From owner-ipsec@lists.tislabs.com Wed Nov 1 15:13:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA13016; Wed, 1 Nov 2000 15:13:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20059 Wed, 1 Nov 2000 16:15:31 -0500 (EST) Message-ID: <20001101212739.17319.qmail@web1502.mail.yahoo.com> Date: Wed, 1 Nov 2000 13:27:39 -0800 (PST) From: Thomas Hardjono Subject: Multicast Security (MSEC) BOF details To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, The Multicast Security (MSEC) BOF at the next IETF49 will be held on Tuesday afternoon (Dec 12). Details are attached below. The msec mailing list should be up and running in the next couple of days. Yours, Thomas Hardjono --------------- --------------------------------------------------------------------------- Multicast Security BOF (msec) Tuesday, December 12 at 1415-1515 Tuesday, December 12 at 1700-1800 ================================= CHAIR: Ran Canetti Thomas Hardjono DESCRIPTION: There is significant interest in the networking industry and content delivery network industry to use IP multicast a vehicle for data delivery to a large audience. One major hindrance to the successful deployment of IP multicast and other group-oriented communication protocols has been the lack of security for both the content and the content-delivery infrastructure. In particular, there has been increasing demand for secure solutions for the 1-to-Many type of group communications, as exemplified by the interest of the cable television sector in using the Internet for content distribution and by the recent emergence of the single-source paradigm in IP multicasting. To this end, the Secure Multicast (SMuG) research group was formed in 1998 under the umbrella of the IRTF. That group has characterized the security concerns and problem areas, has come up with a framework for an overall solution, and has developed protocols for solving much of the problem space in a satisfactory manner. Several of these protocols have reached the needed maturity to be considered for standardization at the IETF. The proposed WG will further develop and standardize the protocols developed at the SMuG RG. The focus will be on mature protocols that are deployable in short term in today's internet. The SMuG RG will continue to examine issues that need further research, delivering protocols to MSEC when they are mature. In the immediate future MSEC will focus on the 1-to-Many group communication, and will address at least the following issues: - Developing the transformations to be applied to the multicasted data. These transformations will provide at least the following functionalities: + Encryption of data using a group key available to all members. + Source and Data Authentications even when the data receivers do not trust each other. Both functionalities are required for content-authors and content-distributors. They represent an important element in the larger digital rights management area. - Group Security Association and Key Management. Secure protocols are needed for management of cryptographic keys and Security Associations for groups. These include techniques for initial key dissemination, key updates and refreshments, and Group Security Association (Group SA) management. Depending on the acceptance and stability of the above two issues, the following issues will be addressed by the WG in the immediate future: - Group Security Policies. Different levels of policies exist for a group, covering a range from member behavior to cryptographic policies. - Secure group announcements. Information regarding the existence of a group, its policies, base security mechanisms and methods for joining needs to be announced in a suitable manner. Secure multicast touches upon the work of several other working groups. The proposed WG will take care to coordinate its activities with the relevant directorates (security, routing, transport) and especially with the IPSec and RMT working groups. The WG will not work on: - Security issues at firewalls and NATs relating to multicast traffic. - Protection against illegal re-distribution of multicasted data. AGENDA: 10 mins - Agenda bashing 10 mins - Charter presentation 80 mins - Internet draft presentations: 10 mins - Taxonomy of multicast security concerns (draft-irtf-smug-taxonomy-01.txt) 10 mins - Framework overview (draft-irtf-smug-framework-01.txt) - Data transforms: 10 mins - Overall design (draft-irtf-smug-data-transforms-00.txt) 10 mins - Source authentication (draft-irtf-smug-tesla-00.txt) - Group key and SA management 10 mins - GKM Building Block (draft-irtf-smug-gkmbb-gsadef-00.txt) 10 mins - GSAKMP (draft-harney-sparta-gsakmp-sec-02.txt) 10 mins - Group DOI for ISAKMP (draft-irtf-smug-gdoi-00.txt) 10 mins - Group policy management (draft-mcast-pol-req00.txt) 20 mins - Open Discussion (work descriptions, objectives, goals/milestones) MAILING LIST The mailing list is at msec-request@securemulticast.org (or email the chairs). The website is at www.securemulticast.org READING MATERIAL draft-irtf-smug-taxonomy-02.txt draft-irtf-smug-framework-01.txt draft-irtf-smug-data-transforms-01.txt draft-irtf-smug-tesla-00.txt draft-irtf-smug-gkmbb-gsadef-00.txt draft-harney-sparta-gsakmp-sec-02.txt draft-irtf-smug-gdoi-00.txt draft-irtf-smug-pol-req00.txt --------------------------------------------------------------------------- __________________________________________________ Do You Yahoo!? >From homework help to love advice, Yahoo! Experts has your answer. http://experts.yahoo.com/ From owner-ipsec@lists.tislabs.com Mon Nov 6 06:31:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA03321; Mon, 6 Nov 2000 06:30:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA05784 Mon, 6 Nov 2000 07:30:14 -0500 (EST) Message-ID: <3A02E061.8C437D10@americasm01.nt.com> Date: Fri, 03 Nov 2000 10:57:21 -0500 From: "Kim Edwards" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipsec Subject: Out of Sync Security Policies Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We are having a problem with out of sync security policies (sp) and we would like to know what other implementations are doing to address this problem. It is possible that we are simply missing something from the RFC. setup: Gateway A Gateway B Initiator --------------------- Responder sp/1 sp/1 ip addresses: 10.1.1.0 ip addresses: 10.1.1.0 protocol: any protocol: tcp sp/2 ip addresses: 10.1.1.0 protocol: icmp Assumptions: 1. all data traffic is flowing from Gateway A to Gateway B. 2. The selectors in a negotiated SA use the value from the corresponding security policy (option b from section 4.4.1, RFC 2401). 3. there are no SAs initially setup. 4. all security policies have the action: protect. Now, if we generate a tcp packet, an SA will be negotiated between A's sp/1 and B's sp/1. The selectors in A's SA will contain "any" as a protocol (assumption 2). If we then send an ICMP packet, the ICMP packet will see that an SA exists according to the sp and SA selectors and a protected packet will be sent to B. B will verify/remove the protection and then verify that the selectors match. Since B's SA selectors contain the protocol "tcp" (assumption 2), the packet will be discarded as the protocol is "icmp". Therefore, it is impossible to send ICMP traffic without clearing the previous SA or having matching sp on both sides. How do we get ICMP traffic through in such a setup? We must be missing the obvious. I must apologize if this has been discussed in past threads, but I could not find any references to this problem. Kim Edwards From owner-ipsec@lists.tislabs.com Mon Nov 6 07:18:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08068; Mon, 6 Nov 2000 07:18:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06104 Mon, 6 Nov 2000 09:02:58 -0500 (EST) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A051A9A15@eseis06nok> To: ipsec@lists.tislabs.com Subject: RE: Out of Sync Security Policies Date: Mon, 6 Nov 2000 16:14:32 +0200 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 I'm not 100% sure because I had problems with this as well, however, I'd say that the first IKE negotiation I wrong and should fail because selectors don't match. If the INITIATOR proposes ANY protocol then the RESPONDER must have ANY in the policy as well. Otherwise you have funny situations like yours. Toni -----Original Message----- From: EXT Kim Edwards [mailto:kimed@nortelnetworks.com] Sent: 03. November 2000 17:57 To: ipsec Subject: Out of Sync Security Policies We are having a problem with out of sync security policies (sp) and we would like to know what other implementations are doing to address this problem. It is possible that we are simply missing something from the RFC. setup: Gateway A Gateway B Initiator --------------------- Responder sp/1 sp/1 ip addresses: 10.1.1.0 ip addresses: 10.1.1.0 protocol: any protocol: tcp sp/2 ip addresses: 10.1.1.0 protocol: icmp Assumptions: 1. all data traffic is flowing from Gateway A to Gateway B. 2. The selectors in a negotiated SA use the value from the corresponding security policy (option b from section 4.4.1, RFC 2401). 3. there are no SAs initially setup. 4. all security policies have the action: protect. Now, if we generate a tcp packet, an SA will be negotiated between A's sp/1 and B's sp/1. The selectors in A's SA will contain "any" as a protocol (assumption 2). If we then send an ICMP packet, the ICMP packet will see that an SA exists according to the sp and SA selectors and a protected packet will be sent to B. B will verify/remove the protection and then verify that the selectors match. Since B's SA selectors contain the protocol "tcp" (assumption 2), the packet will be discarded as the protocol is "icmp". Therefore, it is impossible to send ICMP traffic without clearing the previous SA or having matching sp on both sides. How do we get ICMP traffic through in such a setup? We must be missing the obvious. I must apologize if this has been discussed in past threads, but I could not find any references to this problem. Kim Edwards From owner-ipsec@lists.tislabs.com Mon Nov 6 11:02:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25523; Mon, 6 Nov 2000 11:02:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07061 Mon, 6 Nov 2000 12:40:48 -0500 (EST) From: Dan McDonald Message-Id: <200011061752.eA6HqmT08503@kebe.Eng.Sun.COM> Subject: Reminder - Connectathon To: ipsec@lists.tislabs.com Date: Mon, 6 Nov 2000 09:52:47 -0800 (PST) CC: audrey@vanb.com Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Connectathon organizer Audrey Van Bellingham (audrey@vanb.com), has asked me to remind the list about the 2001 Connectathon which is held March 1-8 in San Jose. We plan on having more IPsec/IKE testing than we did last year. This means we'll need a CA. If there's anyone interested in providing a CA for Connectathon, let me and Audrey know. Some general Connectathon note include: > Plans for Connectathon 2001 are already under way! The 15th annual > Connectathon event, an interoperability testing event for engineers > only, will be held March 1-8, 2001 in San Jose, California. > Connectathon, sponsored by Sun Microsystems, Inc., hosts nearly 50 > companies annually in an effort to test and debug source code which > utilize the following technologies and protocols: > > NFS versions 2, 3 and 4 > NFS over TCP > WebNFS > Lock Manager > NIS/NIS+ > Kerberos > Automounter > IPv6 > IPsec > NDMP > DHCPv6 > CIFS > Mobile IPv4 > Mobile IPv6 > Diameter > Gigabit Ethernet > > Testing continues 24 hours per day. Technology testing coordinators > will organize testing procedures and test suite material. In > addition, there will be seminars with speakers addressing various > topics. > > The registration deadline is February 7, 2001. An Early Bird > Discount on booth fees is available to those who register and pay by > December 31, 2000. For registration information, please see our web > site at http://www.connectathon.org. Registration is accepted on a > first come basis. We encourage you to register early but fees are > non-refundable. Connectathon 2000 was sold out. > > If you have any questions, please feel free to contact Audrey Van > Belleghem at audrey@vanb.com or (408) 358-9598. > > We look forward to seeing you at the 15th annual Connectathon event! > > Audrey Van Belleghem > Connectathon Manager Dan From owner-ipsec@lists.tislabs.com Tue Nov 7 04:06:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA20950; Tue, 7 Nov 2000 04:06:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA10053 Tue, 7 Nov 2000 05:51:23 -0500 (EST) Message-Id: <200011071103.GAA05630@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ike-auth-ecdsa-01.txt Date: Tue, 07 Nov 2000 06:03:30 -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 : IKE Authentication Using ECDSA Author(s) : S. Blake-Wilson, P. Fahn Filename : draft-ietf-ipsec-ike-auth-ecdsa-01.txt Pages : 5 Date : 06-Nov-00 This document describes how the Elliptic Curve Digital Signature Algorithm (ECDSA) may be used as the authentication method within the Internet Key Exchange (IKE) protocol. ECDSA provides authentication and non-repudiation with benefits of computational efficiency, small signature sizes, and minimal bandwidth, compared to other available digital signature methods. This document adds ECDSA capability to IKE without introducing any changes to existing IKE operation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-auth-ecdsa-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ike-auth-ecdsa-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-auth-ecdsa-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: <20001106120036.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-auth-ecdsa-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-auth-ecdsa-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001106120036.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Nov 7 04:58:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA24086; Tue, 7 Nov 2000 04:58:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA10442 Tue, 7 Nov 2000 07:00:26 -0500 (EST) Date: Tue, 7 Nov 2000 14:12:11 +0200 (IST) From: Hugo Krawczyk To: pfahn@certicom.com cc: ipsec list Subject: Re: I-D ACTION:draft-ietf-ipsec-ike-auth-ecdsa-01.txt In-Reply-To: <200011071103.GAA05630@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Security Protocol Working Group of the IETF. > > Title : IKE Authentication Using ECDSA > Author(s) : S. Blake-Wilson, P. Fahn > Filename : draft-ietf-ipsec-ike-auth-ecdsa-01.txt > Pages : 5 > Date : 06-Nov-00 > > This document describes how the Elliptic Curve Digital Signature > Algorithm (ECDSA) may be used as the authentication method within > the Internet Key Exchange (IKE) protocol. ECDSA provides > authentication and non-repudiation with benefits of computational While ECDSA can provide non-repudiation when used appropriately, it cannot guarantee that property, in general, when used in the cotext of the signature authentication mode of IKE. The reason is that BY DESIGN this mode does NOT guarantee non-repudiation regardless of the signature scheme. Indeed the input to the signature is the output of a PRF. For certain PRFs (e.g. 3DES, Rijndael) the combination with the signature results in a repudable signature. Non-repudiation was a no-goal for IKE. Actually ensuring non-repudiation can be viewed as a privacy weakness (as it gives a "proof of communication"). If one still wants to provide non-repudiation then using HMAC as the PRF with a hash function that provides collision-resistance will achieve that. Hugo > efficiency, small signature sizes, and minimal bandwidth, compared > to other available digital signature methods. This document adds > ECDSA capability to IKE without introducing any changes to existing > IKE operation. > From owner-ipsec@lists.tislabs.com Tue Nov 7 05:55:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA27816; Tue, 7 Nov 2000 05:55:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA10960 Tue, 7 Nov 2000 07:57:18 -0500 (EST) Message-ID: <3A07FE1F.A802C7DC@americasm01.nt.com> Date: Tue, 07 Nov 2000 08:05:35 -0500 From: "Kim Edwards" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipsec Subject: Re: Out of Sync Security Policies - Design Flaw References: <0B3F42CA1FB6D2118FE50008C7894B0A051A9A15@eseis06nok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am in agreement that you cannot have out of sync policies with the current RFCs. You should not fail the IPsec SA negotiation due to a wildcard mismatch. The intention for the wildcards is that one side does not care about the selector. Using this logic, if the initiator gives a range of IP addresses, then the responder must also have the same range of addresses in its security policy. I believe that a third Id payload would be required: - Id payload for Initiator's security policy selectors - Id payload for Responder's security policy selectors - Id payload for Initiator's packet selectors With the above, each side could accurately put the most granular selectors in its SA (indirect negotiation of policy selectors). Kim > I'm not 100% sure because I had problems with this as well, however, > I'd say that the first IKE negotiation I wrong and should fail because > selectors don't match. If the INITIATOR proposes ANY protocol then the > RESPONDER must have ANY in the policy as well. Otherwise you have funny > situations like yours. > > Toni > > > -----Original Message----- > From: EXT Kim Edwards [mailto:kimed@nortelnetworks.com] > Sent: 03. November 2000 17:57 > To: ipsec > Subject: Out of Sync Security Policies > > We are having a problem with out of sync security policies (sp) and we > would like to know what other implementations are doing to address > this problem. It is possible that we are simply missing something from > the RFC. > > setup: > > Gateway A Gateway B > > Initiator --------------------- Responder > > sp/1 > sp/1 > ip addresses: 10.1.1.0 ip addresses: > 10.1.1.0 > protocol: any protocol: > tcp > > sp/2 > > ip addresses: 10.1.1.0 > > protocol: icmp > > Assumptions: > > 1. all data traffic is flowing from Gateway A to Gateway B. > > 2. The selectors in a negotiated SA use the value from the > corresponding security policy (option b from section 4.4.1, RFC 2401). > > 3. there are no SAs initially setup. > > 4. all security policies have the action: protect. > > Now, if we generate a tcp packet, an SA will be negotiated between A's > sp/1 and B's sp/1. The selectors in A's SA will contain "any" as a > protocol (assumption 2). > > If we then send an ICMP packet, the ICMP packet will see that an SA > exists according to the sp and SA selectors and a protected packet > will be sent to B. B will verify/remove the protection and then verify > that the selectors match. Since B's SA selectors contain the protocol > "tcp" (assumption 2), the packet will be discarded as the protocol is > "icmp". > Therefore, it is impossible to send ICMP traffic without clearing the > previous > SA or having matching sp on both sides. > > How do we get ICMP traffic through in such a setup? > > We must be missing the obvious. > > I must apologize if this has been discussed in past threads, but I > could not find any references to this problem. > > Kim Edwards From owner-ipsec@lists.tislabs.com Tue Nov 7 08:01:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10505; Tue, 7 Nov 2000 08:01:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11335 Tue, 7 Nov 2000 09:49:00 -0500 (EST) X-Authentication-Warning: loki.research.nokia.com: Host hed040-232.research.nokia.com [172.21.40.232] claimed to be hews0169nrc From: "Markku Savela" To: Subject: RE: Out of Sync Security Policies - Design Flaw Date: Tue, 7 Nov 2000 17:01:10 +0200 Message-ID: <000001c048cb$90faf260$e82815ac@hews0169nrc.research.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <3A07FE1F.A802C7DC@americasm01.nt.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: EXT Kim Edwards [mailto:kimed@nortelnetworks.com] >> I believe that a third Id payload would be required: > > - Id payload for Initiator's security policy selectors > - Id payload for Responder's security policy selectors > - Id payload for Initiator's packet selectors Another solution is totally disable policy checking from IKE. Kernel has to do it anyway for each packet as described in RFC-2401. From owner-ipsec@lists.tislabs.com Tue Nov 7 10:55:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20923; Tue, 7 Nov 2000 10:55:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15107 Tue, 7 Nov 2000 11:59:55 -0500 (EST) Message-ID: <3A083147.ACB0DF02@americasm01.nt.com> Date: Tue, 07 Nov 2000 11:43:51 -0500 From: "Kim Edwards" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipsec Subject: Re: Out of Sync Security Policies - Design Flaw References: <000001c048cb$90faf260$e82815ac@hews0169nrc.research.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Markku, I cannot see how your solution will prevent the scenario I mentioned in my first posting to the mailing list. The problem lies with the fact that we are not negotiating policy selectors. Therefore, the responder SA has different policy selectors than the initiator's SA which leads to my initial problem of not negotiating a new IPsec SA for ICMP traffic. The initiator will attempt to pass the ICMP traffic across the first SA it negotiated, but the responder will discard this protected ICMP traffic as the policy selectors in its SA are for TCP traffic only. Markku Savela wrote: > > From: EXT Kim Edwards [mailto:kimed@nortelnetworks.com] > >> I believe that a third Id payload would be required: > > > > - Id payload for Initiator's security policy selectors > > - Id payload for Responder's security policy selectors > > - Id payload for Initiator's packet selectors > > Another solution is totally disable policy checking from IKE. > > Kernel has to do it anyway for each packet as described in RFC-2401. Kim From owner-ipsec@lists.tislabs.com Tue Nov 7 15:29:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA00776; Tue, 7 Nov 2000 15:29:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15928 Tue, 7 Nov 2000 16:48:07 -0500 (EST) Message-ID: From: "Shriver, John" To: "'ipsec@lists.tislabs.com'" Cc: "'ppanjwani@certicom.com'" , "'sblakewilson@certicom.com'" Subject: consistency in naming for elliptic curves... Date: Tue, 7 Nov 2000 13:48: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 The following text is in the IKE magic numbers file (http://www.isi.edu/in-notes/iana/assignments/ipsec-registry) at the IANA. I'm trying to update my MIB textual conventions for final release, and these give me pause: Group Description Value Reference ----------------- ----- --------- default 768-bit MODP group (section 6.1) 1 [RFC2409] alternate 1024-bit MODP group (section 6.2) 2 [RFC2409] EC2N group on GP[2^155] (section 6.3) 3 [RFC2409] EC2N group on GP[2^185] (section 6.4) 4 [RFC2409] Reserved to IANA 5 EC2N group over GF[2^163] (Section 2.1) 6 [Panjwani] EC2N group over GF[2^163] (Section 2.2) 7 [Panjwani] EC2N group over GF[2^283] (Section 2.3) 8 [Panjwani] EC2N group over GF[2^283] (Section 2.4) 9 [Panjwani] EC2N group over GF[2^409] (Section 2.5) 10 [Blake-Wilson] EC2N group over GF[2^409] (Section 2.6) 11 [Blake-Wilson] EC2N group over GF[2^571] (Section 2.7) 12 [Blake-Wilson] EC2N group over GF[2^571] (Section 2.8) 13 [Blake-Wilson] First, are the two groups of EC2N groups really of the same type? That is, is GP[] distinct from GF[], or is this a typo. Second, the pairs of EC2N groups differing only in the "section number" is very confusing. Is that truly the only difference? Isn't there any more edifying name. Also, I see that value 5 has been set aside, it has been assigned in at least one Internet Draft. Is it being "held" for modp1536, or has it been abandoned due to conflicting assignments in different Internet Drafts? I definitely want to get the textual-conventions MIB out for last call before this IETF meeting. I've had to delete all the numbers that had only been in the IKE revision Internet Draft, since I cannot cite it if I want to go onto RFC standards track. From owner-ipsec@lists.tislabs.com Tue Nov 7 16:35:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA02408; Tue, 7 Nov 2000 16:35:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16095 Tue, 7 Nov 2000 18:14:45 -0500 (EST) Message-Id: <200011072310.PAA00998@potassium.network-alchemy.com> To: "Shriver, John" cc: "'ipsec@lists.tislabs.com'" , "'ppanjwani@certicom.com'" , "'sblakewilson@certicom.com'" Subject: Re: consistency in naming for elliptic curves... In-reply-to: Your message of "Tue, 07 Nov 2000 13:48:31 PST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <995.973638616.1@network-alchemy.com> Date: Tue, 07 Nov 2000 15:10:16 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The magic numbers that are not referenced by RFC2409 were not properly allocated by IANA. There are IANA considerations in RFC2409 that were not followed when these other numbers were allocated. I'm hoping that IANA will rescind these shortly. Dan. On Tue, 07 Nov 2000 13:48:31 PST you wrote > The following text is in the IKE magic numbers file > (http://www.isi.edu/in-notes/iana/assignments/ipsec-registry) at the IANA. > I'm trying to update my MIB textual conventions for final release, and these > give me pause: > > Group Description Value Reference > ----------------- ----- --------- > default 768-bit MODP group (section 6.1) 1 [RFC2409] > alternate 1024-bit MODP group (section 6.2) 2 [RFC2409] > EC2N group on GP[2^155] (section 6.3) 3 [RFC2409] > EC2N group on GP[2^185] (section 6.4) 4 [RFC2409] > Reserved to IANA 5 > EC2N group over GF[2^163] (Section 2.1) 6 [Panjwani] > EC2N group over GF[2^163] (Section 2.2) 7 [Panjwani] > EC2N group over GF[2^283] (Section 2.3) 8 [Panjwani] > EC2N group over GF[2^283] (Section 2.4) 9 [Panjwani] > EC2N group over GF[2^409] (Section 2.5) 10 [Blake-Wilson] > EC2N group over GF[2^409] (Section 2.6) 11 [Blake-Wilson] > EC2N group over GF[2^571] (Section 2.7) 12 [Blake-Wilson] > EC2N group over GF[2^571] (Section 2.8) 13 [Blake-Wilson] > > First, are the two groups of EC2N groups really of the same type? That is, > is GP[] distinct from GF[], or is this a typo. > > Second, the pairs of EC2N groups differing only in the "section number" is > very confusing. Is that truly the only difference? Isn't there any more > edifying name. > > Also, I see that value 5 has been set aside, it has been assigned in at > least one Internet Draft. Is it being "held" for modp1536, or has it been > abandoned due to conflicting assignments in different Internet Drafts? > > I definitely want to get the textual-conventions MIB out for last call > before this IETF meeting. > > I've had to delete all the numbers that had only been in the IKE revision > Internet Draft, since I cannot cite it if I want to go onto RFC standards > track. > > From owner-ipsec@lists.tislabs.com Wed Nov 8 07:34:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06283; Wed, 8 Nov 2000 07:34:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18270 Wed, 8 Nov 2000 08:32:42 -0500 (EST) Message-ID: <3A083147.ACB0DF02@americasm01.nt.com> Date: Tue, 07 Nov 2000 11:43:51 -0500 From: "Kim Edwards" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipsec Subject: Re: Out of Sync Security Policies - Design Flaw References: <000001c048cb$90faf260$e82815ac@hews0169nrc.research.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Markku, I cannot see how your solution will prevent the scenario I mentioned in my first posting to the mailing list. The problem lies with the fact that we are not negotiating policy selectors. Therefore, the responder SA has different policy selectors than the initiator's SA which leads to my initial problem of not negotiating a new IPsec SA for ICMP traffic. The initiator will attempt to pass the ICMP traffic across the first SA it negotiated, but the responder will discard this protected ICMP traffic as the policy selectors in its SA are for TCP traffic only. Markku Savela wrote: > > From: EXT Kim Edwards [mailto:kimed@nortelnetworks.com] > >> I believe that a third Id payload would be required: > > > > - Id payload for Initiator's security policy selectors > > - Id payload for Responder's security policy selectors > > - Id payload for Initiator's packet selectors > > Another solution is totally disable policy checking from IKE. > > Kernel has to do it anyway for each packet as described in RFC-2401. Kim From owner-ipsec@lists.tislabs.com Wed Nov 8 12:06:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22378; Wed, 8 Nov 2000 12:06:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19475 Wed, 8 Nov 2000 13:33:49 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Kim Edwards'" , "'ipsec'" Subject: RE: Out of Sync Security Policies - Design Flaw Date: Wed, 8 Nov 2000 13:25:23 -0500 Message-Id: <001e01c049b1$43896250$d23e788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <3A083147.ACB0DF02@americasm01.nt.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've said this before and I'll say it again. The reason these issues occur is because IKE is (among other things) a policy enforcement protocol which some people want to use as a policy discovery protocol. The same types of issues come up with the cert request payload and, to a lesser extent, exploded SA proposals. Selectors shouldn't need to be negotiated. They should either be known to both peers or they should be discovered independently by each peer (by taking the intersection of two policy rule sets) and then the resulting policy should be enforced by each peer. The purpose of the negotiation phase is merely to confirm that both sides arrived independently at the same result. That is the only sane way to do it. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Kim Edwards > Sent: Tuesday, November 07, 2000 11:44 AM > To: ipsec > Subject: Re: Out of Sync Security Policies - Design Flaw > > > Markku, > > I cannot see how your solution will prevent the scenario I > mentioned in > my first posting to the mailing list. The problem lies with the fact > that we are not negotiating policy selectors. Therefore, the responder > SA has different policy selectors than the initiator's SA > which leads to > my initial problem of not negotiating a new IPsec SA for ICMP traffic. > The initiator will attempt to pass the ICMP traffic across > the first SA > it negotiated, but the responder will discard this protected ICMP > traffic as the policy selectors in its SA are for TCP traffic only. > > Markku Savela wrote: > > > > From: EXT Kim Edwards [mailto:kimed@nortelnetworks.com] > > >> I believe that a third Id payload would be required: > > > > > > - Id payload for Initiator's security policy selectors > > > - Id payload for Responder's security policy selectors > > > - Id payload for Initiator's packet selectors > > > > Another solution is totally disable policy checking from IKE. > > > > Kernel has to do it anyway for each packet as described in RFC-2401. > > Kim > From owner-ipsec@lists.tislabs.com Wed Nov 8 12:06:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22379; Wed, 8 Nov 2000 12:06:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19411 Wed, 8 Nov 2000 13:21:17 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "Simon Blake-Wilson" To: Hugo Krawczyk cc: "Paul Fahn" , ipsec list Message-ID: <85256991.00616B2D.00@smtpmail.certicom.com> Date: Wed, 8 Nov 2000 12:45:07 -0500 Subject: Re: I-D ACTION:draft-ietf-ipsec-ike-auth-ecdsa-01.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Hugo, Thanks. We didn't intend to imply that ECDSA provides non-repudiation within IKE, rather that in general ECDSA can help provide non-repudiation in the same way other signature schemes can help provide non-repudiation. In the context, the text is misleading, and we'll do our best to fix it. Best regards. Simon Hugo Krawczyk on 11/07/2000 07:12:11 AM To: Paul Fahn/Certicom@Certicom cc: ipsec list (bcc: Simon Blake-Wilson/Certicom) Subject: Re: I-D ACTION:draft-ietf-ipsec-ike-auth-ecdsa-01.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Security Protocol Working Group of the IETF. > > Title : IKE Authentication Using ECDSA > Author(s) : S. Blake-Wilson, P. Fahn > Filename : draft-ietf-ipsec-ike-auth-ecdsa-01.txt > Pages : 5 > Date : 06-Nov-00 > > This document describes how the Elliptic Curve Digital Signature > Algorithm (ECDSA) may be used as the authentication method within > the Internet Key Exchange (IKE) protocol. ECDSA provides > authentication and non-repudiation with benefits of computational While ECDSA can provide non-repudiation when used appropriately, it cannot guarantee that property, in general, when used in the cotext of the signature authentication mode of IKE. The reason is that BY DESIGN this mode does NOT guarantee non-repudiation regardless of the signature scheme. Indeed the input to the signature is the output of a PRF. For certain PRFs (e.g. 3DES, Rijndael) the combination with the signature results in a repudable signature. Non-repudiation was a no-goal for IKE. Actually ensuring non-repudiation can be viewed as a privacy weakness (as it gives a "proof of communication"). If one still wants to provide non-repudiation then using HMAC as the PRF with a hash function that provides collision-resistance will achieve that. Hugo > efficiency, small signature sizes, and minimal bandwidth, compared > to other available digital signature methods. This document adds > ECDSA capability to IKE without introducing any changes to existing > IKE operation. > From owner-ipsec@lists.tislabs.com Wed Nov 8 21:09:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA12216; Wed, 8 Nov 2000 21:09:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA20868 Wed, 8 Nov 2000 22:35:36 -0500 (EST) Message-ID: <003d01c049fe$352c7240$23d9bec2@elvis.ru> From: "Valery Smyslov" To: , "'Kim Edwards'" , "'ipsec'" References: <001e01c049b1$43896250$d23e788a@andrewk3.ca.newbridge.com> Subject: Re: Out of Sync Security Policies - Design Flaw Date: Thu, 9 Nov 2000 06:36:10 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: Andrew Krywaniuk To: 'Kim Edwards' ; 'ipsec' Sent: Wednesday, November 08, 2000 9:25 PM Subject: RE: Out of Sync Security Policies - Design Flaw > I've said this before and I'll say it again. > > The reason these issues occur is because IKE is (among other things) a > policy enforcement protocol which some people want to use as a policy > discovery protocol. > > The same types of issues come up with the cert request payload and, to a > lesser extent, exploded SA proposals. > > Selectors shouldn't need to be negotiated. They should either be known to > both peers or they should be discovered independently by each peer (by > taking the intersection of two policy rule sets) and then the resulting > policy should be enforced by each peer. > > The purpose of the negotiation phase is merely to confirm that both sides > arrived independently at the same result. That is the only sane way to do Andrew, if you were right, then what is the purpose of multiple SA proposals in IKE? One proposal would be enough. The fact is that IKE *has* some kind of policy negotiation capabilities, but they are limited. Regards, Valery. > it. > > Andrew > -------------------------------------- > Beauty with out truth is insubstantial. > Truth without beauty is unbearable. > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Kim Edwards > > Sent: Tuesday, November 07, 2000 11:44 AM > > To: ipsec > > Subject: Re: Out of Sync Security Policies - Design Flaw > > > > > > Markku, > > > > I cannot see how your solution will prevent the scenario I > > mentioned in > > my first posting to the mailing list. The problem lies with the fact > > that we are not negotiating policy selectors. Therefore, the responder > > SA has different policy selectors than the initiator's SA > > which leads to > > my initial problem of not negotiating a new IPsec SA for ICMP traffic. > > The initiator will attempt to pass the ICMP traffic across > > the first SA > > it negotiated, but the responder will discard this protected ICMP > > traffic as the policy selectors in its SA are for TCP traffic only. > > > > Markku Savela wrote: > > > > > > From: EXT Kim Edwards [mailto:kimed@nortelnetworks.com] > > > >> I believe that a third Id payload would be required: > > > > > > > > - Id payload for Initiator's security policy selectors > > > > - Id payload for Responder's security policy selectors > > > > - Id payload for Initiator's packet selectors > > > > > > Another solution is totally disable policy checking from IKE. > > > > > > Kernel has to do it anyway for each packet as described in RFC-2401. > > > > Kim > > > > From owner-ipsec@lists.tislabs.com Thu Nov 9 04:57:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA00445; Thu, 9 Nov 2000 04:57:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA22012 Thu, 9 Nov 2000 06:21:08 -0500 (EST) Message-Id: <200011091122.GAA11588@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipsec@lists.tislabs.com, ietf-tls@lists.certicom.com, nat@livingston.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-shukla-ipsec-nat-qos-compatible-security-00.txt Date: Thu, 09 Nov 2000 06:21:59 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NGISec-NAT and QoS compatible End-to-End Secure Communication Author(s) : J. Shukla Filename : draft-shukla-ipsec-nat-qos-compatible-security-00.txt Pages : 15 Date : 08-Nov-00 This document outlines a new approach, called NGISec, for end-to-end secure communication system that is compatible with other networking protocols. Such a solution is needed because IPSec is incompatible with network address translation (NAT), ICMP, and QoS protocols such as differentiated services, RSVP, RED, and ECN. Most of the proposed solutions to mitigate or remove the incompatibility problems of IPSec only address a small sub-section of the problems, and proposed solutions have severe drawbacks. By using our proposed approach, one can achieve end-to-end secure communication in LANs, VPNs, and network-to-network connections. This approach can be viewed as an alternative to IPSec that solves the severe problems faced by IPSec and paves the way for simultaneous use of security and QoS services. While it is aimed to be an alternative to IPSec, it re-uses critical components of the IPSec infrastructure such as the Internet key exchange (IKE). An interesting aspect of the proposed protocol is that it also allows the use of SSL/TLS to build VPNs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shukla-ipsec-nat-qos-compatible-security-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-shukla-ipsec-nat-qos-compatible-security-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-shukla-ipsec-nat-qos-compatible-security-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001108140603.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shukla-ipsec-nat-qos-compatible-security-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-shukla-ipsec-nat-qos-compatible-security-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001108140603.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Nov 9 06:08:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA03952; Thu, 9 Nov 2000 06:08:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA22335 Thu, 9 Nov 2000 07:52:33 -0500 (EST) From: Arvind Devarajan Date: Thu, 09 Nov 2000 08:24:05 GMT Message-ID: <20001109.8240500@INCQ249A.idc.oracle.com> Subject: Help - IPSec Newbie To: ipsec@lists.tislabs.com X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.2;Linux) X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id DAA21742 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi, i have a small doubt. please help me. As i understand from RFC 2401, SPD contains entries related to the polices to be applied for packets going out/in of/from a particular host/gateway. Each entry of the SPD also contains a list of SAs that any packet that applies that policy will have to pass through. For example, a Sample SPD might contain: Policy, List of SAs Policy, List of SAs The "List of SAs" could also be a "Single" SA, depending upon the policy. The to be selected is based on the "selectors" and the packet parameters. Now, my question is: 1.As I understand, SPD is a static database done initially, and all the SAs are created dynamically. This being the case, how will the "List of SAs" or a "Single SA" be specified in the policy entries of the SPD? 2.Just as the incoming packets help in identifying the SA through which they should be passed, using the tupple (SPI, Protocol and Dst Addr), does the SPD entries too have any such identifier for the SAs? Please help. I am designing an entirely new implementation of IPSec, not based on any existing ones. I am doing this as a part of my Masters project, and, inter-operability, and performance are my main concerns. Soon, i'll be posting my design for your valuable comments and feedback. Thanking you, Arvind. From owner-ipsec@lists.tislabs.com Thu Nov 9 07:20:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA10398; Thu, 9 Nov 2000 07:20:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA22561 Thu, 9 Nov 2000 09:01:28 -0500 (EST) X-Authentication-Warning: loki.research.nokia.com: Host hed040-232.research.nokia.com [172.21.40.232] claimed to be hews0169nrc From: "Markku Savela" To: "'EXT Arvind Devarajan'" , Subject: RE: Help - IPSec Newbie Date: Thu, 9 Nov 2000 16:02:14 +0200 Message-ID: <000001c04a55$aaa52880$e82815ac@hews0169nrc.research.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <20001109.8240500@INCQ249A.idc.oracle.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: EXT Arvind Devarajan > Policy, List of SAs > Policy, List of SAs > 1.As I understand, SPD is a static database done initially, > and all the > SAs are created dynamically. This being the case, how will > the "List of > SAs" or a "Single SA" be specified in the policy entries of the SPD? It's not list of SA's. It's a list of "SA templates", which specify the required parameters for the SA's to be used or created. > 2.Just as the incoming packets help in identifying the SA > through which > they should be passed, using the tupple (SPI, Protocol and Dst Addr), > does the SPD entries too have any such identifier for the SAs? That is an implementation issue, as an optimization, one could attach the real SA's to the policy selector once they are created. However, it gets complex. Consider a selector remote port = 8099 -> SA-template That selector will apply to multiple communications with different hosts, each needing a similar, but different SA (addresses are different). Thus you would at least need to implement a list of created SA's, and search this list for existing SA, whenever the policy matches. [assume port 8099 is used by some new fancy protocol that always uses IPSEC] From owner-ipsec@lists.tislabs.com Thu Nov 9 13:41:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02247; Thu, 9 Nov 2000 13:41:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23848 Thu, 9 Nov 2000 15:07:32 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'ipsec'" Subject: RE: Out of Sync Security Policies - Design Flaw Date: Thu, 9 Nov 2000 14:55:59 -0500 Message-Id: <000601c04a87$15f4d0a0$d23e788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: <003d01c049fe$352c7240$23d9bec2@elvis.ru> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Andrew, > > if you were right, then what is the purpose of multiple SA > proposals in IKE? > One proposal would be enough. Three possible interpretations: 1. The discovered policy could be ambiguous. You need to chose between one of several possibilities. 2. The sets of transforms that are likely to work are "preshared" in that it is generally well known which algorithms are likely to work. (e.g. if you're using anything other than 3DES or AES with MD5 or SHA-1 with commonly used block sizes and # of rounds and mode of operation and hash output length then you are unlikely to work with some random host on the net). As the combinatorics majors known, if two people each randomly draw 3 coloured balls from a sock containing 6 different colours of balls then there's a good chance that they will have at least one ball colour in common. 3. This is an example of a case where people are using IKE to perform policy discovery instead of policy enforcement. On the other hand, one thing has been proven multiple times now: Don't assume that there's a good reason for doing something just because it's in the spec. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Valery Smyslov > Sent: Wednesday, November 08, 2000 10:36 PM > To: andrew.krywaniuk@alcatel.com; 'Kim Edwards'; 'ipsec' > Subject: Re: Out of Sync Security Policies - Design Flaw > > > ----- Original Message ----- > From: Andrew Krywaniuk > To: 'Kim Edwards' ; 'ipsec' > > Sent: Wednesday, November 08, 2000 9:25 PM > Subject: RE: Out of Sync Security Policies - Design Flaw > > > > I've said this before and I'll say it again. > > > > The reason these issues occur is because IKE is (among > other things) a > > policy enforcement protocol which some people want to use > as a policy > > discovery protocol. > > > > The same types of issues come up with the cert request > payload and, to a > > lesser extent, exploded SA proposals. > > > > Selectors shouldn't need to be negotiated. They should > either be known to > > both peers or they should be discovered independently by > each peer (by > > taking the intersection of two policy rule sets) and then > the resulting > > policy should be enforced by each peer. > > > > The purpose of the negotiation phase is merely to confirm > that both sides > > arrived independently at the same result. That is the only > sane way to do > > Andrew, > > if you were right, then what is the purpose of multiple SA > proposals in IKE? > One proposal would be enough. > > The fact is that IKE *has* some kind of policy negotiation > capabilities, > but they are limited. > > Regards, > Valery. From owner-ipsec@lists.tislabs.com Fri Nov 10 02:40:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA17317; Fri, 10 Nov 2000 02:40:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA25930 Fri, 10 Nov 2000 04:25:50 -0500 (EST) Message-Id: <200011100926.MAA08709@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: "'ipsec'" , Date: Fri, 10 Nov 2000 12:25:52 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: Out of Sync Security Policies - Design Flaw In-reply-to: <000601c04a87$15f4d0a0$d23e788a@andrewk3.ca.newbridge.com> References: <003d01c049fe$352c7240$23d9bec2@elvis.ru> X-mailer: Pegasus Mail for Win32 (v3.12b) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 9 Nov 00, at 14:55, Andrew Krywaniuk wrote: > > Andrew, > > > > if you were right, then what is the purpose of multiple SA > > proposals in IKE? > > One proposal would be enough. > > Three possible interpretations: > > 1. The discovered policy could be ambiguous. You need to chose between one > of several possibilities. I see no reason for ambiguity if policy are known in advance to both sides. > 2. The sets of transforms that are likely to work are "preshared" in that it > is generally well known which algorithms are likely to work. (e.g. if you're > using anything other than 3DES or AES with MD5 or SHA-1 with commonly used > block sizes and # of rounds and mode of operation and hash output length > then you are unlikely to work with some random host on the net). > > As the combinatorics majors known, if two people each randomly draw 3 > coloured balls from a sock containing 6 different colours of balls then > there's a good chance that they will have at least one ball colour in > common. Again, there is no need for such a negotiation if policies are known in advance. > 3. This is an example of a case where people are using IKE to perform policy > discovery instead of policy enforcement. Because IKE explicitly allows it. > On the other hand, one thing has been proven multiple times now: Don't > assume that there's a good reason for doing something just because it's in > the spec. Regards, Valery. > Andrew > -------------------------------------- > Beauty with out truth is insubstantial. > Truth without beauty is unbearable. > > From owner-ipsec@lists.tislabs.com Fri Nov 10 05:57:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA29840; Fri, 10 Nov 2000 05:57:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA26637 Fri, 10 Nov 2000 07:49:16 -0500 (EST) Message-ID: <3A0B3904.ED5A5343@sookmyung.ac.kr> Date: Fri, 10 Nov 2000 08:53:41 +0900 From: Gwangsoo Rhee X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: [Q] IPSEC Newbie Question on ISAKMP/Oakley Resolution document Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk RFC 2412 makes many references to ISAKMP/Oakley Resolution document. Could anyone tell me which document it is, please? Many thanks. -- --------------------------------------- Gwangsoo Rhee tel: +82-2-710-9429 fax: 710-9296 HP: 011-9691-9541 --------------------------------------- From owner-ipsec@lists.tislabs.com Fri Nov 10 09:52:34 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA24055; Fri, 10 Nov 2000 09:52:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA27259 Fri, 10 Nov 2000 11:26:24 -0500 (EST) Date: Fri, 10 Nov 2000 11:27:05 -0500 Message-Id: <200011101627.LAA22006@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@lists.tislabs.com Subject: Agenda topics for the upcoming IPSEC wg meeting Phone: (781) 391-3464 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We currently have one full session reserved for the upcoming IETF meeting in San Diego. Could folks who would like to propose topics for the IPSEC agenda please forward them to me ASAP. Please estimate how much time you need for your presenatation, and how much time you think might be needed for discussion afterwards. If the agenda looks like it may get too full, I can investigate the possibility of requesting a second slot. Many thanks!! - Ted From owner-ipsec@lists.tislabs.com Mon Nov 13 05:02:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA18394; Mon, 13 Nov 2000 05:02:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA05447 Mon, 13 Nov 2000 06:39:07 -0500 (EST) Message-Id: <200011131140.GAA05541@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipsec@lists.tislabs.com, ippcp@external.cisco.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-heath-ipcomp-v44-01.txt Date: Mon, 13 Nov 2000 06:40:05 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Payload Compression Using ITU-T V.44 Packet Method Author(s) : J. Heath, J. Border Filename : draft-heath-ipcomp-v44-01.txt Pages : 7 Date : 10-Nov-00 This document describes a compression method based on the data compression algorithm described in ITU-T Recommendation V.44 [V44]. Recommendation V.44 is a modem standard but Annex B, Clause B.1, of the recommendation describes the implementation of V.44 in packet networks (e.g. V.44 Packet Method). This document defines the the application of V.44 Packet Method to the IP Payload Compression Protocol [RFC-2393]. [RFC-2393] defines a method for applying lossless compression to the payload portion of Internet Protocol datagrams. V.44 Packet Method is based upon the LZJH data compression algorithm. Thoughout the remainder of this document the terms V.44 Packet Method and LZJH are synonomous. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-heath-ipcomp-v44-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-heath-ipcomp-v44-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-heath-ipcomp-v44-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: <20001110102737.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-heath-ipcomp-v44-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-heath-ipcomp-v44-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001110102737.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Nov 13 13:44:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22260; Mon, 13 Nov 2000 13:44:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07540 Mon, 13 Nov 2000 15:30:51 -0500 (EST) Message-Id: <5.0.0.25.0.20001113115929.00a8ceb0@omega> X-Sender: sfluhrer@omega X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 13 Nov 2000 12:29:14 -0800 To: ipsec@lists.tislabs.com From: Scott Fluhrer Subject: Re: I-D ACTION:draft-shukla-ipsec-nat-qos-compatible-security-00.txt In-Reply-To: <200011091122.GAA11588@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Looking through the above draft, we find the text (section 6): "The control packets [SYN=1 or initial UDP packets] are decrypted at the [NAT] gateways and re-encrypted after NAT to achieve complete compatibility with NAT." "The data packets are encrypted at the end hosts and are not decrypted at the gateways." They appear to be requiring that the NAT gateways to share copies of the IPSec keys with the end hosts. If I am interpreting this right, then: - The fact that there are more than two systems with knowledge of the secret keys is not listed in the Security Considerations -- IMHO, it really should be - The draft does not address how the key transport is to be done securely - The draft cannot be implemented securely if you don't have any way to authenticate, or don't trust, the NAT gateway. Could the author please confirm my interpretation, and address the above concerns? >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-shukla-ipsec-nat-qos-compatible-security-00.txt -- scott From owner-ipsec@lists.tislabs.com Mon Nov 13 18:21:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA28762; Mon, 13 Nov 2000 18:21:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08545 Mon, 13 Nov 2000 20:12:14 -0500 (EST) Message-ID: <000401c04dd8$c77210f0$5fb12304@ffb5b> From: "jshukla" To: , "Scott Fluhrer" References: <5.0.0.25.0.20001113115929.00a8ceb0@omega> Subject: Re: I-D ACTION:draft-shukla-ipsec-nat-qos-compatible-security-00.txt Date: Mon, 13 Nov 2000 17:18:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Scott Fluhrer" To: Sent: Monday, November 13, 2000 12:29 PM Subject: Re: I-D ACTION:draft-shukla-ipsec-nat-qos-compatible-security-00.txt > Looking through the above draft, we find the text (section 6): > > "The control packets [SYN=1 or initial UDP packets] are decrypted > at the [NAT] gateways and re-encrypted after NAT to achieve complete > compatibility with NAT." > > "The data packets are encrypted at the end hosts and are not > decrypted at the gateways." > > > They appear to be requiring that the NAT gateways to share copies of > the IPSec keys with the end hosts. If I am interpreting this right, > then: > No. The keys and SAs used by the end host to encrypt/decrypt the data packets are not shared with the gateways. There is a separate channel for securely transmitting the control packets (just read further down the same section). quote--- " Typically separate secure channels are used for communicating the control and data packets because the control packets are decrypted at the gateways. This creates extra overhead of establishing security associations and key exchange for the control packets, but is necessary for end-to-end secure communication over the public networks. Since the control packets are few compared to data packets, using a single secure channel for all control packets communication between two hosts can mitigate the extra overhead. In LANs it is possible to use the same secure channel for both because the gateways do not affect these packets." end quote--- This picture might help understand how the control packets are transmitted. k_1, SA_1 k_2, SA_2 k_3, SA_2 host A --------- Gateway A -----------Gateway B ---------host B encrypt control packet using k_1, SA_1 decrypt using k_1, SA_1 NAT encrypt using k_2, SA_2 decrypt using k_2, SA_2 NAT encrypt using k_3, SA_3 decrypt using k_3, SA_3 ---------------------------------------------------------------------------- ---- For data packets host A ---------Gateway A --------------Gateway B-------host B encrypt using ----NAT--------------------NAT---------------decrypt k_data, SA_data using k_data, SA_data regards, Jayant From owner-ipsec@lists.tislabs.com Mon Nov 13 22:14:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA02170; Mon, 13 Nov 2000 22:14:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA09051 Tue, 14 Nov 2000 00:16:38 -0500 (EST) Message-ID: <7695E2F6903F7A41961F8CF888D87EA80130C933@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: "Mobile IP (E-mail)" , "IPsec (E-mail)" Subject: RE: mobile IPv6 & IPsec policies Date: Mon, 13 Nov 2000 21:12:20 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I had an old address for the ipsec list in my original email, so please reply to this email instead. -----Original Message----- From: Richard Draves Sent: Monday, November 13, 2000 9:06 PM To: Mobile IP (E-mail); IPsec (E-mail) Subject: mobile IPv6 & IPsec policies I have some questions about the interactions between mobile IPv6 and IPsec policy selection (SPD lookup) and IKE (SA negotiation) in draft-ietf-mobileip-ipv6-12, especially sections 4.4 and 10.2. If this is all obvious to others then perhaps the draft could be clarified. It's not obvious to me and I don't know enough about IPsec & IKE to be certain of the answers. I believe the draft says/implies: the security policies on the mobile node do not usually change when the mobile node moves, and policy lookups use home addresses, not care-of addresses. A. What policy selectors should be used when sending/receiving a Binding Update? Section 10.2 says: - As part of outbound packet processing in IP, the packet is compared against the IPsec Security Policy Database (SPD) to determine what processing is required for the packet [13]. - As a special case for Mobile IP, if a Binding Update or Binding Acknowledgement is being included in the packet, IPsec authentication, integrity protection, and replay protection MUST be applied to the packet [13, 11, 12], as defined in Section 4.4. If the SPD check above has already indicated that authentication and replay protection are required, this processing is sufficient for the Mobile IP requirement that all packets containing Binding Updates or Binding Acknowledgements be authenticated and covered by replay protection. Otherwise, an implementation can force the required IPsec processing on this individual packet by, for example, creating a temporary SPD entry for the handling of this packet. Suppose you are piggy-backing a Binding Update on a TCP or UDP packet, but the selectors find a policy of "no IPsec needed" in the SPD. Then Mobile IPv6 is saying, you should negotiate and use an SA anyway, because the Binding Update needs to be protected. The suggestion is to create a temporary SPD entry. What should this temporary SPD entry contain? What transforms should be proposed in the ensuing IKE negotation? What if there is a policy, but it doesn't provide the required protections - if you try to negotiate an SA with IKE for transforms that aren't in the policy, isn't the correspondent likely to reject the proposals when they don't match its policy? Suppose this is a "naked" Binding Update, not piggy-backed on a TCP or UDP packet. What selectors should be used in the policy lookup? Should there be a policy lookup at all, or should you instead try to find & use any suitable existing SA between the two machines? It seems like a naked Binding Update should reuse if possible an existing SA between the two machines. B. Suppose the mobile node's home is in the same organization as the correspondent node (ie normally no IPsec needed for communication between home location & correspondent), but the mobile node is away from home. In fact there is a Security Gateway between the mobile node and the correspondent node, and the mobile node needs to use one SA to communicate with the SG (say ESP tunnel-mode) and a second SA (say transport-mode AH) to send binding-updates through to the correspondent node. A policy lookup on the mobile node based solely on the home address will not work because the result will be "no IPsec needed". Even if you force the use of IPsec to protect the Binding Updates (as discussed above), you won't know to negotiate a tunnel-mode SA and communicate via the SG. One possibility (that I like) is that Mobile IPv6 effectively mandates that policies that need communication via a security gateway must be implemented in the routing table via a tunnel interface, instead of in the SPD. However, mandating this style of implementation for security gateway policies would be a departure from the base IPsec standard as I understand it. For one thing, because routing table lookups are usually based just on destination address and don't take into account the other IPsec selectors, this would limit the kinds of policies that you could use. An alternative would be to say the mobile node does TWO lookups in the SPD, one using its home address and another using its care-of address, and merges the resulting policies that it gets from those two lookups. Actually it gets more complicated, because there might be an HA->CoA mapping for the destination as well as the source address. The tunnel interface approach to dealing with security gateways seems simpler. Thanks, Rich From owner-ipsec@lists.tislabs.com Tue Nov 14 06:18:32 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA22066; Tue, 14 Nov 2000 06:18:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA10426 Tue, 14 Nov 2000 07:56:22 -0500 (EST) Message-Id: <200011140428.eAE4Sut03731@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-shukla-ipsec-nat-qos-compatible-security-00.txt In-reply-to: Your message of "Mon, 13 Nov 2000 12:29:14 PST." <5.0.0.25.0.20001113115929.00a8ceb0@omega> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 13 Nov 2000 23:28:56 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Scott" == Scott Fluhrer writes: Scott> They appear to be requiring that the NAT gateways to share copies of Scott> the IPSec keys with the end hosts. If I am interpreting this right, Scott> then: Scott> - The fact that there are more than two systems with knowledge of the Scott> secret keys is not listed in the Security Considerations -- IMHO, Scott> it really should be Scott> - The draft does not address how the key transport is to be done Scott> securely More importantly: Even if you invent a secure way to share the keys with the NAT gateway, since you have now caused new software on the client and the gateway, then you might as well do it right and use RSIP, SPP, ESPUDP or IPv6. All NAT compatibility solutions must be evaluated against RSIP and SPP in particular. In addition, doing: client nat gateway IPv4-1/ESP/IPv6 IPv4-1/ESP/IPv6/IPv4 using 6to4 addressing, seems as good to me as doing NAPT. The only disadvantage is 20 bytes extra overhead. But, that goes way as you transition to IPv6. I.e. if you are going to encapsulate, you might as well use IPv6. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson | Travelling... if you don't know where I am, how should I? Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: mcr@solidum.com. From owner-ipsec@lists.tislabs.com Tue Nov 14 11:39:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15260; Tue, 14 Nov 2000 11:39:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11878 Tue, 14 Nov 2000 13:27:08 -0500 (EST) Message-ID: <000901c04e69$5b1f3b80$98b12304@ffb5b> From: "jshukla" To: , "Michael Richardson" References: <200011140428.eAE4Sut03731@sandelman.ottawa.on.ca> Subject: Re: I-D ACTION:draft-shukla-ipsec-nat-qos-compatible-security-00.txt Date: Tue, 14 Nov 2000 10:33:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Michael Richardson" > > Even if you invent a secure way to share the keys with the NAT gateway, > since you have now caused new software on the client and the gateway, then > you might as well do it right and use RSIP, SPP, ESPUDP or IPv6. > Scott had reached an incorrect conclusion and my previous e-mail addresses that issue. As far as RSIP, ESPUDP etc. are concerned, please take a look at the Section 5 of my draft where I talk about the existing solutions and their drawbacks. I also give references to other drafts and RFCs that talk about the problems with existing solutions in greater detail. regards, Jayant From owner-ipsec@lists.tislabs.com Wed Nov 15 06:38:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA28359; Wed, 15 Nov 2000 06:38:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA14925 Wed, 15 Nov 2000 08:05:27 -0500 (EST) Reply-To: From: "Sumanth Inabathini" To: Subject: LDAP CRLs Server Date: Wed, 15 Nov 2000 13:08:01 +0530 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C04F05.152438A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C04F05.152438A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hai All, I am quite new to this new mailid and so I am not aware whether the doubts I have might have been answered already. I am right now working on the implementation of the LDAP for IKE to retrieve CRLs from a CA. I have the following doubts: 1) I want to know a public LDAP CRL server. If there are any such, I would also like to know additional information like the ip address of the public LDAP CRL server etc., needed to connect to the server and get the CRLs from the server. 2) I would also like to know something more about CRLs like how they are organised, what are the different attributes in the CRL and what it is like. 3) And I would also like to know the format of the data that is returned from the LDAP server like whether entries returned contain the attributes of the each certificate that is revoked or how it is. . I mean, I would like to know how the results are returned. Your kind help will be highly appreciated. Regards Sumanth. ------=_NextPart_000_000C_01C04F05.152438A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hai=20 All, I am=20 quite new to this new mailid and so I am not aware whether the doubts I = have=20 might have been answered already. I am = right now=20 working on the implementation of the LDAP for IKE to retrieve CRLs from = a=20 CA. I have = the following=20 doubts: 1) I=20 want to know a public LDAP CRL server. =20 If there are any such, I would also like to know additional information = like the=20 ip address of the public LDAP CRL server etc., =20 =20 needed to connect to the server and get the CRLs from the=20 server. 2) I would=20 also like to know something more about CRLs like how they are organised, = what=20 are the different attributes in the CRL and=20 what it is like. 3) And I=20 would also like to know the format of the data that is returned from the = LDAP=20 server like whether entries returned contain the=20 attributes of the each certificate that is revoked or how it is.=20 . I mean, I=20 would like to know how the results are returned. Your = kind help will=20 be highly appreciated. Regards Sumanth. ------=_NextPart_000_000C_01C04F05.152438A0-- From owner-ipsec@lists.tislabs.com Wed Nov 15 09:35:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10032; Wed, 15 Nov 2000 09:35:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15606 Wed, 15 Nov 2000 11:11:18 -0500 (EST) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A051A9AA8@eseis06nok> To: ipsec@lists.tislabs.com Subject: ISAKMP_RESPONDER_LIFETIME Date: Wed, 15 Nov 2000 18:12:05 +0200 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 IPSEC DOI question: Is the ISAKMP_RESPONDER_LIFETIME notification payload supposed to send only the lifetime (seconds) or also the lifesize (KBytes)? And if both can be send, should they both be send together in the same ISAKMP Notification payload (Of course same SA) or in 2 different ones? Thanks. Toni From owner-ipsec@lists.tislabs.com Wed Nov 15 21:16:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA24652; Wed, 15 Nov 2000 21:16:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA20989 Wed, 15 Nov 2000 22:53:00 -0500 (EST) Reply-To: From: "Sumanth Inabathini" To: "IPSec" Subject: LDAP CRL Server Date: Thu, 16 Nov 2000 09:29:34 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi All, I am quite new to this mailing list and so I am not aware whether the doubts I have, might have been already answered. I am right now working on the implementation of the LDAP for IKE to retrieve CRLs from a CA. I have the following doubts: 1) I want to know whether there are any public LDAP CRL servers. If there are any such, I would also like to know additional information like the ip address of the public LDAP CRL server etc., needed to connect to the server and get the CRLs from the server. 2) I would also like to know something more about CRLs like how they are organised, what are the different attributes in the CRL and what it is like. 3) And I would also like to know the format of the data that is returned from the LDAP server, like whether each result returned contains a single record of the certificates with their atributes that are in the CRLs or the entire list of the certificates with their attributes or how it is. . I mean, I would like to know how the results are returned. I am stuck up here. Pls help me out. Your help in this regard will be highly appreciated. Regards Sumanth. From owner-ipsec@lists.tislabs.com Thu Nov 16 13:21:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA09974; Thu, 16 Nov 2000 13:21:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23985 Thu, 16 Nov 2000 15:10:54 -0500 (EST) Date: Thu, 16 Nov 2000 22:11:58 +0200 (EET) Message-Id: <200011162011.WAA16045@torni.hel.fi.ssh.com> X-Authentication-Warning: torni.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 From: Tero Kivinen To: antonio.barrera@nokia.com Cc: ipsec@lists.tislabs.com Subject: ISAKMP_RESPONDER_LIFETIME In-Reply-To: <0B3F42CA1FB6D2118FE50008C7894B0A051A9AA8@eseis06nok> References: <0B3F42CA1FB6D2118FE50008C7894B0A051A9AA8@eseis06nok> X-Mailer: VM 6.34 under Emacs 20.7.2 Organization: SSH Communications Security Oy X-Edit-Time: 1 min X-Total-Time: 0 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk antonio.barrera@nokia.com writes: > IPSEC DOI question: > > Is the ISAKMP_RESPONDER_LIFETIME notification payload supposed to > send only the lifetime (seconds) or also the lifesize (KBytes)? Yes, I think both are allowed. > And if both can be send, should they both be send together in the same > ISAKMP Notification payload (Of course same SA) or in 2 different ones? I would say that they must be only one notification, containing both. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Nov 17 07:19:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20105; Fri, 17 Nov 2000 07:19:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29381 Fri, 17 Nov 2000 09:15:03 -0500 (EST) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A051A9AD7@eseis06nok> To: ipsec@lists.tislabs.com Subject: RE: ISAKMP_RESPONDER_LIFETIME (Could it be removed?) Date: Fri, 17 Nov 2000 16:15:58 +0200 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 I noticed that some implementations actually allow a reply with an SA with different lifetimes so if the reply contains a smaller lifetime means that the other peer is using a smaller lifetime. In these cases RESPONDER_LIFETIME is actually useless. Is it mandatory that the SA in the reply has exactly the same lifetime or it can be smaller? I think taht would be a good solution for a further version of IKE to get rid of the RESPONDER_LIFETIME. Anyway it doesn't appear to be used too much. Any coments? Toni -----Original Message----- From: EXT Tero Kivinen [mailto:kivinen@ssh.fi] Sent: 16. November 2000 22:12 To: antonio.barrera@nokia.com Cc: ipsec@lists.tislabs.com Subject: ISAKMP_RESPONDER_LIFETIME antonio.barrera@nokia.com writes: > IPSEC DOI question: > > Is the ISAKMP_RESPONDER_LIFETIME notification payload supposed to > send only the lifetime (seconds) or also the lifesize (KBytes)? Yes, I think both are allowed. > And if both can be send, should they both be send together in the same > ISAKMP Notification payload (Of course same SA) or in 2 different ones? I would say that they must be only one notification, containing both. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Nov 17 09:01:20 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA29232; Fri, 17 Nov 2000 09:01:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA29779 Fri, 17 Nov 2000 11:17:57 -0500 (EST) Message-ID: <092301c050b2$42e8fce0$83d62ca1@cisco.com> From: "Stephane Beaulieu" To: , References: <0B3F42CA1FB6D2118FE50008C7894B0A051A9AD7@eseis06nok> Subject: Re: ISAKMP_RESPONDER_LIFETIME (Could it be removed?) Date: Fri, 17 Nov 2000 11:20:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From 2409, Section 5. During security association negotiation, initiators present offers for potential security associations to responders. Responders MUST NOT modify attributes of any offer, attribute encoding excepted (see Appendix A). If the initiator of an exchange notices that attribute values have changed or attributes have been added or deleted from an offer made, that response MUST be rejected. I don't necessarily agree with it, but if you want interoperability, I would use the RESPONDER-LIFETIME notify instead. Stephane. ----- Original Message ----- From: To: Sent: Friday, November 17, 2000 9:15 AM Subject: RE: ISAKMP_RESPONDER_LIFETIME (Could it be removed?) > I noticed that some implementations actually allow a reply with an > SA with different lifetimes so if the reply contains a smaller lifetime > means that > the other peer is using a smaller lifetime. In these cases > RESPONDER_LIFETIME is actually useless. > Is it mandatory that the SA in the reply has exactly the same > lifetime or it can be smaller? > I think taht would be a good solution for a further version of IKE to get > rid of the RESPONDER_LIFETIME. Anyway it doesn't appear to be used too much. > Any coments? > > Toni > > -----Original Message----- > From: EXT Tero Kivinen [mailto:kivinen@ssh.fi] > Sent: 16. November 2000 22:12 > To: antonio.barrera@nokia.com > Cc: ipsec@lists.tislabs.com > Subject: ISAKMP_RESPONDER_LIFETIME > > > antonio.barrera@nokia.com writes: > > IPSEC DOI question: > > > > Is the ISAKMP_RESPONDER_LIFETIME notification payload supposed to > > send only the lifetime (seconds) or also the lifesize (KBytes)? > > Yes, I think both are allowed. > > > And if both can be send, should they both be send together in the same > > ISAKMP Notification payload (Of course same SA) or in 2 different ones? > > I would say that they must be only one notification, containing both. > -- > kivinen@ssh.fi Work : +358 303 9870 > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Nov 17 10:10:41 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02960; Fri, 17 Nov 2000 10:10:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29965 Fri, 17 Nov 2000 12:19:49 -0500 (EST) Message-Id: <200011171715.JAA25725@potassium.network-alchemy.com> To: antonio.barrera@nokia.com cc: ipsec@lists.tislabs.com Subject: Re: ISAKMP_RESPONDER_LIFETIME (Could it be removed?) In-reply-to: Your message of "Fri, 17 Nov 2000 16:15:58 +0200." <0B3F42CA1FB6D2118FE50008C7894B0A051A9AD7@eseis06nok> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25722.974481336.1@network-alchemy.com> Date: Fri, 17 Nov 2000 09:15:37 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't understand why that behavior makes RESPONDER_LIFETIME useless? On the contrary. It is saying, "the lifetime I'm enforcing is actually foo". If A is configured with a lifetime less than B and A initiates to B it kind of makes sense for B to accept the smaller lifetime (smaller lifetime means less chance for key exposure). But when B initiates to A, A will not want to increase the lifetime as her config says something like: "...a lifetime of not more than foo", so all other attributes being acceptable she accepts the offer but says, "actually, the lifetime I'm enforcing is foo." B should honor this for the same reason B should've honored the smaller lifetime if A had been initiating. This allows each side to have a reasonable expectation of when the other side is no longer using the SA and lessen the chance of one side assuming the other has SAs and continuing to send packets using them only to have them silently dropped on the floor by the other side. RESPONDER_LIFETIME is quite useful. Dan. On Fri, 17 Nov 2000 16:15:58 +0200 you wrote > I noticed that some implementations actually allow a reply with an > SA with different lifetimes so if the reply contains a smaller lifetime > means that > the other peer is using a smaller lifetime. In these cases > RESPONDER_LIFETIME is actually useless. > Is it mandatory that the SA in the reply has exactly the same > lifetime or it can be smaller? > I think taht would be a good solution for a further version of IKE to get > rid of the RESPONDER_LIFETIME. Anyway it doesn't appear to be used too much. > Any coments? > > Toni > > -----Original Message----- > From: EXT Tero Kivinen [mailto:kivinen@ssh.fi] > Sent: 16. November 2000 22:12 > To: antonio.barrera@nokia.com > Cc: ipsec@lists.tislabs.com > Subject: ISAKMP_RESPONDER_LIFETIME > > > antonio.barrera@nokia.com writes: > > IPSEC DOI question: > > > > Is the ISAKMP_RESPONDER_LIFETIME notification payload supposed to > > send only the lifetime (seconds) or also the lifesize (KBytes)? > > Yes, I think both are allowed. > > > And if both can be send, should they both be send together in the same > > ISAKMP Notification payload (Of course same SA) or in 2 different ones? > > I would say that they must be only one notification, containing both. > -- > kivinen@ssh.fi Work : +358 303 9870 > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Nov 17 13:48:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17184; Fri, 17 Nov 2000 13:48:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00638 Fri, 17 Nov 2000 15:40:00 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Stephane Beaulieu'" , , Subject: RE: ISAKMP_RESPONDER_LIFETIME (Could it be removed?) Date: Fri, 17 Nov 2000 15:29:56 -0500 Message-Id: <001c01c050d5$2726e350$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 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <092301c050b2$42e8fce0$83d62ca1@cisco.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From 2409, Section 5. > > During security association negotiation, initiators present offers > for potential security associations to responders. Responders MUST > NOT modify attributes of any offer, attribute encoding > excepted (see > Appendix A). If the initiator of an exchange notices that > attribute > values have changed or attributes have been added or > deleted from an > offer made, that response MUST be rejected. > > > I don't necessarily agree with it, but if you want > interoperability, I would > use the RESPONDER-LIFETIME notify instead. I believe this constraint is required in order to allow stateless operation. In other words, it's an artifact, just like cookies. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephane Beaulieu > Sent: Friday, November 17, 2000 11:20 AM > To: antonio.barrera@nokia.com; ipsec@lists.tislabs.com > Subject: Re: ISAKMP_RESPONDER_LIFETIME (Could it be removed?) > > > From 2409, Section 5. > > During security association negotiation, initiators present offers > for potential security associations to responders. Responders MUST > NOT modify attributes of any offer, attribute encoding > excepted (see > Appendix A). If the initiator of an exchange notices that > attribute > values have changed or attributes have been added or > deleted from an > offer made, that response MUST be rejected. > > > I don't necessarily agree with it, but if you want > interoperability, I would > use the RESPONDER-LIFETIME notify instead. > > Stephane. > > > ----- Original Message ----- > From: > To: > Sent: Friday, November 17, 2000 9:15 AM > Subject: RE: ISAKMP_RESPONDER_LIFETIME (Could it be removed?) > > > > I noticed that some implementations actually allow a reply with an > > SA with different lifetimes so if the reply contains a > smaller lifetime > > means that > > the other peer is using a smaller lifetime. In these cases > > RESPONDER_LIFETIME is actually useless. > > Is it mandatory that the SA in the reply has exactly the same > > lifetime or it can be smaller? > > I think taht would be a good solution for a further version > of IKE to get > > rid of the RESPONDER_LIFETIME. Anyway it doesn't appear to > be used too > much. > > Any coments? > > > > Toni > > > > -----Original Message----- > > From: EXT Tero Kivinen [mailto:kivinen@ssh.fi] > > Sent: 16. November 2000 22:12 > > To: antonio.barrera@nokia.com > > Cc: ipsec@lists.tislabs.com > > Subject: ISAKMP_RESPONDER_LIFETIME > > > > > > antonio.barrera@nokia.com writes: > > > IPSEC DOI question: > > > > > > Is the ISAKMP_RESPONDER_LIFETIME notification payload supposed to > > > send only the lifetime (seconds) or also the lifesize (KBytes)? > > > > Yes, I think both are allowed. > > > > > And if both can be send, should they both be send > together in the same > > > ISAKMP Notification payload (Of course same SA) or in 2 > different ones? > > > > I would say that they must be only one notification, > containing both. > > -- > > 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 Nov 19 07:29:41 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09385; Sun, 19 Nov 2000 07:29:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05934 Sun, 19 Nov 2000 09:05:41 -0500 (EST) To: ipsec@lists.tislabs.com Subject: default lifetime X-Mailer: Cue version 0.6 (000609-1000/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20001119230852I.sakane@ydc.co.jp> Date: Sun, 19 Nov 2000 23:08:52 +0900 From: "Shoichi 'Ne' Sakane" X-Dispatcher: imput version 990905(IM130) Lines: 16 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The section 4.5 of RFC2407 says that the default SA life duration is 8 hours. Could someone tell me where the value is derived ? Regards, /Shoichi `NE' Sakane @ KAME project/ 4.5 IPSEC Security Association Attributes : Class Values : SA Duration : If unspecified, the default value shall be assumed to be 28800 seconds (8 hours). From owner-ipsec@lists.tislabs.com Sun Nov 19 12:06:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA23204; Sun, 19 Nov 2000 12:06:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06327 Sun, 19 Nov 2000 13:45:29 -0500 (EST) Message-Id: <200011191848.TAA09205@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@lists.tislabs.com Cc: Richard Draves Subject: RFC 2401 section 5.2.1 Date: Sun, 19 Nov 2000 19:48:32 +0100 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In the inbound processing section 5.2.1 the RFC 2401 (IPsec architecture) specifies: 1. Use the packet's destination address (outer IP header), IPsec protocol, and SPI to look up the SA in the SAD. If the SA lookup fails, drop the packet and log/report the error. 2. Use the SA found in (1) to do the IPsec processing, e.g., authenticate and decrypt. This step includes matching the packet's (Inner Header if tunneled) selectors to the selectors in the SA. Local policy determines the specificity of the SA selectors (single value, list, range, wildcard). In general, a packet's source address MUST match the SA selector value. ... Do (1) and (2) for every IPsec header until a Transport Protocol Header or an IP header that is NOT for this system is encountered. Keep track of what SAs have been used and their order of application. How this was intepreted in current implementations: - is the packet's the source address checked in transport mode? - is the packet's outer source address checked in destination mode? - when are the checks done (before, ie. at the end of the lookup routine, after, ie. after the processing of all IPsec headers)? If you know it, what is the rationale? Regards Francis.Dupont@enst-bretagne.fr PS: with the exception of KAME (no check), all open source implementations I have seen are a bit paranoic, ie. they check all source addresses as soon as possible. From owner-ipsec@lists.tislabs.com Sun Nov 19 15:11:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA00658; Sun, 19 Nov 2000 15:11:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06735 Sun, 19 Nov 2000 17:16:57 -0500 (EST) From: "Joseph D. Harwood" To: "Francis Dupont" , Cc: "Richard Draves" Subject: RE: RFC 2401 section 5.2.1 Date: Sun, 19 Nov 2000 14:19:49 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C05233.C7118DC0" 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: <200011191848.TAA09205@givry.rennes.enst-bretagne.fr> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C05233.C7118DC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I think you're asking about when source address checks are disabled on inbound packets. My interpretation of this is that it's for ICMP error messages in Tunnel Mode that are generated by a router other than the Security Gateway that is the ingress point of the tunnel (see RFC 2401 section 6). Something like this: H0 ---- SG0 ==== SG1 ---- R1 ---- H1 If SG0 and SG1 have established a tunnel between themselves specifically for non-host generated ICMP error messages, and R1 detects an error in a packet going from H0 to H1, the ICMP error message will be carried on the tunnel between SG0 and SG1 even though the (inner) source address (R1) doesn't match the SA's source address (SG1). If SG0 doesn't disable source address checks for this specific case the error message will be discarded because the source address check will fail. I'd be curious to hear from folks out there if (1) they agree this situation was the intent of RFC2401 (2) they agree this is a compliant way to handle non-host generated ICMP error messages (3) their Security Gateway product implements this feature (4) how (else) their Security Gateway product handles non-host generated ICMP error messages 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 Francis Dupont > Sent: Sunday, November 19, 2000 10:49 AM > To: ipsec@lists.tislabs.com > Cc: Richard Draves > Subject: RFC 2401 section 5.2.1 > > > In the inbound processing section 5.2.1 the RFC 2401 (IPsec architecture) > specifies: > 1. Use the packet's destination address (outer IP header), > IPsec protocol, and SPI to look up the SA in the SAD. If > the SA lookup fails, drop the packet and log/report the > error. > > 2. Use the SA found in (1) to do the IPsec processing, e.g., > authenticate and decrypt. This step includes matching the > packet's (Inner Header if tunneled) selectors to the > selectors in the SA. Local policy determines the > specificity of the SA selectors (single value, list, > range, wildcard). In general, a packet's source address > MUST match the SA selector value. > ... > Do (1) and (2) for every IPsec header until a Transport > Protocol Header or an IP header that is NOT for this > system is encountered. Keep track of what SAs have been > used and their order of application. > > How this was intepreted in current implementations: > - is the packet's the source address checked in transport mode? > - is the packet's outer source address checked in destination mode? > - when are the checks done (before, ie. at the end of the lookup > routine, after, ie. after the processing of all IPsec headers)? > If you know it, what is the rationale? > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: with the exception of KAME (no check), all open source implementations > I have seen are a bit paranoic, ie. they check all source addresses > as soon as possible. > ------=_NextPart_000_0000_01C05233.C7118DC0 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_0000_01C05233.C7118DC0-- From owner-ipsec@lists.tislabs.com Sun Nov 19 23:37:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA27357; Sun, 19 Nov 2000 23:37:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA07745 Mon, 20 Nov 2000 01:11:24 -0500 (EST) Message-ID: <7695E2F6903F7A41961F8CF888D87EA8014691D3@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: ipsec@lists.tislabs.com Cc: Francis Dupont Subject: RE: RFC 2401 section 5.2.1 Date: Sun, 19 Nov 2000 22:11:26 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To give the ipsec list some background for Francis's question: Over on the mobile-ip list, we've been discussing how Mobile IPv6 should interact with IPsec. A mobile node has both a Home Address and a Care-Of Address. When the mobile node sends a packet, the source address in the IPv6 header is the Care-Of address and the Home Address is put in a Home Address option. When the mobile node makes a security association or looks up security policies, it uses its Home Address. (So when the mobile node moves and gets a new Care-Of Address, it doesn't affect the security associations.) The current draft specifies that Binding Updates MUST be protected by AH and that the Home Address option MUST appear in a destination options header before the AH header and the Binding Update option MUST appear in a destination options header after the AH header. I've been arguing that this is too restrictive: instead Mobile IPv6 should allow either AH or ESP to protect Binding Update option, depending on policy. In the case of ESP, the Home Address option and the Binding Update option would appear in a destination options header after the ESP header so they are appropriately protected. The question is, how will this interact on the receiver with the provisions of RFC 2401 section 5.2.1. I've been arguing that the following implementation style is possible: - when the ESP header is processed, the destination address, SPI, and IPsec protoocol are used to find the SA - the receiver uses the SA to authenticate/decrypt - finally we get to the point of the discussion: section 5.2.1 requires that the packet's source address be checked against the SA. In this case, we want to check the Home Address against the SA. But the Home Address hasn't been seen yet - it's in a Home Address option in the next header. I think an implementation can either look ahead to find the Home Address (much like you look ahead to find selectors in the transport header), *or* an implementation can "lazy evaluate" this check, postponing it until after the destination options header is processed. Some questions: a) Do you agree that Mobile IPv6's requirement that AH be used and not ESP is too restrictive? b) Is the receiver processing that I'm proposing legitimate? c) If Mobile IPv6 support is added to your IPsec implementation, would this Home Address processing be unduly difficult for your implementation to support? Thanks, Rich > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Sunday, November 19, 2000 10:49 AM > To: ipsec@lists.tislabs.com > Cc: Richard Draves > Subject: RFC 2401 section 5.2.1 > > > In the inbound processing section 5.2.1 the RFC 2401 (IPsec > architecture) > specifies: > 1. Use the packet's destination address (outer IP header), > IPsec protocol, and SPI to look up the SA in > the SAD. If > the SA lookup fails, drop the packet and log/report the > error. > > 2. Use the SA found in (1) to do the IPsec > processing, e.g., > authenticate and decrypt. This step includes > matching the > packet's (Inner Header if tunneled) selectors to the > selectors in the SA. Local policy determines the > specificity of the SA selectors (single value, list, > range, wildcard). In general, a packet's source address > MUST match the SA selector value. > ... > Do (1) and (2) for every IPsec header until a Transport > Protocol Header or an IP header that is NOT for this > system is encountered. Keep track of what SAs have been > used and their order of application. > > How this was intepreted in current implementations: > - is the packet's the source address checked in transport mode? > - is the packet's outer source address checked in destination mode? > - when are the checks done (before, ie. at the end of the lookup > routine, after, ie. after the processing of all IPsec headers)? > If you know it, what is the rationale? > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: with the exception of KAME (no check), all open source > implementations > I have seen are a bit paranoic, ie. they check all source addresses > as soon as possible. > From owner-ipsec@lists.tislabs.com Mon Nov 20 03:49:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA27334; Mon, 20 Nov 2000 03:49:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA08638 Mon, 20 Nov 2000 05:22:03 -0500 (EST) X-Authentication-Warning: loki.research.nokia.com: Host hed040-232.research.nokia.com [172.21.40.232] claimed to be hews0169nrc From: "Markku Savela" To: Subject: RE: RFC 2401 section 5.2.1 Date: Mon, 20 Nov 2000 12:22:56 +0200 Message-ID: <000001c052db$da7d3cd0$e82815ac@hews0169nrc.research.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA8014691D3@red-msg-06.redmond.corp.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: EXT Richard Draves > In this case, we want to check the Home Address > against the SA. But the Home Address hasn't been > seen yet - it's in a Home Address option in the > next header. ..or even later headers. Nothing says it must follow the IPSEC headers. > I think an implementation can either look ahead to > find the Home Address (much like you look ahead to > find selectors in the transport header), *or* > an implementation can "lazy evaluate" this check, > postponing it until after the destination options > header is processed. > Some questions: > a) Do you agree that Mobile IPv6's requirement that > AH be used and not ESP > is too restrictive? Too restrictive. Decision should be on the policy writer, not hardcode in to the implementations. > b) Is the receiver processing that I'm proposing legitimate? > c) If Mobile IPv6 support is added to your IPsec > implementation, would this Home Address processing > be unduly difficult for your implementation to > support? Not after realizing that the "lazy evaluate" is the only one that really works easily (at least for me). I had to go to "lazy evaluation" on my implementation, 1) because after processing the IPSEC headers, there might be other extension headers before the transport layer. => Cannot check policy because skipping unknown extension headers is impossible [one cannot know the structure of unknown extension headers. In my architecture, there is no fixed set of supported headers. When new extension header is defined, the existing stack can be made to support it just by writing a loadable handler for it.] 2) what now happens is that my "IPSEC AH/ESP" handler gets called for each AH and ESP, and also just before passing the packet to the upper layer. The SA's of AH and ESP are remembered, and the policy check occurs at the call that happens before upper layer. Thus, the next header in turn at that point is always the upper layer header and easily looked at. The src and dst are the current "effective" ones. 3) I presume that whatever logic is decided on Home Address option handling, can be now fitted into this fairly easily. On receive side, the processing is fairly deterministic. I'm more uncertain about the outbound direction. How does the IPSEC required by Binding Update activate (enable destination options in selectors -- I don't like that)? What to do if IPSEC requirement of Binding Update and some other security policy are in conflict (require different protection). Prevent "piggybacked" Binding updates, send them always separate? From owner-ipsec@lists.tislabs.com Mon Nov 20 06:20:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07657; Mon, 20 Nov 2000 06:20:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09439 Mon, 20 Nov 2000 08:23:14 -0500 (EST) Message-ID: <44050464.974721849507.JavaMail.Administrator@hvwww5> Date: Mon, 20 Nov 2000 04:04:09 -0800 (PST) From: Arvind Devarajan To: ipsec@lists.tislabs.com Subject: Doubt regarding sequence number.... Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="44052466.974721849507.JavaMail.Administrator@hvwww5" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --44052466.974721849507.JavaMail.Administrator@hvwww5 Content-Type: text/plain Content-Transfer-Encoding: 7bit hi, i have a doubt regarding generation of the sequence numbers in the AH and the ESP headers. is this sequence number per packet, or, per protocol? assuming a situation like this: [IP] [AH] [ESP] [Upper] is the sequence number in both AH and ESP in the above situation the same? or, should i have separate counters for AH and ESP? What about a situation like this: [IP] [AH] [AH] [ESP] [Upper] (Though might not be used, this is a possibility) regards, arvind. -------------------------------------------------------------------------- Global Internet phone calls, voicemail, fax, e-mail and instant messaging. Sign-up today for FREE account at http://www.hotvoice.com --44052466.974721849507.JavaMail.Administrator@hvwww5-- From owner-ipsec@lists.tislabs.com Mon Nov 20 09:55:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00933; Mon, 20 Nov 2000 09:55:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10085 Mon, 20 Nov 2000 11:44:35 -0500 (EST) Message-ID: <7695E2F6903F7A41961F8CF888D87EA80146922E@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: Markku Savela Cc: ipsec@lists.tislabs.com, "Mobile IP (E-mail)" Subject: RE: RFC 2401 section 5.2.1 Date: Mon, 20 Nov 2000 08:42:37 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm cc'ing the mobile-ip list - I hope this works better than the last time I tried to send a message to both ipsec & mobile-ip. Our implementation uses the "lazy-evaluate" strategy, very much like you describe and for the same reasons. The security policy questions that you raise at the end of our message have not yet been resolved satisfactorily, that I know of. Thanks, Rich > -----Original Message----- > From: Markku Savela [mailto:Markku.Savela@research.nokia.com] > Sent: Monday, November 20, 2000 2:23 AM > To: ipsec@lists.tislabs.com > Subject: RE: RFC 2401 section 5.2.1 > > > > > From: EXT Richard Draves > > > In this case, we want to check the Home Address > > against the SA. But the Home Address hasn't been > > seen yet - it's in a Home Address option in the > > next header. > > ..or even later headers. Nothing says it must follow the > IPSEC headers. > > > I think an implementation can either look ahead to > > find the Home Address (much like you look ahead to > > find selectors in the transport header), *or* > > an implementation can "lazy evaluate" this check, > > postponing it until after the destination options > > header is processed. > > > Some questions: > > a) Do you agree that Mobile IPv6's requirement that > > AH be used and not ESP > > is too restrictive? > > Too restrictive. Decision should be on the policy writer, not > hardcode in to > the implementations. > > > b) Is the receiver processing that I'm proposing legitimate? > > > c) If Mobile IPv6 support is added to your IPsec > > implementation, would this Home Address processing > > be unduly difficult for your implementation to > > support? > > Not after realizing that the "lazy evaluate" is the only one > that really > works easily (at least for me). I had to go to "lazy evaluation" on my > implementation, > > 1) because after processing the IPSEC headers, there might be other > extension headers before the transport layer. => Cannot check > policy because > skipping unknown extension headers is impossible [one cannot know the > structure of unknown extension headers. In my architecture, > there is no > fixed set of supported headers. When new extension header is > defined, the > existing stack can be made to support it just by writing a > loadable handler > for it.] > > 2) what now happens is that my "IPSEC AH/ESP" handler gets > called for each > AH and ESP, and also just before passing the packet to the > upper layer. The > SA's of AH and ESP are remembered, and the policy check > occurs at the call > that happens before upper layer. Thus, the next header in > turn at that point > is always the upper layer header and easily looked at. The > src and dst are > the current "effective" ones. > > 3) I presume that whatever logic is decided on Home Address > option handling, > can be now fitted into this fairly easily. > > On receive side, the processing is fairly deterministic. I'm > more uncertain > about the outbound direction. How does the IPSEC required by > Binding Update > activate (enable destination options in selectors -- I don't > like that)? > What to do if IPSEC requirement of Binding Update and some > other security > policy are in conflict (require different protection). > Prevent "piggybacked" > Binding updates, send them always separate? > From owner-ipsec@lists.tislabs.com Mon Nov 20 09:55:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00932; Mon, 20 Nov 2000 09:55:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10066 Mon, 20 Nov 2000 11:41:26 -0500 (EST) From: tomd@sacefcu.org To: ipsec@lists.tislabs.com Message-ID: <3A195403.ED7D87D8@sacefcu.org> Date: Mon, 20 Nov 2000 10:40:36 -0600 Organization: SACEFCU X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 Subject: Question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I know that this is probably not the right list for this post, but I'm at my wits end.... Does anyone know where I can locate a Shiva VPN Client mail list? I've done several searchs but have come up w/nothing. Any help would be appreciated. Tom From owner-ipsec@lists.tislabs.com Mon Nov 20 11:22:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05995; Mon, 20 Nov 2000 11:22:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10779 Mon, 20 Nov 2000 13:12:14 -0500 (EST) Message-ID: <7DAA70BEB463D211AC3E00A0C96B7AB2073D7487@orsmsx41.jf.intel.com> From: "Strahm, Bill" To: "'tomd@sacefcu.org'" , ipsec@lists.tislabs.com Subject: RE: Question Date: Mon, 20 Nov 2000 10:13:18 -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 don't know if this will help, but the Shiva support site is at http://support.intel.com/support/si/vpn/lanrover/ I do not know if they have a mailing list under that somewhere (I didn't see one with a quick glance) Bill (Hoping to help, but not a part of the Shiva VPN team) ______________________________________________ Bill Strahm Programming today is a race between bill.strahm@ software engineers striving to build intel.com bigger and better idiot-proof programs, (503) 264-4632 and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.--Rich Cook I am not speaking for Intel. And Intel rarely speaks for me > -----Original Message----- > From: tomd@sacefcu.org [mailto:tomd@sacefcu.org] > Sent: Monday, November 20, 2000 8:41 AM > To: ipsec@lists.tislabs.com > Subject: Question > > > I know that this is probably not the right list for this post, but I'm > at my wits end.... > > > Does anyone know where I can locate a Shiva VPN Client mail > list? I've > done several searchs but have come up w/nothing. > > Any help would be appreciated. > > Tom > From owner-ipsec@lists.tislabs.com Mon Nov 20 12:15:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA09304; Mon, 20 Nov 2000 12:15:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10974 Mon, 20 Nov 2000 14:06:34 -0500 (EST) X-Authentication-Warning: nurkka.hel.fi.ssh.com: mstenber set sender to mstenber@ssh.com using -f To: "jshukla" Cc: , "Michael Richardson" Subject: Re: I-D ACTION:draft-shukla-ipsec-nat-qos-compatible-security-00.txt References: <200011140428.eAE4Sut03731@sandelman.ottawa.on.ca> <000901c04e69$5b1f3b80$98b12304@ffb5b> From: Markus Stenberg Date: 20 Nov 2000 17:51:33 +0200 In-Reply-To: "jshukla"'s message of "Tue, 14 Nov 2000 10:33:15 -0800" Message-ID: Lines: 32 User-Agent: Gnus/5.0803 (Gnus v5.8.3) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "jshukla" writes: > Scott had reached an incorrect conclusion and > my previous e-mail addresses that issue. As > far as RSIP, ESPUDP etc. are concerned, please > take a look at the Section 5 of my draft where I > talk about the existing solutions and their > drawbacks. I also give references to other > drafts and RFCs that talk about the problems > with existing solutions in greater detail. from 5.3: The drawbacks of this approach are that it will require modifications to existing NAT implementations, and will have overhead in book-keeping to ensure that no two hosts use the same port number. To be specific, it does NOT require changes to the intervening NAT devices on network path between IPsec endpoints. One endpoint MAY need to contain NAT implementation, which obviously is nonstandard as it performs (host,port) <> internal-host mapping in some cases. > regards, > Jayant -Markus -- Simplicity does not precede complexity, but follows it. >From ACM's SIGPLAN publication, (September, 1982), Article "Epigrams in Programming", by Alan J. Perlis of Yale University. From owner-ipsec@lists.tislabs.com Mon Nov 20 12:51:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA10938; Mon, 20 Nov 2000 12:51:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11587 Mon, 20 Nov 2000 14:38:41 -0500 (EST) Date: Mon, 20 Nov 2000 14:29:50 -0500 (EST) From: Henry Spencer To: Richard Draves cc: ipsec@lists.tislabs.com, Francis Dupont Subject: RE: RFC 2401 section 5.2.1 In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA8014691D3@red-msg-06.redmond.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 Sun, 19 Nov 2000, Richard Draves wrote: > a) Do you agree that Mobile IPv6's requirement that AH be used and not ESP > is too restrictive? Strongly agree. We'd like to see AH die entirely, and hence are opposed to having any other standard demand its continued survival. > b) Is the receiver processing that I'm proposing legitimate? I'd say it is, with the caveat that I haven't worked with IPv6 enough yet to really have a good feel for its header processing. > c) If Mobile IPv6 support is added to your IPsec implementation, would this > Home Address processing be unduly difficult for your implementation to > support? FreeS/WAN is still far enough away from IPv6 support of any flavor that it's hard to be sure, but it doesn't sound too bad. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Nov 20 18:55:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA18333; Mon, 20 Nov 2000 18:55:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA13717 Mon, 20 Nov 2000 20:25:55 -0500 (EST) To: Henry Spencer cc: Richard Draves , ipsec@lists.tislabs.com, Francis Dupont In-reply-to: henry's message of Mon, 20 Nov 2000 14:29:50 EST. 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: RFC 2401 section 5.2.1 From: itojun@iijlab.net Date: Tue, 21 Nov 2000 10:25:43 +0900 Message-ID: <3984.974769943@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >On Sun, 19 Nov 2000, Richard Draves wrote: >> a) Do you agree that Mobile IPv6's requirement that AH be used and not ESP >> is too restrictive? >Strongly agree. We'd like to see AH die entirely, and hence are opposed >to having any other standard demand its continued survival. (again this holy war on AH) I don't. if you use transport mode IPsec heavily (unlike today's VPN-only situation) how can you protect your header portion? since the introduction of IPsec there are so many protocols that rely upon the use of IPsec to protect it. I wonder what is their underlying security model. itojun From owner-ipsec@lists.tislabs.com Tue Nov 21 05:53:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10466; Tue, 21 Nov 2000 05:53:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA16000 Tue, 21 Nov 2000 07:33:59 -0500 (EST) Message-ID: <3A1A6B67.6F5176C6@rd.francetelecom.fr> Date: Tue, 21 Nov 2000 13:32:39 +0100 From: Jean-Michel COMBES Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D X-Mailer: Mozilla 4.7 [fr] (WinNT; U) X-Accept-Language: fr MIME-Version: 1.0 To: itojun@iijlab.net CC: Henry Spencer , Richard Draves , ipsec@lists.tislabs.com, Francis Dupont , mobile-ip@standards.nortelnetworks.com Subject: Re: RFC 2401 section 5.2.1 References: <3984.974769943@coconut.itojun.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk itojun@iijlab.net a écrit : > >On Sun, 19 Nov 2000, Richard Draves wrote: > >> a) Do you agree that Mobile IPv6's requirement that AH be used and not ESP > >> is too restrictive? > >Strongly agree. We'd like to see AH die entirely, and hence are opposed > >to having any other standard demand its continued survival. > > (again this holy war on AH) > I don't. if you use transport mode IPsec heavily (unlike today's > VPN-only situation) how can you protect your header portion? JMC : You will use a Alternate Care-of Address Sub-Option, containing the CoA ( == IPv6 Hdr Src Addr), behind the DO-BU, but, IMO, this is a heavy solution : we have the same thing twice ... In my point of view, DO-HA before AH/ESP plus AH mecanism is the simplest solution. > > since the introduction of IPsec there are so many protocols that rely > upon the use of IPsec to protect it. I wonder what is their underlying > security model. > > itojun JMC : One thing I don't understand is what are the advantages to have the DO-HA behind AH/ESP ? If it's a question of privacy (ie. hiding the MN location), I think that doesn't resolve the problem unless to hide the Routing Header, which contains MN's Home Address, coming from the Home Agent for the BAck. On the other hand, having the DO-HA before the AH/ESP Hdr, will simplify considerably filtering policy in FW (ie. filtering based on MN Home Address). Regards. -- France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@rd.francetelecom.fr Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 From owner-ipsec@lists.tislabs.com Tue Nov 21 08:21:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25080; Tue, 21 Nov 2000 08:21:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16778 Tue, 21 Nov 2000 10:15:27 -0500 (EST) To: Jean-Michel COMBES cc: Henry Spencer , Richard Draves , ipsec@lists.tislabs.com, Francis Dupont , mobile-ip@standards.nortelnetworks.com In-reply-to: jeanmichel.combes's message of Tue, 21 Nov 2000 13:32:39 +0100. <3A1A6B67.6F5176C6@rd.francetelecom.fr> 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: RFC 2401 section 5.2.1 From: itojun@iijlab.net Date: Wed, 22 Nov 2000 00:16:29 +0900 Message-ID: <14757.974819789@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> since the introduction of IPsec there are so many protocols that rely >> upon the use of IPsec to protect it. I wonder what is their underlying >> security model. here are some examples of these. not sure if they require header protection, but they are all tricky - issues with multicast issue (source address validation gets tricky), as well as bootstrap issue. most of routing protocol needs to somehow protect IPv6 source address, as they will use (peers') IPv6 source address as the nexthop router information. - RIPng (RFC2080, see section 4) - OSPFv3 (RFC2740, see abstract and couple of other places) - neighbor discovery and stateless autoconfiguration (RFC2461 section 3.1, RFC2462 p19) -> tricky chicken-and-egg problem exist, about how to setup SA - router renumbering (RFC2894, section 3 and 7.1) itojun From owner-ipsec@lists.tislabs.com Tue Nov 21 08:29:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25538; Tue, 21 Nov 2000 08:29:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16814 Tue, 21 Nov 2000 10:35:28 -0500 (EST) Date: Tue, 21 Nov 2000 10:35:14 -0500 (EST) From: Henry Spencer To: itojun@iijlab.net cc: ipsec@lists.tislabs.com, mobile-ip@standards.nortelnetworks.com Subject: Re: RFC 2401 section 5.2.1 In-Reply-To: <14757.974819789@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 22 Nov 2000 itojun@iijlab.net wrote: > most of routing protocol needs to somehow protect IPv6 source address, > as they will use (peers') IPv6 source address as the nexthop router > information... Many of the death-to-AH enthusiasts also favoring killing transport mode and doing everything with tunnel mode, in which case the inner headers -- the ones that would be visible to applications -- are fully protected. (Notably, they can be encrypted as well as authenticated, if desired.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Nov 21 08:42:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25874; Tue, 21 Nov 2000 08:42:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16864 Tue, 21 Nov 2000 10:43:21 -0500 (EST) To: Henry Spencer cc: ipsec@lists.tislabs.com, mobile-ip@standards.nortelnetworks.com In-reply-to: henry's message of Tue, 21 Nov 2000 10:35:14 EST. 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: RFC 2401 section 5.2.1 From: itojun@iijlab.net Date: Wed, 22 Nov 2000 00:43:55 +0900 Message-ID: <15119.974821435@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> most of routing protocol needs to somehow protect IPv6 source address, >> as they will use (peers') IPv6 source address as the nexthop router >> information... >Many of the death-to-AH enthusiasts also favoring killing transport mode >and doing everything with tunnel mode, in which case the inner headers -- >the ones that would be visible to applications -- are fully protected. >(Notably, they can be encrypted as well as authenticated, if desired.) do we want to use tunnel mode on non-VPN ipsec exchanges? I don't think so. itojun From owner-ipsec@lists.tislabs.com Tue Nov 21 08:48:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26077; Tue, 21 Nov 2000 08:48:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16964 Tue, 21 Nov 2000 10:57:14 -0500 (EST) Date: Tue, 21 Nov 2000 10:57:08 -0500 (EST) From: Henry Spencer To: itojun@iijlab.net cc: ipsec@lists.tislabs.com, mobile-ip@standards.nortelnetworks.com Subject: Re: RFC 2401 section 5.2.1 In-Reply-To: <15119.974821435@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 22 Nov 2000 itojun@iijlab.net wrote: > >Many of the death-to-AH enthusiasts also favoring killing transport mode > >and doing everything with tunnel mode... > > do we want to use tunnel mode on non-VPN ipsec exchanges? > I don't think so. Why not? It can do everything transport mode does. (In particular, it is perfectly capable of working host-to-host.) "Recommendation 1: *Eliminate transport mode*. ...we do not know why IPsec has two modes... The extra cost of a second mode (in terms of added complexity and resulting loss of security) is huge..." -- Ferguson & Schneier It would be sensible to retain both if transport mode was the fundamental IPsec mode and tunnel mode was *just* IPIP tunneling over a transport-mode connection. But it's not. (If it were, tunnel mode could be explained in a single footnote in RFC 2401, rather than having implications everywhere.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Nov 21 09:03:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA26859; Tue, 21 Nov 2000 09:03:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA17040 Tue, 21 Nov 2000 11:10:00 -0500 (EST) Date: Tue, 21 Nov 2000 11:09:11 -0500 (EST) From: Henry Spencer To: itojun@iijlab.net cc: ipsec@lists.tislabs.com Subject: Re: RFC 2401 section 5.2.1 In-Reply-To: <3984.974769943@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 21 Nov 2000 itojun@iijlab.net wrote: > >Strongly agree. We'd like to see AH die entirely... > > (again this holy war on AH) > I don't. if you use transport mode IPsec heavily (unlike today's > VPN-only situation) how can you protect your header portion? Why would you have to use transport mode IPsec heavily? What problem does it solve that tunnel mode doesn't? Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Nov 21 11:27:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06735; Tue, 21 Nov 2000 11:27:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17811 Tue, 21 Nov 2000 13:28:16 -0500 (EST) Message-ID: <3A1ABF07.EFE29FE9@isi.edu> Date: Tue, 21 Nov 2000 10:29:27 -0800 From: Lars Eggert Organization: USC Information Sciences Institute X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en, de MIME-Version: 1.0 CC: ipsec@lists.tislabs.com Subject: Re: RFC 2401 section 5.2.1 References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms00EA3721019B0D691400BEC6" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms00EA3721019B0D691400BEC6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Henry Spencer wrote: > > On Tue, 21 Nov 2000 itojun@iijlab.net wrote: > > >Strongly agree. We'd like to see AH die entirely... > > > > (again this holy war on AH) > > I don't. if you use transport mode IPsec heavily (unlike today's > > VPN-only situation) how can you protect your header portion? > > Why would you have to use transport mode IPsec heavily? What problem does > it solve that tunnel mode doesn't? Tunnel mode (in current implementations I'm aware of, at least) does not support dynamic routing inside a VPN, since IPsec tunnels aren't represented in routing tables. What does tunnel mode give you that IPIP tunnels + IPsec transport mode don't? Inbound processing for both should be identical, since you can't tell the difference by looking at the packet. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms00EA3721019B0D691400BEC6 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIIwYJKoZIhvcNAQcCoIIIFDCCCBACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BfQwggLYMIICQaADAgECAgMDIwUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDgyNDIwMzAwOFoXDTAxMDgyNDIwMzAw OFowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAz1yfcNs53rvhuw8gSDvr2+/snP8GduYY7x7WkJdyvcwb4oipNpWYIkMGP214 Zv1KrgvntGaG+jeugAGQt0n64VusgcIzQ6QDRtnMgdQDTAkVSQ2eLRSQka+nAPx6SFKJg79W EEHmgKQBMtZdMBYtYv/mTOcpm7jTJVg+7W6n04UCAwEAAaN3MHUwKgYFK2UBBAEEITAfAgEA MBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1 MAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUiKvxYINmVfTkWMdGHcBhvSPXw4wwDQYJKoZI hvcNAQEEBQADgYEAi65fM/jSCaPhRoA9JW5X2FktSFhE5zkIpFVPpv33GWPPNrncsK13HfZm s0B1rNy2vU7UhFI/vsJQgBJyffkLFgMCjp3uRZvBBjGD1q4yjDO5yfMMjquqBpZtRp5op3lT d01faA58ZCB5sxCb0ORSxvXR8tc9DJO0JIpQILa6vIAwggMUMIICfaADAgECAgELMA0GCSqG SIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9D ZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTkwOTE2MTQwMTQwWhcNMDEwOTE1MTQwMTQwWjCBlDELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoT BlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNv bmFsIEZyZWVtYWlsIFJTQSAxOTk5LjkuMTYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALNpWpfU0BYLerXFXekhnCNyzRJMS/d+z8f7ynIk9EJSrFeV43theheE5/1yOTiUtOrtZaeS Bl694GX2GbuUeXZMPrlocHWEHPQRdAC8BSxPCQMXMcz0QdRyxqZd4ohEsIsuxE3x8NaFPmzz lZR4kX5A6ZzRjRVXjsJz5TDeRvVPAgMBAAGjNzA1MBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYD VR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZIhvcNAQEEBQADgYEAa8ZZ6TH6 6bbssQPY33Jy/pFgSOrGVd178GeOxmFw523CpTfYnbcXKFYFi91cdW/GkZDGbGZxE9AQfGuR b4bgITYtwdfqsgmtzy1txoNSm/u7/pyHnfy36XSS5FyXrvx+rMoNb3J6Zyxrc/WG+Z31AG70 HQfOnZ6CYynvkwl+Vd4xggH3MIIB8wIBATCBnDCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEd MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt YWlsIFJTQSAxOTk5LjkuMTYCAwMjBTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMTEyMTE4MjkyN1owIwYJKoZIhvcNAQkEMRYE FMq0317ijfW+IqpDvYtgvX/Y4beuMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G CSqGSIb3DQEBAQUABIGAAeQiusrPRoZKyDcFRp3Fvm+ojaBQCoxOqqnyc0amR5EcyvQ74EFE Dd5WaQ+/qePQtb7kBPOleP7NIOv5ghvdM+/zh6pv+aB7Y6ZnLmBH21w/uoSv1Y7IRJAb+wcD etolnHLwt9bS9ejXmP40bnFhhYSvrK/4cTvtOURgF+o1aC0= --------------ms00EA3721019B0D691400BEC6-- From owner-ipsec@lists.tislabs.com Tue Nov 21 11:27:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06748; Tue, 21 Nov 2000 11:27:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17778 Tue, 21 Nov 2000 13:21:07 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14874.48403.331976.88667@thomasm-u1.cisco.com> Date: Tue, 21 Nov 2000 10:21:07 -0800 (PST) To: Henry Spencer Cc: itojun@iijlab.net, ipsec@lists.tislabs.com Subject: Re: RFC 2401 section 5.2.1 In-Reply-To: References: <3984.974769943@coconut.itojun.org> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > On Tue, 21 Nov 2000 itojun@iijlab.net wrote: > > >Strongly agree. We'd like to see AH die entirely... > > > > (again this holy war on AH) > > I don't. if you use transport mode IPsec heavily (unlike today's > > VPN-only situation) how can you protect your header portion? > > Why would you have to use transport mode IPsec heavily? What problem does > it solve that tunnel mode doesn't? Unless you're talking about Schneier's transport-is-really-tunnel-with-header-compression contention, there's an obvious benefit of bytes on the wire. Mike From owner-ipsec@lists.tislabs.com Tue Nov 21 11:47:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA08437; Tue, 21 Nov 2000 11:47:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA17909 Tue, 21 Nov 2000 14:01:24 -0500 (EST) Message-ID: <7695E2F6903F7A41961F8CF888D87EA80130C99F@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: "'itojun@iijlab.net'" , Henry Spencer Cc: ipsec@lists.tislabs.com, Francis Dupont Subject: RE: RFC 2401 section 5.2.1 Date: Tue, 21 Nov 2000 10:40:12 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >On Sun, 19 Nov 2000, Richard Draves wrote: > >> a) Do you agree that Mobile IPv6's requirement that AH be > used and not ESP > >> is too restrictive? > >Strongly agree. We'd like to see AH die entirely, and hence > are opposed > >to having any other standard demand its continued survival. > > (again this holy war on AH) I'm not trying to rule out AH - that's a different argument and I don't know enough to have a strong opinion. I just want the Mobile IPv6 spec to have the flexibility to allow either AH or ESP. Thanks, Rich From owner-ipsec@lists.tislabs.com Tue Nov 21 14:43:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14395; Tue, 21 Nov 2000 14:43:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA18486 Tue, 21 Nov 2000 16:46:39 -0500 (EST) From: "Joseph D. Harwood" To: "Lars Eggert" Cc: Subject: RE: RFC 2401 section 5.2.1 Date: Tue, 21 Nov 2000 13:47:52 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0023_01C053C1.A4CF0C80" 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: <3A1ABF07.EFE29FE9@isi.edu> X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C053C1.A4CF0C80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > > What does tunnel mode give you that IPIP tunnels + IPsec transport mode > don't? Inbound processing for both should be identical, since you can't > tell the difference by looking at the packet. Not quite identical. After IPsec processing, the received packet's selectors are checked against the SPD to make sure all of the appropriate processing has been performed. In Tunnel mode, these selectors are from the inner (encapsulated) header, in IPIP + IPsec transport these selectors are from the outer header. > > Lars > -- > Lars Eggert Information Sciences Institute > http://www.isi.edu/larse/ University of Southern > California Best Regards, Joseph D. Harwood jharwood@vesta-corp.com www.vesta-corp.com ------=_NextPart_000_0023_01C053C1.A4CF0C80 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_0023_01C053C1.A4CF0C80-- From owner-ipsec@lists.tislabs.com Tue Nov 21 15:03:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA19760; Tue, 21 Nov 2000 15:03:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA18653 Tue, 21 Nov 2000 17:17:55 -0500 (EST) Date: Tue, 21 Nov 2000 17:17:50 -0500 (EST) From: Henry Spencer To: Lars Eggert cc: ipsec@lists.tislabs.com Subject: Re: RFC 2401 section 5.2.1 In-Reply-To: <3A1ABF07.EFE29FE9@isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 21 Nov 2000, Lars Eggert wrote: > > Why would you have to use transport mode IPsec heavily? What problem does > > it solve that tunnel mode doesn't? > > Tunnel mode (in current implementations I'm aware of, at least) does not > support dynamic routing inside a VPN, since IPsec tunnels aren't > represented in routing tables. This is a problem in routing implementation, not IPsec tunnel mode. There is no reason why IPsec tunnels shouldn't be represented in routing tables. > What does tunnel mode give you that IPIP tunnels + IPsec transport mode > don't? Most notably, IPsec SPD checking of the inner headers, which is of some small importance for network security. > Inbound processing for both should be identical, since you can't > tell the difference by looking at the packet. Life would be simpler if that were so, but it's not. See RFC 2401. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Nov 21 17:55:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA11904; Tue, 21 Nov 2000 17:55:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA19034 Tue, 21 Nov 2000 19:55:34 -0500 (EST) to: ipsec@lists.tislabs.com, mobile-ip@standards.nortelnetworks.com In-reply-to: henry's message of Tue, 21 Nov 2000 10:57:08 EST. 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: RFC 2401 section 5.2.1 From: itojun@iijlab.net Date: Wed, 22 Nov 2000 09:56:40 +0900 Message-ID: <21716.974854600@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> do we want to use tunnel mode on non-VPN ipsec exchanges? >> I don't think so. >Why not? It can do everything transport mode does. (In particular, it is >perfectly capable of working host-to-host.) >"Recommendation 1: *Eliminate transport mode*. ...we do not know why >IPsec has two modes... The extra cost of a second mode (in terms of added >complexity and resulting loss of security) is huge..." -- Ferguson & Schneier first of all, chews MTU. tunnel-mode-just-for-avoiding-transport-mode does not seem to be the same as transport mode for me. >It would be sensible to retain both if transport mode was the fundamental >IPsec mode and tunnel mode was *just* IPIP tunneling over a transport-mode >connection. But it's not. (If it were, tunnel mode could be explained in >a single footnote in RFC 2401, rather than having implications everywhere.) i still do not get why RFC2401 includes tunnel mode. I believe this was introduced for single reason: to make it easier to negotiate tunnel setup as well as IPsec setup, with IKE. there are enough number of prior art for tunnelling available before 2401 (at least 7 specifications, before and after 2401, use IP protocol #4. 4 specifications use IP protocol #41). if an implementation A handles IPsec tunnel mode as transport mode with tunnels, does it break 2401 conformance? I understand that if the peer i too picky about header field the peer will drop the packet. also I understand we need some trick in IKE code, to setup tunnels AND IPsec transport-mode SAs as necessary. itojun From owner-ipsec@lists.tislabs.com Tue Nov 21 17:56:15 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA12131; Tue, 21 Nov 2000 17:56:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA19040 Tue, 21 Nov 2000 19:56:52 -0500 (EST) to: ipsec@lists.tislabs.com, mobile-ip@standards.nortelnetworks.com In-reply-to: itojun's message of Wed, 22 Nov 2000 09:56:40 JST. <21716.974854600@coconut.itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: RFC 2401 section 5.2.1 From: itojun@iijlab.net Date: Wed, 22 Nov 2000 09:58:00 +0900 Message-ID: <21770.974854680@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > of prior art for tunnelling available before 2401 (at least 7 > specifications, before and after 2401, use IP protocol #4. > 4 specifications use IP protocol #41). typo: 7 specs for protocol #41, 4 specs for protocol #4. itojun From owner-ipsec@lists.tislabs.com Wed Nov 22 02:14:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA16278; Wed, 22 Nov 2000 02:14:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA20324 Wed, 22 Nov 2000 03:52:25 -0500 (EST) X-Authentication-Warning: loki.research.nokia.com: Host hed040-232.research.nokia.com [172.21.40.232] claimed to be hews0169nrc From: "Markku Savela" To: Subject: RE: RFC 2401 section 5.2.1 Date: Wed, 22 Nov 2000 10:53:34 +0200 Message-ID: <000001c05461$b313e400$e82815ac@hews0169nrc.research.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Joseph D. Harwood > Not quite identical. After IPsec processing, the received packet's > selectors are checked against the SPD to make sure all of the > appropriate > processing has been performed. In Tunnel mode, these > selectors are from the > inner (encapsulated) header, in IPIP + IPsec transport these > selectors are > from the outer header. But, the claim was that the sending side can create the tunnel mode packet just by adding the tunnel layer and then applying the standard transport mode processing to packet. Thus, tunnel mode is identical to IPIP + Transport mode. This is what I basicly do, and have not found any interoperatibility problems due to this. On receive side, assuming you implement the "tunnel mode", you need to have the extra logic within the IPSEC processing that "uwraps" the tunnel that follows ESP/AH. First you do AH/ESP processing is plain transport mode, and then decide whether detunneling operation is required. The selectors are matched against the addresses after this processing (with additional check, that if the policy specified a tunnel, the outer src address must also match the tunnel address). [All this talk about inner/outer addresses in RFC-2401, although correct, makes it hard to read. A processing oriented description, like above would be much easily understood.] I don't understand the claims that the presense of the transport mode is complexity. The transport mode is already there and required anyway, and tunnel mode just adds an extra "layer" to the IPSEC processing. From owner-ipsec@lists.tislabs.com Wed Nov 22 15:32:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06197; Wed, 22 Nov 2000 15:32:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22862 Wed, 22 Nov 2000 17:35:58 -0500 (EST) Message-ID: <000601c054d5$78fc9400$19b12304@ffb5b> From: "jshukla" To: References: <200011140428.eAE4Sut03731@sandelman.ottawa.on.ca> <000901c04e69$5b1f3b80$98b12304@ffb5b> Subject: Re: I-D ACTION:draft-shukla-ipsec-nat-qos-compatible-security-00.txt Date: Wed, 22 Nov 2000 14:42:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Markus Stenberg" > > from 5.3: > > The drawbacks of this approach are that it will require > modifications to existing NAT implementations, and will have > overhead in book-keeping to ensure that no two hosts use the same > port number. > > To be specific, it does NOT require changes to the intervening NAT devices > on network path between IPsec endpoints. One endpoint MAY need to contain > NAT implementation, which obviously is nonstandard as it performs > (host,port) <> internal-host mapping in some cases. > As you explained yourself, it does NOT require ANY changes to the NAT devices. In the situations where the effect of NAT must be reversed, some additional functionality is needed and that can be implemented without any modifications to the NAT. I think you are thinking of merging this functionality with the NAT implementation, which is not the case. From owner-ipsec@lists.tislabs.com Wed Nov 22 15:32:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06210; Wed, 22 Nov 2000 15:32:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22909 Wed, 22 Nov 2000 17:51:07 -0500 (EST) Message-ID: <3A1C4DF8.23918D4F@isi.edu> Date: Wed, 22 Nov 2000 14:51:36 -0800 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Henry Spencer , itojun@iijlab.net, ipsec@lists.tislabs.com, mobile-ip@standards.nortelnetworks.com Subject: Re: RFC 2401 section 5.2.1 References: <3A1C47EF.48B0F5C@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Would it be useful to have a discussion of this at the IETF, notably that could support both Mobile-IP and IPSEC participants? (it might take a slightly larger room). Joe From owner-ipsec@lists.tislabs.com Wed Nov 22 15:32:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06212; Wed, 22 Nov 2000 15:32:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22772 Wed, 22 Nov 2000 17:23:03 -0500 (EST) Message-ID: <3A1C4788.9DAC0BA3@isi.edu> Date: Wed, 22 Nov 2000 14:24:08 -0800 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Joseph D. Harwood" CC: Lars Eggert , ipsec@lists.tislabs.com Subject: Re: RFC 2401 section 5.2.1 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Joseph D. Harwood" wrote: > > > > > What does tunnel mode give you that IPIP tunnels + IPsec transport mode > > don't? Inbound processing for both should be identical, since you can't > > tell the difference by looking at the packet. > > Not quite identical. After IPsec processing, the received packet's > selectors are checked against the SPD to make sure all of the appropriate > processing has been performed. In Tunnel mode, these selectors are from the > inner (encapsulated) header, in IPIP + IPsec transport these selectors are > from the outer header. Agreed. It's exactly that difference that allows IPIP+transport to support dynamic routing over per-hop IPSEC'd tunnels. Joe From owner-ipsec@lists.tislabs.com Wed Nov 22 15:32:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06239; Wed, 22 Nov 2000 15:32:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22880 Wed, 22 Nov 2000 17:39:54 -0500 (EST) Message-ID: <3A1C4B77.612130E7@isi.edu> Date: Wed, 22 Nov 2000 14:40:55 -0800 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: itojun@iijlab.net CC: ipsec@lists.tislabs.com, mobile-ip@standards.nortelnetworks.com Subject: Re: RFC 2401 section 5.2.1 References: <21770.974854680@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk itojun@iijlab.net wrote: > > > of prior art for tunnelling available before 2401 (at least 7 > > specifications, before and after 2401, use IP protocol #4. > > 4 specifications use IP protocol #41). > > typo: 7 specs for protocol #41, 4 specs for protocol #4. > > itojun Protocol type 4 inside IP is designated as specifed by RFC 2003. While there may be prior or subsequent references, it has already been delegated to exactly one official standard (standards track): http://www.isi.edu/in-notes/iana/assignments/protocol-numbers Joe From owner-ipsec@lists.tislabs.com Wed Nov 22 15:33:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06255; Wed, 22 Nov 2000 15:33:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22794 Wed, 22 Nov 2000 17:25:25 -0500 (EST) Message-ID: <3A1C47EC.EF58E15@isi.edu> Date: Wed, 22 Nov 2000 14:25:48 -0800 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Henry Spencer CC: Lars Eggert , ipsec@lists.tislabs.com Subject: Re: RFC 2401 section 5.2.1 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer wrote: > > On Tue, 21 Nov 2000, Lars Eggert wrote: > > > Why would you have to use transport mode IPsec heavily? What problem does > > > it solve that tunnel mode doesn't? > > > > Tunnel mode (in current implementations I'm aware of, at least) does not > > support dynamic routing inside a VPN, since IPsec tunnels aren't > > represented in routing tables. > > This is a problem in routing implementation, not IPsec tunnel mode. There > is no reason why IPsec tunnels shouldn't be represented in routing tables. This would require synchronizing updates to the key databases with updates to the routing tables. That would certainly make things more complex, not less. > > What does tunnel mode give you that IPIP tunnels + IPsec transport mode > > don't? > > Most notably, IPsec SPD checking of the inner headers, which is of some > small importance for network security. You can set that rule when you setup the tunnel. It need not be an integrated function of setting the transport IPSEC. Joe From owner-ipsec@lists.tislabs.com Wed Nov 22 15:33:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06257; Wed, 22 Nov 2000 15:33:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22787 Wed, 22 Nov 2000 17:25:20 -0500 (EST) Message-ID: <3A1C47EF.48B0F5C@isi.edu> Date: Wed, 22 Nov 2000 14:25:51 -0800 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Henry Spencer CC: itojun@iijlab.net, ipsec@lists.tislabs.com, mobile-ip@standards.nortelnetworks.com Subject: Re: RFC 2401 section 5.2.1 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer wrote: > > On Wed, 22 Nov 2000 itojun@iijlab.net wrote: > > >Many of the death-to-AH enthusiasts also favoring killing transport mode > > >and doing everything with tunnel mode... > > > > do we want to use tunnel mode on non-VPN ipsec exchanges? > > I don't think so. > > Why not? It can do everything transport mode does. (In particular, it is > perfectly capable of working host-to-host.) There is a contrary view - that transport mode after IP encapsulation does everything tunnel mode does (provided transport mode is implemented properly, e.g., that there are checks available after decryption, in the subsequent passes of IP processing, as required by 2401). See our ID (which is probably recently expired, but is also probably still available: draft-touch-ipsec-vpn) The argument for the contrary view is that tunneling - esp that using protocol type 4 - is a separate protocol technique, and it would be useful to extract out of IPSEC. > "Recommendation 1: *Eliminate transport mode*. ...we do not know why > IPsec has two modes... The extra cost of a second mode (in terms of added > complexity and resulting loss of security) is huge..." -- Ferguson & Schneier Agreed - and if you're going to get rid of one of them, things get much simpler to omit tunnel mode. > It would be sensible to retain both if transport mode was the fundamental > IPsec mode and tunnel mode was *just* IPIP tunneling over a transport-mode > connection. But it's not. (If it were, tunnel mode could be explained in > a single footnote in RFC 2401, rather than having implications everywhere.) There are differences between 2401's definition of encapsulation (particularly the DF bit), but it is not clear they should remain. (either 2401 should prohibit clearing the DF bit on the outer header, or 2003 should permit it. there is no clear reason to have dissenting positions). I'm not clear that _any_ IPIP tunnel over transport mode wouldn't have subsequent implications on IPSEC checks on the interior packet headers. Joe From owner-ipsec@lists.tislabs.com Wed Nov 22 21:15:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA13966; Wed, 22 Nov 2000 21:15:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA23513 Wed, 22 Nov 2000 23:11:09 -0500 (EST) Reply-To: From: "Awan Kumar Sharma" To: "'Markku Savela'" Cc: "IpsecMailingList (E-mail)" Subject: RE: RFC 2401 section 5.2.1 Date: Thu, 23 Nov 2000 09:40:44 +0530 Message-Id: <000701c05503$5a8c9780$6d0c000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <000001c05461$b313e400$e82815ac@hews0169nrc.research.nokia.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, For the past few days, I have seen lots of discussion on the relevance of transport and tunnel modes. Although I am not working on these protocols for a very long time, but I see no reason for the relevance of transport mode over the tunnel mode. The reason being: 1) Ref : RFC 2401, Section 4.1 Definition and scope. It says "In IPv4, a transport mode security protocol header appears immediately after the IP header and any options, and before any higher layer protocols (e.g., TCP or UDP)". i.e. In transport mode, the packet will look like [IP][ESP][HLP]. Here I have taken ESP as an example. Now we see that in this case, ESP will encrypt *only* [HLP] and thus IP is not protected i.e. encrypted. Even if we select authentication in ESP, the IP header is not protected. About Tunnel Mode, RFC 2401 says, "The security protocol header appears after the outer IP header, and before the inner IP header". i.e. In Tunnel Mode, the packet will look like [outer IP][ESP][InnerIP][HLP]. Now we see that ESP can encrypt the inner IP packet thus maintaining its confidentiality. If authentication in ESP is used, the inner IP header is fully authenticated also. And I think a security protocol should work in this manner. So, having this argument, I see no reason for Transport mode being more relevant than the Tunnel Mode. Any suggestion/correction in this regard is most welcome. 2) Now taking up the argument that transport mode with tunneling is same as Tunnel mode in IPSec. The tunneled transport mode protected packet will look like : [OuterIP][InnerIP][ESP][HLP]. If my first point is correct, then we can see the extent of coverage in this case on the same lines as before and compare it with the Tunnel mode protected packet, which will look like, [OuterIP][ESP][InnerIP][HLP]. Again on the same arguments, Tunnel mode will provide better protection compared to Transport mode. Any suggestions or corrections to my arguments are most welcome. Regards, Awan. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Markku Savela > Sent: Wednesday, November 22, 2000 2:24 PM > To: ipsec@lists.tislabs.com > Subject: RE: RFC 2401 section 5.2.1 > > > > -----Original Message----- > > From: Joseph D. Harwood > > > Not quite identical. After IPsec processing, the received packet's > > selectors are checked against the SPD to make sure all of the > > appropriate > > processing has been performed. In Tunnel mode, these > > selectors are from the > > inner (encapsulated) header, in IPIP + IPsec transport these > > selectors are > > from the outer header. > > But, the claim was that the sending side can create the > tunnel mode packet > just by adding the tunnel layer and then applying the > standard transport > mode processing to packet. Thus, tunnel mode is identical to IPIP + > Transport mode. This is what I basicly do, and have not found any > interoperatibility problems due to this. > > On receive side, assuming you implement the "tunnel mode", > you need to have > the extra logic within the IPSEC processing that "uwraps" the > tunnel that > follows ESP/AH. First you do AH/ESP processing is plain > transport mode, and > then decide whether detunneling operation is required. The > selectors are > matched against the addresses after this processing (with > additional check, > that if the policy specified a tunnel, the outer src address > must also match > the tunnel address). > > [All this talk about inner/outer addresses in RFC-2401, > although correct, > makes it hard to read. A processing oriented description, > like above would > be much easily understood.] > > I don't understand the claims that the presense of the > transport mode is > complexity. The transport mode is already there and required > anyway, and > tunnel mode just adds an extra "layer" to the IPSEC processing. > From owner-ipsec@lists.tislabs.com Wed Nov 22 21:24:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA14171; Wed, 22 Nov 2000 21:24:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA23588 Wed, 22 Nov 2000 23:42:28 -0500 (EST) Message-ID: <3A1C9DA4.3221215E@isi.edu> Date: Wed, 22 Nov 2000 20:31:32 -0800 From: Joe Touch X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: awank@future.futsoft.com CC: "'Markku Savela'" , "IpsecMailingList (E-mail)" Subject: Re: RFC 2401 section 5.2.1 References: <000701c05503$5a8c9780$6d0c000a@future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Awan Kumar Sharma wrote: > > Hi, > For the past few days, I have seen lots of discussion on the relevance of > transport and tunnel modes. Although I am not working on these protocols for > a very long time, but I see no reason for the relevance of transport mode > over the tunnel mode. The reason being: > > 1) Ref : RFC 2401, Section 4.1 Definition and scope. > It says > "In IPv4, a transport mode security protocol header > appears immediately after the IP header and any options, and before > any higher layer protocols (e.g., TCP or UDP)". > > i.e. In transport mode, the packet will look like [IP][ESP][HLP]. > Here I have taken ESP as an example. > Now we see that in this case, ESP will encrypt *only* [HLP] and thus IP is > not protected i.e. encrypted. Even if we select authentication in ESP, the > IP header is not protected. > > About Tunnel Mode, RFC 2401 says, > "The security protocol header appears after the outer IP header, and > before the inner IP header". > > i.e. In Tunnel Mode, the packet will look like [outer > IP][ESP][InnerIP][HLP]. > Now we see that ESP can encrypt the inner IP packet thus maintaining its > confidentiality. If authentication in ESP is used, the inner IP header is > fully authenticated also. And I think a security protocol should work in > this manner. > > So, having this argument, I see no reason for Transport mode being more > relevant than the Tunnel Mode. > Any suggestion/correction in this regard is most welcome. We've been considering the transport case where [HLP] == "[InnerIP][HLP]" I.e., transport mode does not exclude the use of IP as its content data. > 2) Now taking up the argument that transport mode with tunneling is same as > Tunnel mode in IPSec. > The tunneled transport mode protected packet will look like : > [OuterIP][InnerIP][ESP][HLP]. The idea is to tunnel THEN do transport encryption, resulting in: [OuterIP][ESP][InnerIP][HLP] > If my first point is correct, then we can see the extent of coverage in > this case on the same lines as before and compare it with the Tunnel mode > protected packet, which will look like, > [OuterIP][ESP][InnerIP][HLP]. As you can see, they now match. For more information, see draft-touch-ipsec-vpn-00.txt Joe From owner-ipsec@lists.tislabs.com Thu Nov 23 01:30:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA15459; Thu, 23 Nov 2000 01:30:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA23984 Thu, 23 Nov 2000 03:27:13 -0500 (EST) Date: Thu, 23 Nov 2000 10:28:22 +0200 (EET) From: Markus Levlin X-Sender: To: Subject: An IPR announcement by SSH Communications Security Corp Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk SSH Communications Security Corp hereby announces that at least one of our patent applications may be relevant to the internet-draft draft-huttunen-ipsec-esp-in-udp-00.txt. At present, said patent application has been filed in the US and PCT. The PCT counterpart (PCT/FI00/00537) will be published by the authorities on or after 15 December 2000. The material of the PCT application can be downloaded from http://www.ssh.com/tech/archive/ipsec.html as a PDF file at least until the application is available from the conventional on-line patent databases. The same PDF is available as as well at the IETF IPR notices page. In the case that said internet-draft becomes an IETF standard, SSH Communications Security Corp intends to support a widespread adoption of the standard by offering - on the basis of reciprocity whenever applicable - to license any IPR owned by SSH Communications Security Corp necessary for implementing the standard on fair, reasonable and nondiscriminatory terms. Any questions regarding this application should be sent to me. Markus Levlin Intellectual property rights manager fax +358 303 9871 markus.levlin@ssh.com From owner-ipsec@lists.tislabs.com Thu Nov 23 11:10:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA01941; Thu, 23 Nov 2000 11:10:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA25995 Thu, 23 Nov 2000 12:59:25 -0500 (EST) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A051A9B3A@eseis06nok> To: ipsec@lists.tislabs.com Subject: IKE PRF Date: Thu, 23 Nov 2000 20:00:26 +0200 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 Does anyone know where to find the algorithm to compute PRF using 3DESCBC? Toni From owner-ipsec@lists.tislabs.com Fri Nov 24 00:30:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA19461; Fri, 24 Nov 2000 00:30:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA27915 Fri, 24 Nov 2000 02:06:12 -0500 (EST) From: "akshay" To: Subject: Hi Date: Fri, 24 Nov 2000 00:32:40 +0530 Message-ID: <01c0557f$f3aad2c0$4302a8c0@akshay> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008B_01C055AE.0D630EC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_008B_01C055AE.0D630EC0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Can anyone please tell me , from where I can download BSD implementation = of IPSEC, if available . Thanks Akshay ------=_NextPart_000_008B_01C055AE.0D630EC0 Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable
Can anyone please tell me , from = where I can=20 download BSD implementation of IPSEC,
if available = .
 
 
Thanks
Akshay
------=_NextPart_000_008B_01C055AE.0D630EC0-- From owner-ipsec@lists.tislabs.com Fri Nov 24 00:45:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA21868; Fri, 24 Nov 2000 00:45:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA28018 Fri, 24 Nov 2000 02:57:22 -0500 (EST) To: "akshay" cc: ipsec@lists.tislabs.com In-reply-to: akshay's message of Fri, 24 Nov 2000 00:32:40 +0530. <01c0557f$f3aad2c0$4302a8c0@akshay> 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: Hi From: itojun@iijlab.net Date: Fri, 24 Nov 2000 16:58:22 +0900 Message-ID: <23006.975052702@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Can anyone please tell me , from where I can download BSD implementation = >of IPSEC, >if available . openbsd: bundled for some time now freebsd: bundled since 4.0 (4.2 recommended) netbsd: bundled since 1.5 (1.5 will be released soon) bsd/os: bundled since 4.0 itojun From owner-ipsec@lists.tislabs.com Fri Nov 24 10:24:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09889; Fri, 24 Nov 2000 10:24:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29440 Fri, 24 Nov 2000 12:07:01 -0500 (EST) Message-Id: <200011241709.SAA30456@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Henry Spencer cc: itojun@iijlab.net, ipsec@lists.tislabs.com, mobile-ip@standards.nortelnetworks.com Subject: Re: RFC 2401 section 5.2.1 In-reply-to: Your message of Tue, 21 Nov 2000 10:35:14 EST. Date: Fri, 24 Nov 2000 18:09:55 +0100 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: On Wed, 22 Nov 2000 itojun@iijlab.net wrote: > most of routing protocol needs to somehow protect IPv6 source address, > as they will use (peers') IPv6 source address as the nexthop router > information... Many of the death-to-AH enthusiasts also favoring killing transport mode => I know... but IMHO the tunnel mode is not very primitive, ie. this is tunnel plus transport plus clarifications about inner/outer addresses. and doing everything with tunnel mode, in which case the inner headers -- the ones that would be visible to applications -- are fully protected. (Notably, they can be encrypted as well as authenticated, if desired.) => VPN is not the only usage of IPsec and transport mode is better for end-to-end security. About the tunnel mode, for IPv6 there is an important implementation choice: to use a policy or to use an interface (with link-local addresses, neighbor discovery, ...). Regards Francis.Dupont@enst-bretagne.fr PS: there are many votes about AH in the past, AH is still alive (we voted to keep it) and needed by many IPv6 protocols (cf Itojun's mail). From owner-ipsec@lists.tislabs.com Fri Nov 24 10:24:15 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09907; Fri, 24 Nov 2000 10:24:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29513 Fri, 24 Nov 2000 12:36:12 -0500 (EST) Message-Id: <200011241738.SAA30590@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Henry Spencer cc: itojun@iijlab.net, ipsec@lists.tislabs.com Subject: Re: RFC 2401 section 5.2.1 In-reply-to: Your message of Tue, 21 Nov 2000 10:57:08 EST. Date: Fri, 24 Nov 2000 18:38:43 +0100 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: On Wed, 22 Nov 2000 itojun@iijlab.net wrote: > >Many of the death-to-AH enthusiasts also favoring killing transport mode > >and doing everything with tunnel mode... > > do we want to use tunnel mode on non-VPN ipsec exchanges? > I don't think so. => I agree (with Itojun). Why not? It can do everything transport mode does. (In particular, it is perfectly capable of working host-to-host.) => the price (in complexity, in overhead in packets, ...) is not the same. This is like the tunnel/routing header issue and IMHO should have the same kind of solution: - if you cannot use a header then you must use a tunnel - if you can use a header then you should use it. With you must not modify packets in route this gives headers (transport mode for IPsec, routing header and home address option for mobility, ...) for end-to-end operation and tunnels for other cases. I really believe the end-to-end principle asks for the transport mode, and the tunnel mode is a half-wedding (a PACS in French :-) between IPsec and generic tunnels. "Recommendation 1: *Eliminate transport mode*. ...we do not know why IPsec has two modes... The extra cost of a second mode (in terms of added complexity and resulting loss of security) is huge..." -- Ferguson & Schneier => obviously some details about the Internet architecture should be explained to Bruce Schneier (but I really like his books and we can't say that IPsec is not a bit too complex :-). It would be sensible to retain both if transport mode was the fundamental IPsec mode and tunnel mode was *just* IPIP tunneling over a transport-mode connection. => it is. Not accept that has given a very complex specification with many unspecified details. But it's not. (If it were, tunnel mode could be explained in a single footnote in RFC 2401, rather than having implications everywhere.) => IMHO tunnel mode should be described in an other document than RFC 2401, a kind of IPsec application to tunnels, based on a generic tunnel document like RFC 2473 with all the issues about inner and outer addresses explained. RFC 2367 for instance is far better than RFC 2401 about tunnels: in a SA you know there are two or three addresses and what they are (then there is a counter proof). Regards Francis.Dupont@enst-bretagne.fr PS: this thread should not cross posted to mobile-ip. From owner-ipsec@lists.tislabs.com Fri Nov 24 10:28:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10152; Fri, 24 Nov 2000 10:28:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29491 Fri, 24 Nov 2000 12:34:16 -0500 (EST) Date: Fri, 24 Nov 2000 12:34:48 -0500 (EST) From: Henry Spencer To: Francis Dupont cc: ipsec@lists.tislabs.com, mobile-ip@standards.nortelnetworks.com Subject: Re: RFC 2401 section 5.2.1 In-Reply-To: <200011241709.SAA30456@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 24 Nov 2000, Francis Dupont wrote: > => VPN is not the only usage of IPsec and transport mode is better for > end-to-end security. How is it "better"? Aside from slightly reducing the byte count on the wire, I mean? We use tunnel mode for end-to-end security quite routinely. In fact, it seems to us that tunnel mode actually gives slightly higher security, because it obscures whether the communication really *is* end-to-end or is being done on behalf of other hosts. > PS: there are many votes about AH in the past, AH is still alive... So far, yes. > ...and needed by many IPv6 protocols (cf Itojun's mail). That is exactly the question: *should* those protocols be relying on the quirks of AH? It would be better if they could also work with ESP. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Nov 24 10:31:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10301; Fri, 24 Nov 2000 10:31:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29529 Fri, 24 Nov 2000 12:40:40 -0500 (EST) Message-Id: <200011241743.SAA30616@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Henry Spencer cc: itojun@iijlab.net, ipsec@lists.tislabs.com Subject: Re: RFC 2401 section 5.2.1 In-reply-to: Your message of Tue, 21 Nov 2000 11:09:11 EST. Date: Fri, 24 Nov 2000 18:43:17 +0100 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: On Tue, 21 Nov 2000 itojun@iijlab.net wrote: > >Strongly agree. We'd like to see AH die entirely... > > (again this holy war on AH) > I don't. if you use transport mode IPsec heavily (unlike today's > VPN-only situation) how can you protect your header portion? Why would you have to use transport mode IPsec heavily? What problem does it solve that tunnel mode doesn't? => an example: secure VoIP on an air link: tunnel mode add 20 or 40 uncompressible bytes per packet. Look at ROHC WG for the price of one single bit in this context. Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Fri Nov 24 10:32:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10422; Fri, 24 Nov 2000 10:32:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29544 Fri, 24 Nov 2000 12:44:26 -0500 (EST) Date: Fri, 24 Nov 2000 12:44:59 -0500 (EST) From: Henry Spencer To: Francis Dupont cc: itojun@iijlab.net, ipsec@lists.tislabs.com Subject: Re: RFC 2401 section 5.2.1 In-Reply-To: <200011241738.SAA30590@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 24 Nov 2000, Francis Dupont wrote: > It would be sensible to retain both if transport mode was the fundamental > IPsec mode and tunnel mode was *just* IPIP tunneling over a transport-mode > connection. > > => it is... No. Not by RFC 2401, it's not. Please distinguish carefully between the way you think the protocols should work, and the way they are currently specified to work. Don't be misled by RFC 2401 saying that tunnel mode is "essentially" a tunnel within transport mode; that is a useful explanation but it is not literally true, not when you examine the details. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Nov 24 12:26:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16052; Fri, 24 Nov 2000 12:26:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29811 Fri, 24 Nov 2000 14:30:32 -0500 (EST) Message-ID: <3A1EBF34.84A61E5@isi.edu> Date: Fri, 24 Nov 2000 11:19:16 -0800 From: Joe Touch X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henry Spencer CC: Francis Dupont , itojun@iijlab.net, ipsec@lists.tislabs.com Subject: Re: RFC 2401 section 5.2.1 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer wrote: > > On Fri, 24 Nov 2000, Francis Dupont wrote: > > It would be sensible to retain both if transport mode was the fundamental > > IPsec mode and tunnel mode was *just* IPIP tunneling over a transport-mode > > connection. > > > > => it is... > > No. Not by RFC 2401, it's not. Please distinguish carefully between the > way you think the protocols should work, and the way they are currently > specified to work. Don't be misled by RFC 2401 saying that tunnel mode is > "essentially" a tunnel within transport mode; that is a useful explanation > but it is not literally true, not when you examine the details. The differences are outlined in our ID, draft-touch-ipsec-vpn-00.txt. On outbound processing, the difference is whether the inner or outer IP address determines the SPD. The advantage to tunnel-in-transport (IIPtran, in our doc) is that it uses the outer IP address to determine SPD, thus enabling dynamic routing without the complication of sychronizing key database updates and routing table updates. On inbound processing, the two are (or at least should be) identical. (i.e., either match inner and outer addrs in one step if tunnelmode, or match outer, decapsulate via IPSEC, and reverify - via an additional rule - the inner header on subsequent IP processing) On the wire, they are indistinguishible, for a given key. Which means that the inbound system in particular shouldn't assume that protocol type 4 inside IPSEC implies tunnel mode; it definitely must check the SPD to verify whether IPSEC or some other (non-IPSEC) code should be doing the decapsulation. Joe From owner-ipsec@lists.tislabs.com Fri Nov 24 12:29:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16095; Fri, 24 Nov 2000 12:29:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29790 Fri, 24 Nov 2000 14:27:13 -0500 (EST) Message-Id: <200011241929.UAA31689@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Joe Touch cc: Henry Spencer , itojun@iijlab.net, ipsec@lists.tislabs.com Subject: Re: RFC 2401 section 5.2.1 In-reply-to: Your message of Wed, 22 Nov 2000 14:51:36 PST. <3A1C4DF8.23918D4F@isi.edu> Date: Fri, 24 Nov 2000 20:29:18 +0100 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: Would it be useful to have a discussion of this at the IETF, notably that could support both Mobile-IP and IPSEC participants? => as it is mobile IPv6 it should be IPng and IPsec participants? (it might take a slightly larger room). => a smaller if you'd like to have only IPv6 *and* IPsec people (:-). Francis.Dupont@enst-bretagne.fr PS: I'd like to see this happen because in a IPv6 context the interface issue (tunnel are policies or interfaces) is far more than routing table entries. Perhaps this will be the opportunity to talk about the architectural issues with the tunnel mode... PPS: I'd like to get more answers to my original message too (about source check in inbound processing). From owner-ipsec@lists.tislabs.com Fri Nov 24 13:47:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA18544; Fri, 24 Nov 2000 13:47:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29949 Fri, 24 Nov 2000 15:54:56 -0500 (EST) Message-ID: <001601c05659$93249460$79b12304@ffb5b> From: "jshukla" To: "Francis Dupont" , "Henry Spencer" Cc: , References: <200011241738.SAA30590@givry.rennes.enst-bretagne.fr> Subject: Re: RFC 2401 section 5.2.1 Date: Fri, 24 Nov 2000 13:00:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Francis Dupont" > > Why not? It can do everything transport mode does. (In particular, it is > perfectly capable of working host-to-host.) > > => the price (in complexity, in overhead in packets, ...) is not the same. > This is like the tunnel/routing header issue and IMHO should have the same > kind of solution: > - if you cannot use a header then you must use a tunnel > - if you can use a header then you should use it. > With you must not modify packets in route this gives headers (transport mode > for IPsec, routing header and home address option for mobility, ...) for > end-to-end operation and tunnels for other cases. > I really believe the end-to-end principle asks for the transport mode, > and the tunnel mode is a half-wedding (a PACS in French :-) between IPsec > and generic tunnels. > Transport mode does not solve the end-to-end security problem. In fact, either mode of IPSec cannot traverse NAT and is not capable of providing end-to-end security. One exception is the LAN configuration where you do not have to deal with NAT. There, one can use the transport mode for end-to-end security. A whole lot of work has been done to address this problem, e.g. RSIP, UDP encapsulation etc. For a discussion of the end-to-end security problem, take a look at this draft. In there you will also find references to other work done on end-to-end security problem. http://www.ietf.org/internet-drafts/draft-shukla-ipsec-nat-qos-compatible-se curity-00.txt ~Jayant From owner-ipsec@lists.tislabs.com Fri Nov 24 13:56:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA18653; Fri, 24 Nov 2000 13:56:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29996 Fri, 24 Nov 2000 16:12:32 -0500 (EST) Message-ID: <001b01c0565c$27ac09e0$79b12304@ffb5b> From: "jshukla" To: References: <200011241743.SAA30616@givry.rennes.enst-bretagne.fr> Subject: Re: RFC 2401 section 5.2.1 Date: Fri, 24 Nov 2000 13:18:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Francis Dupont" To: "Henry Spencer" > > Why would you have to use transport mode IPsec heavily? What problem does > it solve that tunnel mode doesn't? > > => an example: secure VoIP on an air link: tunnel mode add 20 or 40 > uncompressible bytes per packet. Look at ROHC WG for the price of > one single bit in this context. > On a similar note, wouldn't the tunnel mode result into waste of a lot of bandwidth in IPv6? Over 50% of data packets on the Internet are less than 128 bytes in size. With the massive IPv6 header (40 bytes), the tunnel mode may not be particularly attractive. http://isglabs.rainbow.com/rsa99/sld007.htm regards, Jayant From owner-ipsec@lists.tislabs.com Fri Nov 24 15:05:20 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA19827; Fri, 24 Nov 2000 15:05:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00134 Fri, 24 Nov 2000 17:05:43 -0500 (EST) Message-ID: <3A1EE395.E842E499@isi.edu> Date: Fri, 24 Nov 2000 13:54:29 -0800 From: Joe Touch X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henry Spencer , Francis Dupont , itojun@iijlab.net, ipsec@lists.tislabs.com Subject: Re: RFC 2401 section 5.2.1 References: <3A1EBF34.84A61E5@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joe Touch wrote: > > Henry Spencer wrote: > > > > On Fri, 24 Nov 2000, Francis Dupont wrote: > > > It would be sensible to retain both if transport mode was the fundamental > > > IPsec mode and tunnel mode was *just* IPIP tunneling over a transport-mode > > > connection. > > > > > > => it is... > > > > No. Not by RFC 2401, it's not. Please distinguish carefully between the > > way you think the protocols should work, and the way they are currently > > specified to work. Don't be misled by RFC 2401 saying that tunnel mode is > > "essentially" a tunnel within transport mode; that is a useful explanation > > but it is not literally true, not when you examine the details. > > The differences are outlined in our ID, draft-touch-ipsec-vpn-00.txt. PS - that draft did expire, and may not be widely availabley anymore. However, I just completed and submitted an update, which addresses only the IPIP encapsulation/decapsulation rules as an appendix, mostly. It should be available in the usual places shortly; in the meantime, it can be retreived from: http://www.isi.edu/touch/pubs/draft-touch-ipsec-vpn-01.txt Joe From owner-ipsec@lists.tislabs.com Fri Nov 24 18:07:41 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA22719; Fri, 24 Nov 2000 18:07:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA00458 Fri, 24 Nov 2000 20:05:43 -0500 (EST) To: "jshukla" cc: "Francis Dupont" , "Henry Spencer" , ipsec@lists.tislabs.com In-reply-to: jshukla's message of Fri, 24 Nov 2000 13:00:26 PST. <001601c05659$93249460$79b12304@ffb5b> 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: RFC 2401 section 5.2.1 From: itojun@iijlab.net Date: Sat, 25 Nov 2000 10:05:26 +0900 Message-ID: <2926.975114326@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Transport mode does not solve the end-to-end security problem. >In fact, either mode of IPSec cannot traverse NAT and is not >capable of providing end-to-end security. One exception is the >LAN configuration where you do not have to deal with NAT. There, >one can use the transport mode for end-to-end security. A whole >lot of work has been done to address this problem, e.g. RSIP, >UDP encapsulation etc. say a long goodbye to NAT, use IPv6. itojun From owner-ipsec@lists.tislabs.com Sat Nov 25 11:44:41 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA07075; Sat, 25 Nov 2000 11:44:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02037 Sat, 25 Nov 2000 13:16:06 -0500 (EST) Message-Id: <200011251817.TAA38011@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "jshukla" cc: "Henry Spencer" , itojun@iijlab.net, ipsec@lists.tislabs.com Subject: Re: RFC 2401 section 5.2.1 In-reply-to: Your message of Fri, 24 Nov 2000 13:00:26 PST. <001601c05659$93249460$79b12304@ffb5b> Date: Sat, 25 Nov 2000 19:17:01 +0100 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: Transport mode does not solve the end-to-end security problem. In fact, either mode of IPSec cannot traverse NAT and is not capable of providing end-to-end security. => NATs are *not* in the Internet architecture and *do* break any end-to-end properties. One exception is the LAN configuration where you do not have to deal with NAT. => this discussion is in the IPv6 context where NATs are *not* wellcome. A whole lot of work has been done to address this problem, e.g. RSIP, UDP encapsulation etc. => something which modifies packets on the fly should not be considered where we talk about end-to-end security (or end-to-end something) IMHO. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Sun Nov 26 11:26:41 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA17072; Sun, 26 Nov 2000 11:26:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03883 Sun, 26 Nov 2000 12:59:23 -0500 (EST) From: Nishatul@aol.com Message-ID: <9f.d98762a.2752a9a5@aol.com> Date: Sun, 26 Nov 2000 13:00:05 EST Subject: Re: RFC 2401 section 5.2.1 To: Markku.Savela@research.nokia.com, ipsec@lists.tislabs.com, mobile-ip@standards.nortelnetworks.com CC: Atul4sharma@aol.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Windows AOL sub 115 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There was no discussion later in this thread for the questions raised by you. Here are some thoughts based on IPv6 specifications: Quoting from RFC2460 section 4: The contents and semantics of each extension header determine whether or not to proceed to the next header. Therefore, extension headers must be processed strictly in the order they appear in the packet; a receiver must not, for example, scan through a packet looking for a particular kind of extension header and process that header prior to processing all preceding ones. So looks like for the receive side we have no option but to process all the headers before going to HLP and do the processing as stipulated by RFC2401 section 5.1.2. For the outbound side, we need to make sure that binding updates are placed such that changes to the addresses by the binding updates are the last effective ones before the SPD processing, when this packet is received at the other end. So piggybacking would be fine, as long as the above requirement is met. This would raise new questions though, i.e. decision that such a requirement is meant. From owner-ipsec@lists.tislabs.com Sun Nov 26 16:51:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA06500; Sun, 26 Nov 2000 16:51:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04373 Sun, 26 Nov 2000 18:29:32 -0500 (EST) From: Dan McDonald Message-Id: <200011262330.eAQNUmK05325@kebe.Eng.Sun.COM> Subject: On transport-level policy enforcement (was Re: RFC 2401...) To: ipsec@lists.tislabs.com Date: Sun, 26 Nov 2000 15:30:48 -0800 (PST) Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Mailer: ELM [version 2.4ME+ PL66 (25)] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've been watching the transport vs. tunnel debate silently. For the record, I'm in (almost?) full agreement with Joe Touch that "tunnel mode" can be better implemented (and should be treated) as a special case of transport mode. I'll now try and explain how I arrived here through experiences of two (NRL and Solaris) IPsec implementations. To allow for the best policy matching speed, you really shouldn't check against the global SPD for each packet. What you should do is cache the relevant SPD rules in the per-session state. When you select the appropriate session(s) for a datagram, you compare the inbound IPsec processing on the packet against what the rule is for this session. On outbound data, you use the originating session state to guide the outbound packet through the appropriate IPsec processing. In Solaris, the SPD rule is cached in the "IP client" state, which corresponds to an open socket or TLI/XTI descriptor. In BSD, this is in the inpcb state, or perhaps socket state. (Any KAME folks want to clue me in on the current practice?) When you change the global SPD, you must update the per-socket caches _if_ you aren't following a latching policy. (Latching is an implementation decision that keeps TCP retransmission bookkeeping from exploding out-of-control. My very old IPsec API has reasoning for this, as does C. Metz's not-quite-as-old API draft.) Sometimes a transport layer still has to process per-session state even after the session is gone. TCP connections in FIN_WAIT_* state are a fine example of this. Because of this, TCP has to be able to ask the IPsec SPD about a packet, or cache SPD rules itself. Since TCP is doing this anyway... and if we consider tunneling to be just another upper-layer protocol, perhaps our tunneling "session" can always ask the SPD for rules? Or perhaps it can do what is currently defined in 2401 as "tunnel mode processing" with respect to security checking. This way, we keep the complexity (acknowleged by many as the enemy of security) out of the common IP path and in the tunnel-specific code. Leaving out breaking NAT (or NAT being broken), transport mode is better for end-to-end encryption of packets because of MTU and redundant (Do the headers match? If not, how do I handle the differences?) packet checking issues. Francis and Itojun have made these arguments already. It also allows a cleaner separation of policy and mechanism - AH and ESP are the mechanisms of IPsec, not IP in IP. I believe this is Joe's point. My own implementation experiences lean toward transport mode as the preferred way of doing business, because I enforce policy further away from IPsec header processing than perhaps others do. Dan From owner-ipsec@lists.tislabs.com Sun Nov 26 19:03:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA09276; Sun, 26 Nov 2000 19:03:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA04615 Sun, 26 Nov 2000 20:57:16 -0500 (EST) Message-Id: <200011270152.RAA24730@potassium.network-alchemy.com> To: Henry Spencer cc: Francis Dupont , ipsec@lists.tislabs.com, mobile-ip@standards.nortelnetworks.com Subject: Re: RFC 2401 section 5.2.1 In-reply-to: Your message of "Fri, 24 Nov 2000 12:34:48 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24727.975289954.1@network-alchemy.com> Date: Sun, 26 Nov 2000 17:52:34 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 24 Nov 2000 12:34:48 EST you wrote > > We use tunnel mode for end-to-end security quite routinely. In fact, it > seems to us that tunnel mode actually gives slightly higher security, > because it obscures whether the communication really *is* end-to-end or is > being done on behalf of other hosts. Obscured from whom? Don't transport mode and tunnel mode packets look identical to a passive evesdropper since the Next Header field is encrypted? (Assuming you're not doing AH, or NULL ESP, which from your previous statements seems plausible). Dan. From owner-ipsec@lists.tislabs.com Sun Nov 26 22:19:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA12463; Sun, 26 Nov 2000 22:19:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA05031 Mon, 27 Nov 2000 00:14:04 -0500 (EST) To: Dan McDonald cc: ipsec@lists.tislabs.com In-reply-to: Dan.McDonald's message of Sun, 26 Nov 2000 15:30:48 PST. <200011262330.eAQNUmK05325@kebe.Eng.Sun.COM> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: On transport-level policy enforcement (was Re: RFC 2401...) From: itojun@iijlab.net Date: Mon, 27 Nov 2000 14:15:16 +0900 Message-ID: <28243.975302116@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >In Solaris, the SPD rule is cached in the "IP client" state, which >corresponds to an open socket or TLI/XTI descriptor. In BSD, this is in the >inpcb state, or perhaps socket state. (Any KAME folks want to clue me in on >the current practice?) When you change the global SPD, you must update the i believe the above ("inpcb for BSD") is correct. with KAME implementation there are 3 places where you can define policy. - per host policy: regardless of packet content, some policy is enforced (like "this host will accept encrypted packet only"). - packet filter policy: packet filter will match outgoing/incoming packet and enforce certain policy. like "ESP is required for inbound traffic from 10.0.0.0/8". actually, per host policy can be implemented by a policy entry with filter "0.0.0.0/0". i don't remember why it is not done yet. - per socket policy: with setsockopt(2) we can attach policy to pcb (inpcb). like "for SMTP connection over this socket, I ask people to use ESP". because of some complexity (*) we have in our code, we do not cache packet filter policy into inpcb. it definitely makes sense to cache it. BTW, the cache-in-pcb way does not work well if the BSD box is used as a router:-) (*) for example, we have some interaction between user privilege and per socket policy. root can override per-host policy by per socket policy. non-root cannot. also, if we cache policy, inpcb management will get more complex - need to make sure we do not have dangling pointer from inpcb to policy entry. itojun From owner-ipsec@lists.tislabs.com Mon Nov 27 05:20:02 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA25345; Mon, 27 Nov 2000 05:20:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA06438 Mon, 27 Nov 2000 07:13:50 -0500 (EST) Message-ID: <3A225040.AF19526F@lmf.ericsson.se> Date: Mon, 27 Nov 2000 14:14:56 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com CC: jarkko@piuha.net Subject: IPv6 Jumbo Payload and IPsec Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi. I've recently worked with IPv6 and IPsec implementations, and would like to ask the group some advice regarding treatment of IPv6 jumbograms. You may already recall that IPv6 provides for up to 2^32-1+40 byte packets using the Jumbo Payload option described in RFC 2675. If this option is used, then the actual length field in the IPv6 header is set to zero. Such packets may not be fragmented. I'm curious as to the effects this has on IPsec. Has any of the folks supporting IPv6 IPsec actually implemented Jumbo Payload support as well? What is the purpose of the Jumbograms? Why are the Jumbo Payload options classified as Hop-by-Hop options? It survives end-to-end unchanged, doesn't it? Are there any limits to the size of the packets with Jumbo Payloads or is the full 32 bit packet length field in use? Is it mandatory to support Jumbo Payloads? RFC 2675 states as follows: Jumbograms are relevant only to IPv6 nodes that may be attached to links with a link MTU greater than 65,575 octets, and need not be implemented or understood by IPv6 nodes that do not support attachment to links with such large MTUs. But what does this mean? If I have links with MTUs of 1M, but my IPsec or IP forwarding doesn't allow quite as much in between, am I allowed to send back an ICMP? What are the Denial of Service aspects of Jumbo Payloads? For instance, assume you have a 1 Gbit/s hw or CPU to do encryption. Then you get a Jumbo Payload of 4 * 8 Gbits, and spend the next 32 seconds handling this one packet. Granted, even receiving the 4 Gbyte packet will take a lot of time unless one is running pure IP over WDM fiber and has lots of buffer space... but let's assume you are running on such machine but with a low-speed CPU and IPsec mainly targeted to protect some control traffic. Then somebody sends a big packet claiming to be a real IPsec packet... at 10 Mbit/s even integrity check will take a long time, especially if the CPU runs a single-threaded kernel mode implementation... How would one go about testing the Jumbo Payload? In particular, how would you test boundary cases such as ESP padding causing an overflow beyond 2^32-1+40? Jari ---- Jari Arkko, Oy L M Ericsson Ab, 02420 Jorvas, Finland. Tel +358 9 2992480 Fax +358 9 2993052. GSM +358 40 5079256. E-Mail: Jari.Arkko@ericsson.com Private WWW: http://www.iki.fi/jar. Standard disclaimers apply. From owner-ipsec@lists.tislabs.com Mon Nov 27 05:20:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA25363; Mon, 27 Nov 2000 05:20:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA06409 Mon, 27 Nov 2000 07:08:26 -0500 (EST) Message-Id: <200011271212.NAA49108@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Dan McDonald cc: ipsec@lists.tislabs.com Subject: Re: On transport-level policy enforcement (was Re: RFC 2401...) In-reply-to: Your message of Sun, 26 Nov 2000 15:30:48 PST. <200011262330.eAQNUmK05325@kebe.Eng.Sun.COM> Date: Mon, 27 Nov 2000 13:12:14 +0100 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: I've been watching the transport vs. tunnel debate silently. For the record, I'm in (almost?) full agreement with Joe Touch that "tunnel mode" can be better implemented (and should be treated) as a special case of transport mode. I'll now try and explain how I arrived here through experiences of two (NRL and Solaris) IPsec implementations. => I know answers to my questions for NRL, what are they for Solaris: - is the packet's the source address checked in transport mode? - is the packet's outer source address checked in destination mode? - when are the checks done (before, ie. at the end of the lookup routine, after, ie. after the processing of all IPsec headers)? (NRL code: yes, yes and as soon as possible, ie. the (possibly outer) source address is checked in the SA lookup routine). In Solaris, the SPD rule is cached in the "IP client" state, which corresponds to an open socket or TLI/XTI descriptor. In BSD, this is in the inpcb state, or perhaps socket state. (Any KAME folks want to clue me in on the current practice?) => KAME caches inbound and outbound SPD entries in the PCB (inpcb) with a flag for priviledged (ie. owned by root) sockets. Very standard... If the policy is not per-socket then it is recomputed for each packet. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Mon Nov 27 09:15:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16614; Mon, 27 Nov 2000 09:15:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06963 Mon, 27 Nov 2000 10:07:51 -0500 (EST) X-Authentication-Warning: puuro.hel.fi.ssh.com: mstenber set sender to mstenber@ssh.com using -f To: "jshukla" Cc: Subject: Re: I-D ACTION:draft-shukla-ipsec-nat-qos-compatible-security-00.txt References: <200011140428.eAE4Sut03731@sandelman.ottawa.on.ca> <000901c04e69$5b1f3b80$98b12304@ffb5b> <000601c054d5$78fc9400$19b12304@ffb5b> From: Markus Stenberg Date: 23 Nov 2000 14:04:39 +0200 In-Reply-To: "jshukla"'s message of "Wed, 22 Nov 2000 14:42:19 -0800" Message-ID: Lines: 61 User-Agent: Gnus/5.0803 (Gnus v5.8.3) XEmacs/21.1 (Acadia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "jshukla" writes: > ----- Original Message ----- > From: "Markus Stenberg" > > from 5.3: > > > > The drawbacks of this approach are that it will require > > modifications to existing NAT implementations, and will have > > overhead in book-keeping to ensure that no two hosts use the same > > port number. > > > > To be specific, it does NOT require changes to the intervening NAT devices > > on network path between IPsec endpoints. One endpoint MAY need to contain > > NAT implementation, which obviously is nonstandard as it performs > > (host,port) <> internal-host mapping in some cases. > As you explained yourself, it does NOT require ANY changes to the > NAT devices. Yes.. But I think I was pointing out that 'it will require modifications to existing NAT implementations' sentence does not seem to quite apply in this case. > In the situations where the effect of NAT must be > reversed, some additional functionality is needed and that can be > implemented without any modifications to the NAT. .. yes.. > I think you are > thinking of merging this functionality with the NAT implementation, > which is not the case. (as far as the draft spoken about in 5.3 goes) What I meant was that only NAT implementation which is _added_ (not changed) is the NAT-merged-with-responder-end-IPsec (which _CANNOT_ be separated, if transport mode support is desired in all cases). Otherwise you are unable to support case where two initiators (behind dynamic NAPTs) with same configured ip (10.0.0.1, for example) attempt to converse with responder using transport mode. Separate NAT wouldn't work because it couldn't distinguish between the remote end entities as unique ip+port information would not survive the decapsulation process in case of ICMP, for example. The IPsec-merged-with-NAT is only needed if transport mode is desired, and that does not seem to be common trend nowadays. Reasonable use of tunnel mode would lead to unique IPs by using say, or some static network address configuration. -Markus Stenberg (I hope the next version of that draft, which I will probably submit today, is bit clearer on some points.. :-) -- Simplicity does not precede complexity, but follows it. >From ACM's SIGPLAN publication, (September, 1982), Article "Epigrams in Programming", by Alan J. Perlis of Yale University. From owner-ipsec@lists.tislabs.com Mon Nov 27 09:15:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16613; Mon, 27 Nov 2000 09:15:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA07023 Mon, 27 Nov 2000 10:15:52 -0500 (EST) Message-ID: <44059717.975063341656.JavaMail.Administrator@hvwww5> Date: Fri, 24 Nov 2000 02:55:41 -0800 (PST) From: Arvind Devarajan To: ipsec@lists.tislabs.com Subject: Question regarding SPD and SA bundles... Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="44061071.975063341593.JavaMail.Administrator@hvwww5" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --44061071.975063341593.JavaMail.Administrator@hvwww5 Content-Type: text/plain Content-Transfer-Encoding: 7bit hi, i've not understood a phrase in RFC 2401, Section 5.1.1. In the outbound processing, the RFC says: "Match the packet's selector fields against the outbound policies in the SPD to locate the first appropriate policy, whicc will point to zero or more SA bundles in the SAD" As i have understood, an SPD is something like this: ......... I've used the words "SA template" here because these templates become SAs in the SAD, and not in the SPD itself. If a policy contains more than one SA template, we have an SA bundle that it points to. Now, my question is this: As i see from above, a policy can either point to _one_ SA, or _one_ SA bundle (more than one SA). Where is the question of SPD entries matching "one or more SA Bundles"? I've myself got one possible answer - correct me if i am wrong: these SA bundles are nothing but SAs created from these templates for each connection that requires it? initially, we begin with one set of SA templates for a particular policy, and, when a packet's selector matches this policy, it initiates creation of the SA bundle pointed by it. now, when another packet, for a different connection also matches this policy's selector, another SA bundle is created for this packet from the same set of SA templates. this effectively means that this SPD entry now points to two SA bundles... and the story goes on. If my above answer is right, in a way, the SPD is not just a static Database - SA bundles keep on getting added to it as and when a new channel is to be created. please comment on this too. thanks for your patience, and hoping for an answer soon... regards, arvind. ------------------------------------------- Arvind Devarajan < - > Luck is defined as the time when HARD WORK meets OPPORTUNITY! -------------------------------------------------------------------------- Global Internet phone calls, voicemail, fax, e-mail and instant messaging. Sign-up today for FREE account at http://www.hotvoice.com --44061071.975063341593.JavaMail.Administrator@hvwww5-- From owner-ipsec@lists.tislabs.com Mon Nov 27 09:48:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18739; Mon, 27 Nov 2000 09:48:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07706 Mon, 27 Nov 2000 11:34:00 -0500 (EST) From: Dan McDonald Message-Id: <200011271634.eARGYte19952@kebe.Eng.Sun.COM> Subject: Re: On transport-level policy enforcement (was Re: RFC 2401...) In-Reply-To: <28243.975302116@coconut.itojun.org> from "itojun@iijlab.net" at "Nov 27, 2000 02:15:16 pm" To: itojun@iijlab.net Date: Mon, 27 Nov 2000 08:34:54 -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 > actually, per host policy can be implemented by a policy entry with > filter "0.0.0.0/0". i don't remember why it is not done yet. That makes sense. > because of some complexity (*) we have in our code, we do not cache > packet filter policy into inpcb. it definitely makes sense to cache it. > BTW, the cache-in-pcb way does not work well if the BSD box is used > as a router:-) In Solaris, tunnels are interfaces over the "IP device". Since sockets are also opens of the "TCP/IP device," "UDP/IP device," or the "raw IP device," tunnels have pcb's just like sockets do! OTOH if your tunnels have complex rules (e.g. varieties of per-flow policies), then per-pcb-caching breaks down. > also, if we cache policy, inpcb management will get more complex - > need to make sure we do not have dangling pointer from inpcb to policy > entry. Heh heh. That's a tricky one, but it's doable. Throw multithreading issues in if you want extra fun! :) Dan From owner-ipsec@lists.tislabs.com Mon Nov 27 09:48:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18750; Mon, 27 Nov 2000 09:48:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07775 Mon, 27 Nov 2000 11:51:23 -0500 (EST) From: Dan McDonald Message-Id: <200011271639.eARGdVJ19997@kebe.Eng.Sun.COM> Subject: Re: On transport-level policy enforcement (was Re: RFC 2401...) In-Reply-To: <200011271212.NAA49108@givry.rennes.enst-bretagne.fr> from Francis Dupont at "Nov 27, 2000 01:12:14 pm" To: Francis Dupont Date: Mon, 27 Nov 2000 08:39:31 -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 > => I know answers to my questions for NRL, what are they for Solaris: > - is the packet's the source address checked in transport mode? It's part of the SA lookup. > - is the packet's outer source address checked in destination mode? Just like the transport mode stuff again. > - when are the checks done (before, ie. at the end of the lookup > routine, after, ie. after the processing of all IPsec headers)? > (NRL code: yes, yes and as soon as possible, ie. the (possibly outer) source > address is checked in the SA lookup routine). And you wonder where I got the idea from... ;) > If the policy is not per-socket then it is recomputed for each packet. Expensive... but it's often necessary. (Consider the UDP server app that's bound to only a port and does nothing but recvfrom()s and sendto()s.) Dan From owner-ipsec@lists.tislabs.com Mon Nov 27 10:14:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19680; Mon, 27 Nov 2000 10:14:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07856 Mon, 27 Nov 2000 12:11:36 -0500 (EST) From: Dan McDonald Message-Id: <200011271711.eARHBet20164@kebe.Eng.Sun.COM> Subject: Re: IPv6 Jumbo Payload and IPsec In-Reply-To: <3A225040.AF19526F@lmf.ericsson.se> from Jari Arkko at "Nov 27, 2000 02:14:56 pm" To: Jari Arkko Date: Mon, 27 Nov 2000 09:11:39 -0800 (PST) CC: ipsec@lists.tislabs.com, jarkko@piuha.net Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Mailer: ELM [version 2.4ME+ PL66 (25)] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I'm curious as to the effects this has on IPsec. Has any > of the folks supporting IPv6 IPsec actually implemented Jumbo > Payload support as well? We don't have jumbogram support yet. > What is the purpose of the Jumbograms? To allow the full use of large MTU links. Most of these large MTU links connect supercomputer-class machines. (And I'll bet small sums that many instances of such links are physically secure and disconnected from hostile networks.) > Why are the Jumbo Payload options classified as Hop-by-Hop > options? Because it needs to be seen immediately, in case of two jumbo-sized MTUs. > It survives end-to-end unchanged, doesn't it? Yes. > Are there any limits to the size of the packets with Jumbo > Payloads or is the full 32 bit packet length field in use? Nothing save the link MTU stops the packet size from reaching its maximum. > But what does this mean? If I have links with MTUs of 1M, but > my IPsec or IP forwarding doesn't allow quite as much in between, > am I allowed to send back an ICMP? I believe so. You may wish to verify this with someone more IPv6-savvy. My local IPv6 clue sources aren't in the office yet. > What are the Denial of Service aspects of Jumbo Payloads? The same as regular payloads... except bigger! :) > For instance, assume you have a 1 Gbit/s hw or CPU to do > encryption. Then you get a Jumbo Payload of 4 * 8 Gbits, > and spend the next 32 seconds handling this one packet. Yep. > IPsec mainly targeted to protect some control traffic. > Then somebody sends a big packet claiming to be a real > IPsec packet... at 10 Mbit/s even integrity check will take a > long time, especially if the CPU runs a single-threaded kernel > mode implementation... Only way this would happen is if your adversary has access to your high-MTU link. Given what I said earlier, this is a low-probability event. > How would one go about testing the Jumbo Payload? In particular, > how would you test boundary cases such as ESP padding causing > an overflow beyond 2^32-1+40? The same way you would an ordinary packet - only obtaining the length a different way. Dan From owner-ipsec@lists.tislabs.com Mon Nov 27 13:42:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03737; Mon, 27 Nov 2000 13:42:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA08540 Mon, 27 Nov 2000 14:35:48 -0500 (EST) Message-Id: <200011271934.eARJY3a100590@thunk.east.sun.com> From: Bill Sommerfeld To: Dan Harkins cc: Henry Spencer , Francis Dupont , ipsec@lists.tislabs.com, mobile-ip@standards.nortelnetworks.com Subject: Re: RFC 2401 section 5.2.1 In-reply-to: Your message of "Sun, 26 Nov 2000 17:52:34 PST." <200011270152.RAA24730@potassium.network-alchemy.com> Reply-to: sommerfeld@East.Sun.COM Date: Mon, 27 Nov 2000 14:34:03 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Obscured from whom? Don't transport mode and tunnel mode packets look > identical to a passive evesdropper since the Next Header field is encrypted? > (Assuming you're not doing AH, or NULL ESP, which from your previous > statements seems plausible). well, there's always traffic analysis on minimum packet lengths, assuming that some minimum-length ack-only TCP segments will be in the traffic mix, and ipcomp and/or more-than-minimal padding aren't in use.. - Bill From owner-ipsec@lists.tislabs.com Mon Nov 27 15:10:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06666; Mon, 27 Nov 2000 15:10:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08866 Mon, 27 Nov 2000 16:24:10 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200011262330.eAQNUmK05325@kebe.Eng.Sun.COM> References: <200011262330.eAQNUmK05325@kebe.Eng.Sun.COM> Date: Mon, 27 Nov 2000 16:18:24 -0500 To: Dan McDonald From: Stephen Kent Subject: Re: On transport-level policy enforcement (was Re: RFC 2401...) Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, I was away for a week, and terribly far behind, so this reply is way of out order, but ... Your analysis of how to do the checking is fine for a native host implementation where per-connection state is already available. In a security gateway, the problem is a bit different. We wrote the generic checking description we didn't know how to cache SPD rules in such circumstances. We now have ways of doing that which do not violate the SPD ordering assumption. The next rev of 2401 will update the inbound processing discussion accordingly. We can also divide the discussion into SG vs. native host environments, to simplify matters. Steve From owner-ipsec@lists.tislabs.com Mon Nov 27 15:39:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA07073; Mon, 27 Nov 2000 15:39:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA08955 Mon, 27 Nov 2000 17:10:19 -0500 (EST) Message-ID: <3A22B283.A6AB2FD1@bravidacorp.com> Date: Mon, 27 Nov 2000 11:14:11 -0800 From: fisher Organization: Bravida Corporation X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dan McDonald CC: itojun@iijlab.net, ipsec@lists.tislabs.com, fisher@bravidacorp.com Subject: Re: On transport-level policy enforcement (was Re: RFC 2401...) References: <200011271634.eARGYte19952@kebe.Eng.Sun.COM> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan McDonald wrote: > > > actually, per host policy can be implemented by a policy entry with > > filter "0.0.0.0/0". i don't remember why it is not done yet. > > That makes sense. > > > because of some complexity (*) we have in our code, we do not cache > > packet filter policy into inpcb. it definitely makes sense to cache it. > > > BTW, the cache-in-pcb way does not work well if the BSD box is used > > as a router:-) > > In Solaris, tunnels are interfaces over the "IP device". Since sockets are > also opens of the "TCP/IP device," "UDP/IP device," or the "raw IP device," > tunnels have pcb's just like sockets do! > > OTOH if your tunnels have complex rules (e.g. varieties of per-flow > policies), then per-pcb-caching breaks down. > > > also, if we cache policy, inpcb management will get more complex - > > need to make sure we do not have dangling pointer from inpcb to policy > > entry. > > Heh heh. That's a tricky one, but it's doable. Throw multithreading issues > in if you want extra fun! :) > > Dan > IBM gave a talk last year regarding a policy implementation using the multi-threaded BSD implementation in AIX 4.3. The talk described there "solution" to the dangling pointer and the revised socket/PCB/PolicyObject locking model. Hence the problem has been solved, but it did take considerable effort on the part of the IBM developers. -- Bill (fisher@bravidacorp.com) From owner-ipsec@lists.tislabs.com Tue Nov 28 03:32:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA19155; Tue, 28 Nov 2000 03:32:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA10653 Tue, 28 Nov 2000 04:26:18 -0500 (EST) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A051A9B78@eseis06nok> To: ipsec@lists.tislabs.com Subject: Synchronisation in IKE Date: Tue, 28 Nov 2000 11:27:36 +0200 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 I think this is a very important issue and is giving me plenty of headaches. Is there any documents that talks about how to resynchronise IKE negotiations. Any advice on the subject would be greatly appreciated. Take as an Example the next case: 1- A (Initiator) negotiates with B (Responder) 2- B reboots and is unable to send any delete notification. 3- A can't talk to B anymore (A has IPSEC SAs, but no B) I have no solution for this. IDEAS? 4- IPSEC SAs in A expire. A Initiates a Quick mode negotiation but B doesn't have ISAKMP SAs either That could be solved letting A detect that B can't negotiate and initiating a new Phase I negotiation. Is there any problem with this solution? If yes is there an alternative? What do I do with the old ISAKMP SA? Keep or destroy it? I'd destroy it, but not sure if can give any problem. I'd really appreciate any response. Thanks in advance. Toni From owner-ipsec@lists.tislabs.com Tue Nov 28 04:24:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA23120; Tue, 28 Nov 2000 04:24:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA10850 Tue, 28 Nov 2000 05:55:31 -0500 (EST) Message-Id: <200011281056.FAA02217@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-08.txt Date: Tue, 28 Nov 2000 05:56:50 -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-08.txt Pages : 15 Date : 27-Nov-00 In many remote access scenarios, a mechanism for making the remote host appear to be present on the local corporate network is quite useful. This may be accomplished by assigning the host a 'virtual' address from the corporate network, and then tunneling traffic via Ipsec from the host's ISP-assigned address to the corporate security gateway. The Dynamic Host Configuration Protocol (DHCP) provides for such remote host configuration. This draft explores the requirements for host configuration in IPSEC tunnel mode, and describes how the DHCP protocol may be leveraged for configuration in this case. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dhcp-08.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-dhcp-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-dhcp-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001127132453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-dhcp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-dhcp-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001127132453.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Nov 28 06:45:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA03534; Tue, 28 Nov 2000 06:45:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11242 Tue, 28 Nov 2000 08:19:42 -0500 (EST) Reply-To: From: "sridharj" To: , Subject: RE: Synchronisation in IKE Date: Sun, 5 Nov 2000 18:45:29 +0530 Message-Id: <000101c0472a$78cbe200$6e0c000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <0B3F42CA1FB6D2118FE50008C7894B0A051A9B78@eseis06nok> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Problem 1,2,3 : this problem can be solved if IKE keeps a HELLO or keep alive message periodically (not in rfc). Problem 4 : In this case B should send INVALID_COOKIE(rfc 2408) notify to A . -----Original Message----- From: owner-ipsec@lists.tislabs.com I think this is a very important issue and is giving me plenty of headaches. Is there any documents that talks about how to resynchronise IKE negotiations. Any advice on the subject would be greatly appreciated. Take as an Example the next case: 1- A (Initiator) negotiates with B (Responder) 2- B reboots and is unable to send any delete notification. 3- A can't talk to B anymore (A has IPSEC SAs, but no B) I have no solution for this. IDEAS? 4- IPSEC SAs in A expire. A Initiates a Quick mode negotiation but B doesn't have ISAKMP SAs either That could be solved letting A detect that B can't negotiate and initiating a new Phase I negotiation. Is there any problem with this solution? If yes is there an alternative? What do I do with the old ISAKMP SA? Keep or destroy it? I'd destroy it, but not sure if can give any problem. I'd really appreciate any response. Thanks in advance. Toni From owner-ipsec@lists.tislabs.com Tue Nov 28 08:04:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11426; Tue, 28 Nov 2000 08:04:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11502 Tue, 28 Nov 2000 09:42:05 -0500 (EST) Message-ID: <185401c05949$baecf530$83d62ca1@cisco.com> From: "Stephane Beaulieu" To: , References: <0B3F42CA1FB6D2118FE50008C7894B0A051A9B78@eseis06nok> Subject: Re: Synchronisation in IKE Date: Tue, 28 Nov 2000 09:44:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There are an few ways I've seen this solved. Though I've seen no consensus from the group on which is best. 1 - Use IKE Keepalives / Heartbeats. This gives you a method of detecting when a peer is dead / out of sync. 2 - When peer B reboots and sees packets with invalid SPIs, get B to initiate a new Phase 1 SA with peer A (with INITIAL-CONTACT notify). Don't overlook the DoS issue with this one though, as an attacker could be sending ESP packets with invalid SPIs all the time, so you might have to be picky about with who and how often you will do this. 3 - Have a stateful failover gateway ready to take over for the dead gate. Stephane. ----- Original Message ----- From: To: Sent: Tuesday, November 28, 2000 4:27 AM Subject: Synchronisation in IKE > I think this is a very important issue and is giving me plenty of > headaches. > Is there any documents that talks about how to resynchronise IKE > negotiations. > Any advice on the subject would be greatly appreciated. > Take as an Example the next case: > > 1- A (Initiator) negotiates with B (Responder) > 2- B reboots and is unable to send any delete notification. > 3- A can't talk to B anymore (A has IPSEC SAs, but no B) I have no > solution for this. IDEAS? > 4- IPSEC SAs in A expire. A Initiates a Quick mode negotiation but B > doesn't have ISAKMP SAs either > That could be solved letting A detect that B can't negotiate and > initiating a new Phase I negotiation. > Is there any problem with this solution? If yes is there an > alternative? > What do I do with the old ISAKMP SA? Keep or destroy it? I'd > destroy it, but not sure if can give any problem. > > I'd really appreciate any response. > Thanks in advance. > > Toni From owner-ipsec@lists.tislabs.com Tue Nov 28 08:05:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11529; Tue, 28 Nov 2000 08:05:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11468 Tue, 28 Nov 2000 09:35:33 -0500 (EST) To: henry@spsystems.net Cc: Francis.Dupont@enst-bretagne.fr, ipsec@lists.tislabs.com, mobile-ip@standards.nortelnetworks.com Subject: Re: RFC 2401 section 5.2.1 In-Reply-To: Your message of "Fri, 24 Nov 2000 12:34:48 -0500 (EST)" References: X-Mailer: Cue version 0.6 (001128-1517/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20001128233617M.sakane@ydc.co.jp> Date: Tue, 28 Nov 2000 23:36:17 +0900 From: "Shoichi 'Ne' Sakane" X-Dispatcher: imput version 990905(IM130) Lines: 12 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > ...and needed by many IPv6 protocols (cf Itojun's mail). > That is exactly the question: *should* those protocols be relying on the > quirks of AH? It would be better if they could also work with ESP. ESP can not protect all part of a IP packet. Both some IP headers in IPv6 and all IP options in IPv4 are not protected. Most outer IP header can not be protected by ESP if you use ESP tunnel mode to protect original IP apcket. I believe we need AH in spite of the IP version. /Shoichi `NE' Sakane @ KAME project/ From owner-ipsec@lists.tislabs.com Tue Nov 28 08:06:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11715; Tue, 28 Nov 2000 08:06:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11440 Tue, 28 Nov 2000 09:31:36 -0500 (EST) Message-Id: <200011281431.IAA05857@jumpsrv> X-Mailer: exmh version 2.1.1 10/15/1999 To: sridharj@future.futsoft.com cc: antonio.barrera@nokia.com, ipsec@lists.tislabs.com, carney@securecomputing.com Subject: Re: Synchronisation in IKE In-reply-to: Your message of "Sun, 05 Nov 2000 18:45:29 +0530." <000101c0472a$78cbe200$6e0c000a@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Nov 2000 08:31:04 -0600 From: Mike Carney Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Hi, > Problem 1,2,3 : this problem can be solved if IKE keeps a HELLO or keep > alive > message periodically (not in rfc). > Problem 4 : In this case B should send INVALID_COOKIE(rfc 2408) notify to A > . > I wouldn't recommend that solution as B would have to send an UN-encrypted notify (Since it doesn't have a Phase 1). And if Side A accepts UN-encrypted notifies for invalid cookie as an indication that Side B has lost it's phase 1, Side A is open to Spoofed notify DOS attack. ( I suppose Side B could initiate a phase 1 in order to send a protected notify ) Our solution is to retry QM's several times (3 by default) and if that fails, fall back to doing a Phase 1. If the Phase 1 fails to negotiate, the VPN is torn down. Regards, Michael Carney. > > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > > > > I think this is a very important issue and is giving me plenty of > headaches. > Is there any documents that talks about how to resynchronise IKE > negotiations. > Any advice on the subject would be greatly appreciated. > Take as an Example the next case: > > 1- A (Initiator) negotiates with B (Responder) > 2- B reboots and is unable to send any delete notification. > 3- A can't talk to B anymore (A has IPSEC SAs, but no B) I have no > solution for this. IDEAS? > 4- IPSEC SAs in A expire. A Initiates a Quick mode negotiation but B > doesn't have ISAKMP SAs either > That could be solved letting A detect that B can't negotiate and > initiating a new Phase I negotiation. > Is there any problem with this solution? If yes is there an > alternative? > What do I do with the old ISAKMP SA? Keep or destroy it? I'd > destroy it, but not sure if can give any problem. > > I'd really appreciate any response. > Thanks in advance. > > Toni > From owner-ipsec@lists.tislabs.com Tue Nov 28 08:11:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12092; Tue, 28 Nov 2000 08:11:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11503 Tue, 28 Nov 2000 09:42:08 -0500 (EST) From: "akshay" To: Subject: HI Date: Tue, 28 Nov 2000 04:44:02 +0530 Message-ID: <01c058c7$baf44240$4302a8c0@akshay> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C058F5.D4AC7E40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C058F5.D4AC7E40 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Can Anyone please tell the link from where I can get BSD code for IPSEC = for IPv4 as KAME project is having implementation for IPv6. regards Akshay ------=_NextPart_000_0018_01C058F5.D4AC7E40 Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable
Can Anyone please tell the link from = where I can=20 get BSD code for IPSEC for IPv4  as
KAME project = is having=20 implementation for IPv6.
 
 
 
regards
Akshay 
------=_NextPart_000_0018_01C058F5.D4AC7E40-- From owner-ipsec@lists.tislabs.com Tue Nov 28 08:40:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18700; Tue, 28 Nov 2000 08:40:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11609 Tue, 28 Nov 2000 10:10:50 -0500 (EST) Message-ID: <18fe01c0594d$c1659df0$83d62ca1@cisco.com> From: "Stephane Beaulieu" To: , , References: <000101c0472a$78cbe200$6e0c000a@future.futsoft.com> Subject: Re: Synchronisation in IKE Date: Tue, 28 Nov 2000 10:13:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > message periodically (not in rfc). > Problem 4 : In this case B should send INVALID_COOKIE(rfc 2408) notify to A This is correct behavior, though it doesn't really solve the problem. A will log the arrival of the INVALID-COOKIE which might alert some administrator to look into the problem. However, A will not self-correct the out of sync SAs since the INVALID-COOKIE notify is un-authenticated, and therefore untrusted. > . > > > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > > > > I think this is a very important issue and is giving me plenty of > headaches. > Is there any documents that talks about how to resynchronise IKE > negotiations. > Any advice on the subject would be greatly appreciated. > Take as an Example the next case: > > 1- A (Initiator) negotiates with B (Responder) > 2- B reboots and is unable to send any delete notification. > 3- A can't talk to B anymore (A has IPSEC SAs, but no B) I have no > solution for this. IDEAS? > 4- IPSEC SAs in A expire. A Initiates a Quick mode negotiation but B > doesn't have ISAKMP SAs either > That could be solved letting A detect that B can't negotiate and > initiating a new Phase I negotiation. > Is there any problem with this solution? If yes is there an > alternative? > What do I do with the old ISAKMP SA? Keep or destroy it? I'd > destroy it, but not sure if can give any problem. > > I'd really appreciate any response. > Thanks in advance. > > Toni > From owner-ipsec@lists.tislabs.com Tue Nov 28 08:52:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA20218; Tue, 28 Nov 2000 08:52:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11655 Tue, 28 Nov 2000 10:23:35 -0500 (EST) To: "akshay" cc: ipsec@lists.tislabs.com In-reply-to: akshay's message of Tue, 28 Nov 2000 04:44:02 +0530. <01c058c7$baf44240$4302a8c0@akshay> 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: HI From: itojun@iijlab.net Date: Wed, 29 Nov 2000 00:24:51 +0900 Message-ID: <22157.975425091@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Can Anyone please tell the link from where I can get BSD code for IPSEC = >for IPv4 as >KAME project is having implementation for IPv6. KAME does IPsec for both IPv4 and IPv6. http://www.kame.net/ should be clear enough. Also, most of *BSD projects have integrated past version of KAME kit (openbsd has its own IPsec stack). itojun From owner-ipsec@lists.tislabs.com Tue Nov 28 09:42:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25660; Tue, 28 Nov 2000 09:42:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11782 Tue, 28 Nov 2000 11:06:32 -0500 (EST) Date: Tue, 28 Nov 2000 11:06:37 -0500 (EST) From: Henry Spencer To: "Shoichi 'Ne' Sakane" cc: Francis.Dupont@enst-bretagne.fr, ipsec@lists.tislabs.com Subject: Re: RFC 2401 section 5.2.1 In-Reply-To: <20001128233617M.sakane@ydc.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (Note mobile-ip dropped from addressees list.) On Tue, 28 Nov 2000, Shoichi 'Ne' Sakane wrote: > > ...It would be better if they could also work with ESP. > > ESP can not protect all part of a IP packet... Correct. Neither can AH, although it protects slightly more than ESP. The question is whether it is wise for protocol designers to rely on the extra portions AH protects. Where possible, they should avoid that. > I believe we need AH in spite of the IP version. Perhaps. But the existence of protocols which depend on it should not be advanced as a reason, unless it is first demonstrated that those protocols fundamentally need AH and could not work with ESP. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Nov 28 11:31:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03983; Tue, 28 Nov 2000 11:31:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA12145 Tue, 28 Nov 2000 12:51:23 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <21716.974854600@coconut.itojun.org> References: <21716.974854600@coconut.itojun.org> Date: Tue, 28 Nov 2000 12:46:40 -0500 To: itojun@iijlab.net From: Stephen Kent Subject: Re: RFC 2401 section 5.2.1 Cc: ipsec@lists.tislabs.com, mobile-ip@standards.nortelnetworks.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >> do we want to use tunnel mode on non-VPN ipsec exchanges? > >> I don't think so. > >Why not? It can do everything transport mode does. (In particular, it is > >perfectly capable of working host-to-host.) > >"Recommendation 1: *Eliminate transport mode*. ...we do not know why > >IPsec has two modes... The extra cost of a second mode (in terms of added > >complexity and resulting loss of security) is huge..." -- Ferguson >& Schneier > > first of all, chews MTU. tunnel-mode-just-for-avoiding-transport-mode > does not seem to be the same as transport mode for me. > > >It would be sensible to retain both if transport mode was the fundamental > >IPsec mode and tunnel mode was *just* IPIP tunneling over a transport-mode > >connection. But it's not. (If it were, tunnel mode could be explained in > >a single footnote in RFC 2401, rather than having implications everywhere.) > > i still do not get why RFC2401 includes tunnel mode. I believe > this was introduced for single reason: to make it easier to negotiate > tunnel setup as well as IPsec setup, with IKE. there are enough number > of prior art for tunnelling available before 2401 (at least 7 > specifications, before and after 2401, use IP protocol #4. > 4 specifications use IP protocol #41). > if an implementation A handles IPsec tunnel mode as transport > mode with tunnels, does it break 2401 conformance? I understand > that if the peer i too picky about header field the peer will drop > the packet. also I understand we need some trick in IKE code, to > setup tunnels AND IPsec transport-mode SAs as necessary. Tunnel mode was defined for IPsec because it has processing (vs. syntax) implications that are different than using IP-in-IP tunneling in conjunction with transport mode, as has been mentioned on this list many times in the past. Steve From owner-ipsec@lists.tislabs.com Tue Nov 28 16:14:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18266; Tue, 28 Nov 2000 16:14:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13115 Tue, 28 Nov 2000 17:27:42 -0500 (EST) Date: Tue, 28 Nov 2000 17:28:16 -0500 (EST) From: Henry Spencer To: Dan Harkins cc: Francis Dupont , ipsec@lists.tislabs.com, mobile-ip@standards.nortelnetworks.com Subject: Re: RFC 2401 section 5.2.1 In-Reply-To: <200011270152.RAA24730@potassium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, 26 Nov 2000, Dan Harkins wrote: > > seems to us that tunnel mode actually gives slightly higher security, > > because it obscures whether the communication really *is* end-to-end... > > Obscured from whom? Don't transport mode and tunnel mode packets look > identical to a passive evesdropper since the Next Header field is encrypted? Unless the senders are doing clever things with padding etc., on most links he can quickly tell whether tunneling is being done by inspecting the low end of the packet-length distribution. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Nov 28 16:14:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18288; Tue, 28 Nov 2000 16:14:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13163 Tue, 28 Nov 2000 17:35:20 -0500 (EST) Date: Tue, 28 Nov 2000 17:35:21 -0500 (EST) From: Henry Spencer To: Joe Touch cc: Lars Eggert , ipsec@lists.tislabs.com Subject: Re: RFC 2401 section 5.2.1 In-Reply-To: <3A1C47EC.EF58E15@isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 22 Nov 2000, Joe Touch wrote: > > > Tunnel mode (in current implementations I'm aware of, at least) does not > > > support dynamic routing inside a VPN, since IPsec tunnels aren't > > > represented in routing tables. > > This is a problem in routing implementation, not IPsec tunnel mode... > > This would require synchronizing updates to the key databases with > updates to the routing tables. Quite so, in the same way that it requires synchronizing updates to hardware status with updates to the routing tables. This does not seem conceptually difficult; the IPsec SAs are just virtual wires, so when their status changes, routing has to know about it. > > > What does tunnel mode give you that IPIP tunnels + IPsec transport mode > > > don't? > > Most notably, IPsec SPD checking of the inner headers... > > You can set that rule when you setup the tunnel. It need not > be an integrated function of setting the transport IPSEC. But which IPsec SA the packet emerged from is significant information for the checking. The two cannot safely be divorced; checking *does* need to be an integrated function of IPsec setup. Unfortunate but inevitable (except in some favorable special cases). Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Nov 28 16:19:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18506; Tue, 28 Nov 2000 16:18:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13201 Tue, 28 Nov 2000 17:48:28 -0500 (EST) Message-Id: <200011282248.eASMmEa102347@thunk.east.sun.com> From: Bill Sommerfeld To: Henry Spencer cc: Joe Touch , Lars Eggert , ipsec@lists.tislabs.com Subject: Re: RFC 2401 section 5.2.1 In-reply-to: Your message of "Tue, 28 Nov 2000 17:35:21 EST." Reply-to: sommerfeld@East.Sun.COM Date: Tue, 28 Nov 2000 17:48:14 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > But which IPsec SA the packet emerged from is significant information for > the checking. The two cannot safely be divorced; checking *does* need to > be an integrated function of IPsec setup. Unfortunate but inevitable > (except in some favorable special cases). who says you have to discard that information as part of ipsec decapsulation? stacks typically have to retain a bunch of metadata associated with the packet on the way up; the inbound SA information is just part of this. - Bill From owner-ipsec@lists.tislabs.com Tue Nov 28 16:29:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18924; Tue, 28 Nov 2000 16:29:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13282 Tue, 28 Nov 2000 18:05:37 -0500 (EST) Message-ID: <3A243A1F.4B4FEF37@isi.edu> Date: Tue, 28 Nov 2000 15:05:03 -0800 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Henry Spencer CC: Lars Eggert , ipsec@lists.tislabs.com Subject: Re: RFC 2401 section 5.2.1 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer wrote: > > On Wed, 22 Nov 2000, Joe Touch wrote: > > > > Tunnel mode (in current implementations I'm aware of, at least) does not > > > > support dynamic routing inside a VPN, since IPsec tunnels aren't > > > > represented in routing tables. > > > This is a problem in routing implementation, not IPsec tunnel mode... > > > > This would require synchronizing updates to the key databases with > > updates to the routing tables. > > Quite so, in the same way that it requires synchronizing updates to > hardware status with updates to the routing tables. This does not seem > conceptually difficult; the IPsec SAs are just virtual wires, so when > their status changes, routing has to know about it. It's actually the other way around that's harder - the key database has to be changed when the link goes down. This means gated/mrtd needs to communicate with the key database. Links going down aren't necessarily local - this happens any time a route (in the routing table) changes. > > > > What does tunnel mode give you that IPIP tunnels + IPsec transport mode > > > > don't? > > > Most notably, IPsec SPD checking of the inner headers... > > > > You can set that rule when you setup the tunnel. It need not > > be an integrated function of setting the transport IPSEC. > > But which IPsec SA the packet emerged from is significant information for > the checking. Yes - that's why you're supposed to retain it with the decrypted packet anyway. Joe From owner-ipsec@lists.tislabs.com Tue Nov 28 17:35:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA20554; Tue, 28 Nov 2000 17:35:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA13422 Tue, 28 Nov 2000 19:05:39 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200011282248.eASMmEa102347@thunk.east.sun.com> References: <200011282248.eASMmEa102347@thunk.east.sun.com> Date: Tue, 28 Nov 2000 19:05:04 -0500 To: sommerfeld@East.Sun.COM From: Stephen Kent Subject: Re: RFC 2401 section 5.2.1 Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill, I think it is feasible to maintain the SA info within a single "system" for later AC checking, and that would not be subject to standardization. However, I would not expect to create a standard transfer representation for that sort of info to carry with a packet once it is outside a system, e.g., a packet existing an IPsec device and heading to a separate firewall. I don't think you were suggesting this, but I did want to mention the difference. Steve From owner-ipsec@lists.tislabs.com Tue Nov 28 18:49:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA22354; Tue, 28 Nov 2000 18:49:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA13668 Tue, 28 Nov 2000 20:25:02 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14884.23284.87062.845921@thomasm-u1.cisco.com> Date: Tue, 28 Nov 2000 17:25:08 -0800 (PST) To: Henry Spencer Cc: "Shoichi 'Ne' Sakane" , Francis.Dupont@enst-bretagne.fr, ipsec@lists.tislabs.com Subject: Re: RFC 2401 section 5.2.1 In-Reply-To: References: <20001128233617M.sakane@ydc.co.jp> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > Perhaps. But the existence of protocols which depend on it should not be > advanced as a reason, unless it is first demonstrated that those protocols > fundamentally need AH and could not work with ESP. The canonical example I keep hearing about is that ip6 binding updates require AH and can't live with ESP. I'm not sure I buy that, and I'm not sure whether there isn't tail-wagging-dog going on there, but until that gets sorted out, AH at least has one vocal set of partisans. Mike From owner-ipsec@lists.tislabs.com Tue Nov 28 21:05:20 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA25184; Tue, 28 Nov 2000 21:05:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA13898 Tue, 28 Nov 2000 22:28:17 -0500 (EST) From: "akshay" To: Subject: Transport / Tunnel Mode Date: Tue, 28 Nov 2000 21:01:56 +0530 Message-ID: <01c05950$57ab6540$4302a8c0@akshay> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C0597E.7163A140" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C0597E.7163A140 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Hi As per RFC 2402 under 1 i.e. definition and scope " The requirement for any (transit traffic) SA involving a security gateway to be a tunnel SA arises due to the need to avoid potential problems with regard to fragmentation and reassembly of IPsec packets, and in circumstances where multiple paths (e.g., via different security gateways) exist to the same destination behind the security gateways. " Can any one please explain , How we can avoid fragmentation / ressembly = in tunnel mode and why it is not possible in transport mode . WHY IN SECURITY GATEWAY IT IS REQUIRED TO USE TUNNEL MODE ONLY ?? Cheers Akshay ------=_NextPart_000_0028_01C0597E.7163A140 Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable
 
Hi
As per RFC 2402 under 1 i.e. = definition=20 and scope 

" The requirement for any = (transit=20 traffic) SA involving a
security gateway to be a tunnel SA arises = due to the=20 need to avoid
potential problems with regard to fragmentation and = reassembly=20 of
IPsec packets, and in circumstances where multiple paths (e.g., = via
=20 different security gateways) exist to the same destination behind = the
=20 security gateways. " 
 
Can any one please explain , How we = can avoid=20 fragmentation / ressembly in
tunnel mode and why it is not possible = in=20 transport mode . 
WHY IN SECURITY GATEWAY IT IS = REQUIRED TO USE=20 TUNNEL
MODE ONLY ?? 
 
Cheers
Akshay 
 
------=_NextPart_000_0028_01C0597E.7163A140-- From owner-ipsec@lists.tislabs.com Wed Nov 29 03:27:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01329; Wed, 29 Nov 2000 03:27:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA14870 Wed, 29 Nov 2000 04:29:28 -0500 (EST) Reply-To: From: "Awan Kumar Sharma" To: "'akshay'" Cc: "IpsecMailingList (E-mail)" Subject: RE: Transport / Tunnel Mode Date: Wed, 29 Nov 2000 15:01:27 +0530 Message-Id: <001401c059e7$26ef2c60$6d0c000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <01c05950$57ab6540$4302a8c0@akshay> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C05A15.40A76860" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C05A15.40A76860 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Hi, First of all I would like to correct you for your question. Whatever has been mentioned by you is in RFC 2401 and not 2402 as you have mentioned and under section 4.1. Now taking up your question, let us take this topology. PC1 is a host in Network 1 with GW1 as the Security Gateway. The Network (Network 1) is also reachable through R1. Similarly, PC2 is a host in Network 2 with GW2 as the Security Gateway. The Network (Network 2) is also reachable through R2. Now when PC2 sends a packet to PC1, which has to be protected by IPSec, GW2 (security GW for Network 2) will provide the IPSec security. If it is using Transport mode SA, then the packet will look like [IP][IPSEC Header][ULP]. This is with reference to RFC 2401 only ) Note that the IP contains the IP address of PC2 as source address and PC1 as the destination address. This packet has to be routed to Network 1. Network 1 is reachable through GW1 and R1. Due to the routing decisions, if the packet is routed through R1 ( Note that R1 is not the security gateway for PC1), seeing the address as PC1, R1 will forward the packet to PC1, which is not at all capable to understanding the IPSec protected packets. To avoid this type of situation, if the packets are tunneled, after IPSec processing by GW2, packet will look like [IPo][IPSec][IPi][ULP], where IPo is the outer IP header containing GW1 as the destination and GW2 as the source. This makes sure that the packet will reach GW1, so that it can provide the necessary IPSec processing and forward the packet to PC1. Any comments regarding this is most welcome. Regards, Awan. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of akshay Sent: Tuesday, November 28, 2000 9:02 PM To: ipsec@lists.tislabs.com Subject: Transport / Tunnel Mode Hi As per RFC 2402 under 1 i.e. definition and scope " The requirement for any (transit traffic) SA involving a security gateway to be a tunnel SA arises due to the need to avoid potential problems with regard to fragmentation and reassembly of IPsec packets, and in circumstances where multiple paths (e.g., via different security gateways) exist to the same destination behind the security gateways. " Can any one please explain , How we can avoid fragmentation / ressembly in tunnel mode and why it is not possible in transport mode . WHY IN SECURITY GATEWAY IT IS REQUIRED TO USE TUNNEL MODE ONLY ?? Cheers Akshay ------=_NextPart_000_0015_01C05A15.40A76860 Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable
Hi,
First of all I would like to correct you for = your=20 question. Whatever has been mentioned by you is in RFC 2401 and not 2402 = as you=20 have mentioned and under section 4.1.
 
Now=20 taking up your question, let us take this topology. PC1 is a host in = Network 1=20 with GW1 as the Security Gateway. The Network (Network 1) is also = reachable=20 through R1. Similarly, PC2 is a host in Network 2 with GW2 as the = Security=20 Gateway. The Network (Network 2) is also reachable through R2.=20
 
Now=20 when PC2 sends a packet to PC1, which has to be protected by IPSec, GW2=20 (security GW for Network 2) will provide the IPSec security. If it is = using=20 Transport mode SA, then the packet will look like [IP][IPSEC = Header][ULP]. (=20 This is with reference to RFC 2401 only ) Note that the IP contains the = IP=20 address of PC2 as source address and PC1 as the destination address. = This packet=20 has to be routed to Network 1. Network 1 is reachable through GW1 and = R1. Due to=20 the routing decisions, if the packet is routed through R1 ( Note that R1 = is not=20 the security gateway for PC1), seeing the address as PC1, R1 will = forward the=20 packet to PC1, which is not at all capable to understanding the IPSec = protected=20 packets.
 
To=20 avoid this type of situation, if the packets are tunneled, after IPSec=20 processing by GW2, packet will look like
       =20 [IPo][IPSec][IPi][ULP], where IPo is the outer IP header containing GW1 = as the=20 destination and GW2 as the source. This makes sure that the packet will = reach=20 GW1, so that it can provide the necessary IPSec processing and forward = the=20 packet to PC1.
 
Any=20 comments regarding this is most welcome.
 
Regards,
Awan.
 
       &nbs= p;   =20

-----Original Message-----
From:=20 owner-ipsec@lists.tislabs.com = [mailto:owner-ipsec@lists.tislabs.com]On=20 Behalf Of akshay
Sent: Tuesday, November 28, 2000 9:02=20 PM
To: ipsec@lists.tislabs.com
Subject: Transport = / Tunnel=20 Mode

 
Hi
As per RFC 2402 under 1 i.e. = definition=20 and scope 

" The requirement for any = (transit=20 traffic) SA involving a
security gateway to be a tunnel SA arises = due to=20 the need to avoid
potential problems with regard to fragmentation = and=20 reassembly of
IPsec packets, and in circumstances where multiple = paths=20 (e.g., via
different security gateways) exist to the same = destination=20 behind the
security gateways. " 
 
Can any one please explain , How = we can avoid=20 fragmentation / ressembly in
tunnel mode and why it is not possible = in=20 transport mode . 
WHY IN SECURITY GATEWAY IT IS = REQUIRED TO USE=20 TUNNEL
MODE ONLY ?? 
 
Cheers
Akshay 
 
------=_NextPart_000_0015_01C05A15.40A76860-- From owner-ipsec@lists.tislabs.com Wed Nov 29 04:57:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA08303; Wed, 29 Nov 2000 04:57:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA15112 Wed, 29 Nov 2000 06:26:09 -0500 (EST) Message-Id: <200011291127.GAA29665@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-doi-tc-mib-04.txt Date: Wed, 29 Nov 2000 06:27:28 -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 : IPsec DOI Textual Conventions MIB Author(s) : J. Shriver Filename : draft-ietf-ipsec-doi-tc-mib-04.txt Pages : 23 Date : 28-Nov-00 This memo defines textual conventions for use in monitoring, status, and configuration MIBs for IPSec. It includes a MIB module that defines those textual conventions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-doi-tc-mib-04.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-doi-tc-mib-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-doi-tc-mib-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001128133604.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-doi-tc-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-doi-tc-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128133604.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Nov 29 05:00:20 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA08359; Wed, 29 Nov 2000 05:00:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA15121 Wed, 29 Nov 2000 06:26:15 -0500 (EST) Message-Id: <200011291127.GAA29692@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ike-ext-meth-04.txt Date: Wed, 29 Nov 2000 06:27:33 -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 : ISAKMP & IKE Extensions Methods Author(s) : T. Kivinen Filename : draft-ietf-ipsec-ike-ext-meth-04.txt Pages : 13 Date : 28-Nov-00 This document describes multiple extension methods of the ISAKMP [RFC 2408] and IKE [RFC 2409] protocols and how the older versions should respond when they receive such extensions. This document mainly tries to describe the best practice of extensions handling in ISAKMP [RFC 2408] and IKE [RFC 2409], so that a future version can be made without break- ing the old existing versions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-ext-meth-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ike-ext-meth-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-ext-meth-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001128133617.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-ext-meth-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-ext-meth-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128133617.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Nov 29 05:01:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA08392; Wed, 29 Nov 2000 05:01:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA15109 Wed, 29 Nov 2000 06:26:08 -0500 (EST) Message-Id: <200011291127.GAA29624@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ike-hash-revised-02.txt Date: Wed, 29 Nov 2000 06:27:24 -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 : Fixing IKE Phase 1 & 2 Authentication HASH Author(s) : T. Kivinen Filename : draft-ietf-ipsec-ike-hash-revised-02.txt Pages : 6 Date : 28-Nov-00 This document defines new method of calculating the authentication HASH of the IKE [RFC-2409] protocol. It fixes known problems with the IKE. The way the HASH is currently defined in the [RFC-2409] does not authen- ticate the generic ISAKMP [RFC-2408] header, nor does it authenticate any extra payloads inside phase 1 packets. This causes a security prob- lem when using extra payloads as already defined in the IKE and DOI [RFC-2407] (vendor ID payload, INITIAL-CONTACT notification etc). This document defines three methods how to negotiate the new HASH method. All methods tries to be backward compatible as much as possible. Only one of those methods must be selected by the working group and all the other should be removed from this document. There is also suggestion how to fix the Phase 2 authentication hashes so that they will also authenti- cate the generic ISAKMP header. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-hash-revised-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ike-hash-revised-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-hash-revised-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001128133553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-hash-revised-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-hash-revised-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128133553.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Nov 29 05:02:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA08415; Wed, 29 Nov 2000 05:02:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA15128 Wed, 29 Nov 2000 06:26:21 -0500 (EST) Message-Id: <200011291127.GAA29773@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-aes-cbc-01.txt Date: Wed, 29 Nov 2000 06:27:41 -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 : The Candidate AES Cipher Algorithms and Their Use With IPsec Author(s) : S. Frankel, S. Kelly, R. Glenn Filename : draft-ietf-ipsec-ciph-aes-cbc-01.txt Pages : 16 Date : 28-Nov-00 This document describes the use of the AES Cipher Algorithm in Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mecha- nism within the context of the IPsec Encapsulating Security Payload (ESP). This Internet Draft also describes the use of the four other AES fi- nalist candidate algorithms in the ESP Header. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ciph-aes-cbc-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-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: <20001128133638.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-aes-cbc-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128133638.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Nov 29 05:06:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA08499; Wed, 29 Nov 2000 05:06:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA15127 Wed, 29 Nov 2000 06:26:18 -0500 (EST) Message-Id: <200011291127.GAA29746@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ike-modp-groups-01.txt Date: Wed, 29 Nov 2000 06:27:37 -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 : More MODP Diffie-Hellman groups for IKE Author(s) : T. Kivinen, M. Kojo Filename : draft-ietf-ipsec-ike-modp-groups-01.txt Pages : 6 Date : 28-Nov-00 This document defines new MODP groups for the IKE [RFC-2409] protocol. It documents the well know and used 1536 bit group 5, and also defines new 2048, 3072, and 4096 bit Diffie-Hellman groups. The groups are gen- erated using the guidelines defined in the [RFC-2412]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-modp-groups-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ike-modp-groups-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-modp-groups-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: <20001128133628.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-modp-groups-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-modp-groups-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128133628.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Nov 29 05:53:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA12356; Wed, 29 Nov 2000 05:53:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA15263 Wed, 29 Nov 2000 07:13:18 -0500 (EST) Message-ID: <3A24F341.24C5D1E8@helios.iihe.ac.be> Date: Wed, 29 Nov 2000 13:14:57 +0100 From: Alain Jourez X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: akshay CC: ipsec@lists.tislabs.com Subject: Re: Transport / Tunnel Mode References: <01c05950$57ab6540$4302a8c0@akshay> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id HAA15260 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk akshay wrote: > Hi > As per RFC 2402 under 1 i.e. definition and scope > " The requirement for any (transit traffic) SA involving a > security gateway to be a tunnel SA arises due to the need to avoid > potential problems with regard to fragmentation and reassembly of > IPsec packets, and in circumstances where multiple paths (e.g., via > different security gateways) exist to the same destination behind the > security gateways. " Can any one please explain , How we can avoid > fragmentation / ressembly in > tunnel mode and why it is not possible in transport mode .WHY IN > SECURITY GATEWAY IT IS REQUIRED TO USE TUNNEL > MODE ONLY ?? Cheers > Akshay The problem with fragmentation (at least in IPv4) is that you cannot ensure that a fragment will be routed through a specific route. Thus two fragments form the same datagram may arrive by different ways to the endpoint and enter a specific network by different security gateways. Only the endpoint is requiered to do reassembly. If you try to apply transport mode between security gateways, two fragments may enter the network by two different gateways. Since they cannot reassemble the complete datagram, the "ingress" gateways cannot perform the cryptographic functions they are supposed to do (check the integrity, authenticate, decrypt ...). The problem does not arise when two security gateways use tunnel mode, since the "ingress" gateway is the endpoint and can reassemble the complete datagram before IPsec is applied. Hope this helps cheers. Alain -- Alain Jourez Service Télématique et Communication Université Libre de Bruxelles Tél. +32 (0) 2 650 57 04 Boulevard du Triomphe, CP 230 Fax +32 (0) 2 629 38 16 B-1050 Bruxelles - Belgium mailto:alain.jourez@helios.iihe.ac.be From owner-ipsec@lists.tislabs.com Wed Nov 29 12:02:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA07514; Wed, 29 Nov 2000 12:02:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16946 Wed, 29 Nov 2000 13:16:53 -0500 (EST) Message-ID: <7695E2F6903F7A41961F8CF888D87EA8014699FD@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: ipsec@lists.tislabs.com Subject: RE: RFC 2401 section 5.2.1 Date: Wed, 29 Nov 2000 10:17:36 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Henry Spencer writes: > > Perhaps. But the existence of protocols which depend on > it should not be > > advanced as a reason, unless it is first demonstrated that > those protocols > > fundamentally need AH and could not work with ESP. > > The canonical example I keep hearing about is that > ip6 binding updates require AH and can't live > with ESP. I'm not sure I buy that, and I'm not > sure whether there isn't tail-wagging-dog > going on there, but until that gets sorted out, > AH at least has one vocal set of partisans. What started this whole thread was my contention that Mobile IPv6 Binding Updates *can* be protected by ESP, and Francis wanting to check the interpretation of RFC 2401 section 5.2.1 because it is relevant. The issue is this text: 2. Use the SA found in (1) to do the IPsec processing, e.g., authenticate and decrypt. This step includes matching the packet's (Inner Header if tunneled) selectors to the selectors in the SA. Local policy determines the specificity of the SA selectors (single value, list, range, wildcard). In general, a packet's source address MUST match the SA selector value. However, an ICMP packet received on a tunnel mode SA may have a source address The text reads as if the comparison of the packet source address and the SA selector value happens immediately, before you proceed to look at any headers after/inside the IPsec header. Whereas to support Mobile IPv6, you want to delay the selector checks (against the SA as well as against the SPD) until you've reached the transport header (or are otherwise going to actually do something with the packet) - so that a Home Address option that follows the IPsec header can be processed before the source address check. Rich From owner-ipsec@lists.tislabs.com Wed Nov 29 15:06:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16621; Wed, 29 Nov 2000 15:06:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17501 Wed, 29 Nov 2000 16:38:48 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: , "'akshay'" Cc: "'IpsecMailingList (E-mail)'" Subject: RE: Transport / Tunnel Mode Date: Wed, 29 Nov 2000 16:28:32 -0500 Message-Id: <002a01c05a4b$69945630$1e72788a@andrewk3.ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" 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: <001401c059e7$26ef2c60$6d0c000a@future.futsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk And isn't there also the issue that you couldn't use ESP authentication with sgw-sgw or host-sgw transport mode? AH would again become mandatory in order to protect the outer (and only) header. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Awan Kumar Sharma Sent: Wednesday, November 29, 2000 4:31 AM To: 'akshay' Cc: IpsecMailingList (E-mail) Subject: RE: Transport / Tunnel Mode Hi, First of all I would like to correct you for your question. Whatever has been mentioned by you is in RFC 2401 and not 2402 as you have mentioned and under section 4.1. Now taking up your question, let us take this topology. PC1 is a host in Network 1 with GW1 as the Security Gateway. The Network (Network 1) is also reachable through R1. Similarly, PC2 is a host in Network 2 with GW2 as the Security Gateway. The Network (Network 2) is also reachable through R2. Now when PC2 sends a packet to PC1, which has to be protected by IPSec, GW2 (security GW for Network 2) will provide the IPSec security. If it is using Transport mode SA, then the packet will look like [IP][IPSEC Header][ULP]. This is with reference to RFC 2401 only ) Note that the IP contains the IP address of PC2 as source address and PC1 as the destination address. This packet has to be routed to Network 1. Network 1 is reachable through GW1 and R1. Due to the routing decisions, if the packet is routed through R1 ( Note that R1 is not the security gateway for PC1), seeing the address as PC1, R1 will forward the packet to PC1, which is not at all capable to understanding the IPSec protected packets. To avoid this type of situation, if the packets are tunneled, after IPSec processing by GW2, packet will look like [IPo][IPSec][IPi][ULP], where IPo is the outer IP header containing GW1 as the destination and GW2 as the source. This makes sure that the packet will reach GW1, so that it can provide the necessary IPSec processing and forward the packet to PC1. Any comments regarding this is most welcome. Regards, Awan. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of akshay Sent: Tuesday, November 28, 2000 9:02 PM To: ipsec@lists.tislabs.com Subject: Transport / Tunnel Mode Hi As per RFC 2402 under 1 i.e. definition and scope " The requirement for any (transit traffic) SA involving a security gateway to be a tunnel SA arises due to the need to avoid potential problems with regard to fragmentation and reassembly of IPsec packets, and in circumstances where multiple paths (e.g., via different security gateways) exist to the same destination behind the security gateways. " Can any one please explain , How we can avoid fragmentation / ressembly in tunnel mode and why it is not possible in transport mode . WHY IN SECURITY GATEWAY IT IS REQUIRED TO USE TUNNEL MODE ONLY ?? Cheers Akshay From owner-ipsec@lists.tislabs.com Wed Nov 29 17:00:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA21164; Wed, 29 Nov 2000 17:00:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17748 Wed, 29 Nov 2000 18:28:18 -0500 (EST) Date: Wed, 29 Nov 2000 18:28:56 -0500 (EST) From: Henry Spencer To: Andrew Krywaniuk cc: "'IpsecMailingList (E-mail)'" Subject: RE: Transport / Tunnel Mode In-Reply-To: <002a01c05a4b$69945630$1e72788a@andrewk3.ca.alcatel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 29 Nov 2000, Andrew Krywaniuk wrote: > And isn't there also the issue that you couldn't use ESP authentication with > sgw-sgw or host-sgw transport mode? AH would again become mandatory in order > to protect the outer (and only) header. Not (absolutely) necessarily. In IPv4 in particular, AH protects very little that's of interest except the source and destination addresses. Remember that authentication tells you not only that the packet has not been altered in transit, but also that it did actually come from the other end of that SA. Depending on which packets are flowing through which SAs, the mere fact that a packet emerged from a particular SA (and passed its authentication) might be enough to verify source and destination addresses. As others have noted, and as RFC 2401 explicitly states in 4.1, the bottom line is that multiple fragments may not follow the same route to reach their destination. So when decryption (etc.) is being done by an interposed security gateway rather than by the end host, the security gateway must be the ostensible destination of the packet, so it can be sure it gets all the fragments. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Nov 29 17:26:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA21959; Wed, 29 Nov 2000 17:26:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA17836 Wed, 29 Nov 2000 19:05:44 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Henry Spencer'" , "'Andrew Krywaniuk'" Cc: "'IpsecMailingList (E-mail)'" Subject: RE: Transport / Tunnel Mode Date: Wed, 29 Nov 2000 18:54:58 -0500 Message-Id: <002e01c05a60$0b62f9d0$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: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Of course the routing and fragmentation issues are important. I was merely pointing out an additional security flaw with transport mode ESP. If the transport mode SA is host-sgw or sgw-sgw such that the SA may cover a range of IPs, AH must be used in order to protect the IPs. Otherwise, an intermediate router can redirect the traffic to a different host behind the gateway, which could aid a combined internal-external attack. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Henry Spencer [mailto:henry@spsystems.net] > Sent: Wednesday, November 29, 2000 6:29 PM > To: Andrew Krywaniuk > Cc: 'IpsecMailingList (E-mail)' > Subject: RE: Transport / Tunnel Mode > > > On Wed, 29 Nov 2000, Andrew Krywaniuk wrote: > > And isn't there also the issue that you couldn't use ESP > authentication with > > sgw-sgw or host-sgw transport mode? AH would again become > mandatory in order > > to protect the outer (and only) header. > > Not (absolutely) necessarily. In IPv4 in particular, AH protects very > little that's of interest except the source and destination > addresses. > Remember that authentication tells you not only that the > packet has not > been altered in transit, but also that it did actually come > from the other > end of that SA. Depending on which packets are flowing > through which SAs, > the mere fact that a packet emerged from a particular SA (and > passed its > authentication) might be enough to verify source and > destination addresses. > > As others have noted, and as RFC 2401 explicitly states in > 4.1, the bottom > line is that multiple fragments may not follow the same route to reach > their destination. So when decryption (etc.) is being done by an > interposed security gateway rather than by the end host, the security > gateway must be the ostensible destination of the packet, so it can be > sure it gets all the fragments. > > > Henry Spencer > > henry@spsystems.net > > > From owner-ipsec@lists.tislabs.com Thu Nov 30 05:02:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA09612; Thu, 30 Nov 2000 05:02:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA19316 Thu, 30 Nov 2000 05:50:50 -0500 (EST) Message-Id: <200011301051.FAA25467@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-notifymsg-04.txt Date: Thu, 30 Nov 2000 05:51:55 -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 : Content Requirements for ISAKMP Notify Messages Author(s) : S. Kelly, T. Kivinen Filename : draft-ietf-ipsec-notifymsg-04.txt Pages : 28 Date : 29-Nov-00 The ISAKMP and DOI RFCs [RFC2408, RFC2407] specify error and status message types for use in ISAKMP NOTIFY messages, but in some cases do not specify that any additional clarifying data be carried in the messages. In these cases, it is difficult to determine which SA corresponds to the received NOTIFY message. While the DOI RFC specifies content and formats for additional data in the currently defined IPSEC status messages, no such requirements are currently specified for ISAKMP NOTIFY messages. This document provides content and format recommendations for those messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-notifymsg-04.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-notifymsg-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-notifymsg-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001129114023.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-notifymsg-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-notifymsg-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001129114023.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Nov 30 20:46:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA01126; Thu, 30 Nov 2000 20:46:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA22408 Thu, 30 Nov 2000 22:17:14 -0500 (EST) Date: Thu, 30 Nov 2000 19:17:53 -0800 (PST) From: Jan Vilhuber To: Mike Carney cc: sridharj@future.futsoft.com, antonio.barrera@nokia.com, ipsec@lists.tislabs.com Subject: Re: Synchronisation in IKE In-Reply-To: <200011281431.IAA05857@jumpsrv> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 28 Nov 2000, Mike Carney wrote: > > Hi, > > Problem 1,2,3 : this problem can be solved if IKE keeps a HELLO or keep > > alive > > message periodically (not in rfc). > > Problem 4 : In this case B should send INVALID_COOKIE(rfc 2408) notify to A > > . > > > > I wouldn't recommend that solution as B would have to send an UN-encrypted > notify (Since it doesn't have a Phase 1). And if Side A accepts UN-encrypted > notifies for invalid cookie as an indication that Side B has lost it's > phase 1, Side A is open to Spoofed notify DOS attack. ( I suppose Side B could > initiate a phase 1 in order to send a protected notify ) > > Our solution is to retry QM's several times (3 by default) and if that fails, > fall back to doing a Phase 1. If the Phase 1 fails to negotiate, the VPN is > torn down. > But how do you know to send a QM? The problem is that host A is sending packets to B. B is silently discarding them, because B rebooted or lost SA's or whatever. B can send send an unprotected notify, but that has DoS problems, if A actually heeds the unprotected notify. B can initiate a QM (or phase 1), but again there are DoS problems (As stephane pointed out). There's no 100% secure way that B can let A know that it doesn't have SA's for the traffic that A is sending. Keepalives are fine, but are a somewhat expensive approach (although there's some rather decent solutions; also it's arguable if keepalives aren't something that a routing protocol is supposed to be doing). The only other thing is to do some rate-limiting and trade-offs so that the DoS problems can be bounded (Have B send unprotected notifies to A every 20-100 packets (I just made up those numbers), and have A discard them, unless it got more than, say, 5, AND it actually sent the traffic that's being complained about recently. Then it MIGHT behoove itself to initiate a new QM or phase 1 to B, and the DoS Problems have at least been reduced, although that's arguable). I don't see where A could figure this out on its own, so i don't quite understand your 'Our solution is to retry QM's several times' above... Let me know if I missed something, jan > Regards, > Michael Carney. > > > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > > > > > > > I think this is a very important issue and is giving me plenty of > > headaches. > > Is there any documents that talks about how to resynchronise IKE > > negotiations. > > Any advice on the subject would be greatly appreciated. > > Take as an Example the next case: > > > > 1- A (Initiator) negotiates with B (Responder) > > 2- B reboots and is unable to send any delete notification. > > 3- A can't talk to B anymore (A has IPSEC SAs, but no B) I have no > > solution for this. IDEAS? > > 4- IPSEC SAs in A expire. A Initiates a Quick mode negotiation but B > > doesn't have ISAKMP SAs either > > That could be solved letting A detect that B can't negotiate and > > initiating a new Phase I negotiation. > > Is there any problem with this solution? If yes is there an > > alternative? > > What do I do with the old ISAKMP SA? Keep or destroy it? I'd > > destroy it, but not sure if can give any problem. > > > > I'd really appreciate any response. > > Thanks in advance. > > > > Toni > > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Nov 30 20:47:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA01149; Thu, 30 Nov 2000 20:47:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA22377 Thu, 30 Nov 2000 21:49:55 -0500 (EST) Message-Id: <4.2.0.58.20001130214633.00b0a2b0@mail2.netreach.net> X-Sender: lphifer@pop.fast.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 30 Nov 2000 21:46:54 -0500 To: ipsec@lists.tislabs.com From: Lisa Phifer Subject: TISC 2001 Call for Papers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The Fifth Internet Security Conference will be held June 4-8, 2001 at the Century Plaza Hotel and Tower, 2025 Avenue of the Stars, Century City Los Angeles, CA 90067-4696. TISC is an educational forum for security professionals and practitioners. The TISC Security Symposium is an opportunity for individuals to share their expertise and practical experience with others involved in the design, implementation and deployment of networked security systems. We cordially invite you to submit an abstract for an original paper. Accepted papers will be presented at the conference. We also invite you to submit a session abstract for consideration, or if you prefer, to present a topic as a panel member. We encourage you to submit abstracts and topics by December 8. Further information can be found at http://tisc.corecom.com. Or send your proposal to our program chair, Dave Piscitello, dave@corecom.com. We look forward to your participation. Thank you. Best Regards, Lisa Phifer On behalf of the TISC Advisory Board From owner-ipsec@lists.tislabs.com Thu Nov 30 23:55:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA20479; Thu, 30 Nov 2000 23:55:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA22864 Fri, 1 Dec 2000 01:19:17 -0500 (EST) From: Mike Carney Message-Id: <200012010620.AAA15148@spirit.sctc.com> Subject: Re: Synchronisation in IKE To: vilhuber@cisco.com (Jan Vilhuber) Date: Fri, 1 Dec 2000 00:20:55 -0600 (CST) Cc: carney@securecomputing.com (Mike Carney), sridharj@future.futsoft.com, antonio.barrera@nokia.com, ipsec@lists.tislabs.com In-Reply-To: from "Jan Vilhuber" at Nov 30, 2000 07:17:53 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Comments inline.... > > On Tue, 28 Nov 2000, Mike Carney wrote: > > > > Hi, > > > Problem 1,2,3 : this problem can be solved if IKE keeps a HELLO or keep > > > alive > > > message periodically (not in rfc). > > > Problem 4 : In this case B should send INVALID_COOKIE(rfc 2408) notify to A > > > . > > > > > > > I wouldn't recommend that solution as B would have to send an UN-encrypted > > notify (Since it doesn't have a Phase 1). And if Side A accepts UN-encrypted > > notifies for invalid cookie as an indication that Side B has lost it's > > phase 1, Side A is open to Spoofed notify DOS attack. ( I suppose Side B could > > initiate a phase 1 in order to send a protected notify ) > > > > Our solution is to retry QM's several times (3 by default) and if that fails, > > fall back to doing a Phase 1. If the Phase 1 fails to negotiate, the VPN is > > torn down. > > > But how do you know to send a QM? We will not detect that B has lost state until we rekey the SA, thus the QM rekey. Thus this is not an ideal situation, but one which is eventually recovered. Keepalives would also do the trick if the usage was standardized. How about if B initiates a Phase 1 (if it can based on it's static configuration) in order to send an protected "unknown SPI" notify message? (Rate limited of course). Regards, Michael Carney > The problem is that host A is sending > packets to B. B is silently discarding them, because B rebooted or lost SA's > or whatever. > > B can send send an unprotected notify, but that has DoS problems, if A > actually heeds the unprotected notify. > B can initiate a QM (or phase 1), but again there are DoS problems (As > stephane pointed out). > > There's no 100% secure way that B can let A know that it doesn't have SA's > for the traffic that A is sending. > > Keepalives are fine, but are a somewhat expensive approach (although there's > some rather decent solutions; also it's arguable if keepalives aren't > something that a routing protocol is supposed to be doing). The only other > thing is to do some rate-limiting and trade-offs so that the DoS problems can > be bounded (Have B send unprotected notifies to A every 20-100 packets (I > just made up those numbers), and have A discard them, unless it got more > than, say, 5, AND it actually sent the traffic that's being complained about > recently. Then it MIGHT behoove itself to initiate a new QM or phase 1 to B, > and the DoS Problems have at least been reduced, although that's arguable). > > I don't see where A could figure this out on its own, so i don't quite > understand your 'Our solution is to retry QM's several times' above... > > Let me know if I missed something, > jan > > > > > > > Regards, > > Michael Carney. > > > > > > > > > -----Original Message----- > > > From: owner-ipsec@lists.tislabs.com > > > > > > > > > > > > I think this is a very important issue and is giving me plenty of > > > headaches. > > > Is there any documents that talks about how to resynchronise IKE > > > negotiations. > > > Any advice on the subject would be greatly appreciated. > > > Take as an Example the next case: > > > > > > 1- A (Initiator) negotiates with B (Responder) > > > 2- B reboots and is unable to send any delete notification. > > > 3- A can't talk to B anymore (A has IPSEC SAs, but no B) I have no > > > solution for this. IDEAS? > > > 4- IPSEC SAs in A expire. A Initiates a Quick mode negotiation but B > > > doesn't have ISAKMP SAs either > > > That could be solved letting A detect that B can't negotiate and > > > initiating a new Phase I negotiation. > > > Is there any problem with this solution? If yes is there an > > > alternative? > > > What do I do with the old ISAKMP SA? Keep or destroy it? I'd > > > destroy it, but not sure if can give any problem. > > > > > > I'd really appreciate any response. > > > Thanks in advance. > > > > > > Toni > > > > > > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > >