From owner-ipsec@lists.tislabs.com Sun Apr 1 19:21:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA07452; Sun, 1 Apr 2001 19:21:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA22975 Sun, 1 Apr 2001 20:52:04 -0400 (EDT) Message-ID: <3AC7F551.831B1E6B@nortelnetworks.com> Date: Sun, 01 Apr 2001 20:43:13 -0700 From: "Marcus Leech" Organization: Nortel Networks, Information Systems X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.15 i686) X-Accept-Language: en MIME-Version: 1.0 To: Paul Hoffman / VPNC CC: Theodore Tso , Stephane Beaulieu , ipsec@lists.tislabs.com Subject: Re: Last Call: DHCPv4 Configuration of IPSEC Tunnel Mode toProposed Standard References: <200103301614.LAA23048@ietf.org> <0f0201c0b948$55c54770$b81c550a@cisco.com> <20010331011123.A635@think> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC wrote: > > At 1:11 AM -0500 3/31/01, Theodore Tso wrote: > >More to the point, as far as I know, the IPSEC wg didn't request that > >this be considered as a proposed standard. Did the IPSRA WG so make > >this request? > > Yes, we did. The draft was heavily discussed on the IPSRA WG mailing > list, and we had a WG last call on it. > > For those of you (including the IPsec WG chairs...) who may not be > subscribed to the IPSRA WG mailing list, please see > for more information and a full > archive. > > --Paul Hoffman, Director > --VPN Consortium All: Paul nudged me in Minneapolis about this--the document had passed through last call in IPSRA quite some time ago. My recollection is that this document started out in IPSEC, but IPSRA adopted it a while ago, without the administrative bumph having been corrected. From owner-ipsec@lists.tislabs.com Mon Apr 2 05:13:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA09482; Mon, 2 Apr 2001 05:13:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA25244 Mon, 2 Apr 2001 07:10:58 -0400 (EDT) Message-Id: <200104021115.HAA29900@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-02.txt Date: Mon, 02 Apr 2001 07:15:14 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IKE Authentication Using ECDSA Author(s) : S. Blake-Wilson, P. Fahn Filename : draft-ietf-ipsec-ike-auth-ecdsa-02.txt Pages : 6 Date : 30-Mar-01 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 may provide benefits including 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-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-auth-ecdsa-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-auth-ecdsa-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: <20010330135637.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-auth-ecdsa-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-auth-ecdsa-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010330135637.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Apr 2 05:32:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA10761; Mon, 2 Apr 2001 05:32:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA25237 Mon, 2 Apr 2001 07:10:54 -0400 (EDT) Message-Id: <200104021115.HAA29881@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-ecc-groups-03.txt Date: Mon, 02 Apr 2001 07:15:09 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Additional ECC Groups For IKE Author(s) : S. Blake-Wilson, Y. Poeluev, M. Salter Filename : draft-ietf-ipsec-ike-ecc-groups-03.txt Pages : 15 Date : 30-Mar-01 This document describes new ECC groups for use in IKE [IKE] in addition to the Oakley groups included therein. These groups are defined to align IKE with other ECC implementations and standards, and in addition, some of them provide higher strength than the Oakley groups. It should be noted that this document is not self-contained. It uses the notations and definitions of [IKE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-ecc-groups-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ike-ecc-groups-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-ecc-groups-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010330135628.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-ecc-groups-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-ecc-groups-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010330135628.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Apr 2 08:51:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA26357; Mon, 2 Apr 2001 08:51:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26072 Mon, 2 Apr 2001 10:54:38 -0400 (EDT) MIME-Version: 1.0 Message-Id: <3AC6A1C1.27057@bjapp5> Date: Sun, 1 Apr 2001 11:34:25 +0800 (CST) From: "zhangdongyan" To: ipsec@lists.tislabs.com Subject: help X-Priority: 3 X-Originating-IP: [202.106.170.138] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear sir: We are students of Harbin Institute of Technology of China.Now we are learning IPSec Protocol. We are have questions about IKE: 1.IKE Phase 1 Authenticated With a Pre-Shared Key: What is the difference between Vendor ID data(VID) which is in Vendor ID Payload and Identification Data which is in Identification Payload? 2.IKE Phase 1 Authenticated With Digital Signature: According to the RFC “The Internet IP Security Domain of Interpretation for “ISAKMP”, When an IKE exchange is authenticated using certificates (of any format), any ID's used for input to local policy decisions SHOULD be contained in the certificate used in the authentication of the exchange, what we would like to know is Identification Data which is in Identification Payload is equal to which part of certificates? 3.IKE Phase 1 Authenticated With Public Key Encryption: Is Identification data to know by each other in advance? Is Identification data used to find the other’s public key and how to find the public key? 4.IKE Phase 2 Why initiator has two ID Payloads which are IDci and IDcr and How the initiator know the IDcr data? Is it necessary to have two ID Payloads by responder and send to the initiator? Could you tell me the answer in detail? We are sorry for taking trouble for you. We want to understand the IKE quickly so we are looking forward to hearing from you as soon as possible. Thank you for your attention. Best Regards, Zhang Dongyan Email:myredapple-@163.net Hou Rui Email:hithourui@yahoo.com.cn =============================================== 为你而建，为你而设，让你传递真心真意 ---- 163.net贺卡站（http://ecard.163.net） 163电子邮局全新奉献，精彩无限的电子贺卡站。 =============================================== From owner-ipsec@lists.tislabs.com Mon Apr 2 11:38:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA07624; Mon, 2 Apr 2001 11:38:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA26683 Mon, 2 Apr 2001 13:24:01 -0400 (EDT) Message-Id: <3.0.5.32.20010402173240.03f159e0@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 02 Apr 2001 17:32:40 +0200 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: help In-Reply-To: <3AC6A1C1.27057@bjapp5> 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 LAA26301 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:34 01.04.01 +0800, zhangdongyan wrote: >Dear sir: > We are students of Harbin Institute of Technology of China.Now we are learning IPSec Protocol. > > We are have questions about IKE: > > 1.IKE Phase 1 Authenticated With a Pre-Shared Key: > What is the difference between Vendor ID data(VID) which is in Vendor ID >Payload and Identification Data which is in Identification Payload? > The VID is rather unimportant, you may completely ignore it. It can be used to recognize different _implementations_ of IPsec. It is optional. The ID payload is very important, it holds the names of the two parties. > 2.IKE Phase 1 Authenticated With Digital Signature: > According to the RFC “The Internet IP Security Domain of Interpretation for >“ISAKMP”, When an IKE exchange is authenticated using certificates (of any format), any ID's used for input to local policy decisions SHOULD be contained in the certificate used in the authentication of the exchange, what we would like to know is Identification Data which is in Identification Payload is equal to which part of certificates? That depends on the _type_ if ID payload. If it's IP address, dns, or email, the ID payload SHOULD be equal to the altSubjectName of the certificate. That's a v3 extension of X.509. If the ID payload is a distinguished name, you should compare that to the normal subjectName of the certificate. (easy) > 3.IKE Phase 1 Authenticated With Public Key Encryption: > Is Identification data to know by each other in advance? Is Identification >data used to find the other’s public key and how to find the public key? The responder takes the ID payload and checks it's local database for the public key. The local database should be indexed by the important ID types, such as IP address, full DN etc.. Please note that the common IKE implentations require Cert Request payloads to work properly. One host says "I trust this CA" by sending a Cert Request, and the peer answers with a certificate (during Phase 1). And vice versa. This way, both computers should end up holding the peer's certificate. > 4.IKE Phase 2 > Why initiator has two ID Payloads which are IDci and IDcr and How the >initiator know the IDcr data? Is it necessary to have two ID Payloads by responder and send to the initiator? Could you tell me the answer in detail? Phase 2 is for a tunnel. And a tunnel connects two networks. So the initiator has to specify which two network he wants to connect. He might put his own IP address into IDci and "192.168.30.0/24" into IDcr, that'd be a request for a host-to-gateway connection. > We are sorry for taking trouble for you. We want to understand the IKE quickly > so we are looking forward to hearing from you as soon as possible. Thank you >for your attention. > >Best Regards, > >Zhang Dongyan >Email:myredapple-@163.net >Hou Rui >Email:hithourui@yahoo.com.cn > J鰎n From owner-ipsec@lists.tislabs.com Tue Apr 3 02:39:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA11180; Tue, 3 Apr 2001 02:39:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA29281 Tue, 3 Apr 2001 03:35:30 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: Subject: comment on draft-orman-public-key-lengths-02.txt Date: Tue, 3 Apr 2001 03:14:44 -0400 Message-Id: <006401c0bc10$94709a40$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-reply-to: <3.0.5.32.20010402173240.03f159e0@smtp.datafellows.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually 2 comments. The first comment is that the draft is very well written. Thanks for making my life easier. The second comment is something which I have mentioned before... As the draft states, the correct procedure for choosing algorithms/key lengths is as follows: 1. Determine the number of symmetric key bits matching the security requirement of the application (n). 2. Choose a symmetric cipher that has a key with at least n bits, and a cryptanalytic strength of at least that much. 3. Choose a key exchange algorithm with a resistance to attack of at least n bits. This is something which was not clear in previous versions of the draft, and vestiges of the old way of thinking remain. I think the following paragraph best illustrates the misunderstanding: If it is possible to design hardware for AES cracking that is considerably more efficient than hardware for DES cracking, then the moduli for protecting the key exchange can be made smaller. However, the existence of such designs is only a matter of speculation at this early moment in the AES lifetime. I find the idea that the KE moduli can be decreased if AES is found to be weak rather silly. After all, the requirement is not to match the symmetric key algorithm to the key exchange algorithm; the requirement is only to ensure that both algorithms have at least an equivalent strength of n. The reason I bring this up is because I think the above paragraph is prone to misinterpretation. If 3DES/Group2 provided adequate security for you yesterday then AES/Group2 should be good enough for you tommorow. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ipsec@lists.tislabs.com Tue Apr 3 10:23:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA19125; Tue, 3 Apr 2001 10:23:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00851 Tue, 3 Apr 2001 12:06:57 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200103240829.KAA29352@burp> References: <200103231810.NAA16783@bual.research.att.com> <200103232043.WAA28685@burp> <200103240829.KAA29352@burp> Date: Tue, 3 Apr 2001 12:08:36 -0400 To: Markku.Savela@iki.fi From: Stephen Kent Subject: Re: Two issues: AH death, and SA identification Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:29 AM +0200 3/24/01, Markku Savela wrote: > > >Why would you need a new protocol number if you changed this? "On the >> >wire" format for IPSEC AH and ESP packets would not change at all. >> >> The protocol is more than the format of bits on the wire; it also >> encompasses the processing at seder and receiver. So, if these >> changes affect that processing, it's not the same protocol. > >When I say "on the wire format doesn't change", I also intended to >include: a change in processing on one end doesn't affect the >processing on the other end. > >The avoid further confusions, what is the proper term to express this >condition? Just say "change is internal implementation issue"? We have varying degrees of what constitutes a purely "local matter." if the change is not externally observable, then I think everyone agrees that it is not a standards issue. if the change is externally observable, it's in a gray area. Part of what I try to do in 2401 is to provide specs that allow a customer to be able to predict if the change is externally observable and it affects how the other end of the connection or SA or whatever operates, then it clearly a standards matter. >The processing of incoming SA and destination address is exactly such >"internal implementation decision". => My conclusion: no new protocol >number for ESP/AH is required. this falls into the gray area as different local processing re SA selection could have externally observable characteristics. >HOWEVER, I did say that such change probably would change the IKE >negotiations. But, that is a different protocol. True, but the IPsec architecture encompasses multiple protocols, and may become more IKE dependant in the future, to better coordinate with IKE. >The tunnel vs. transport mode is related issue. As coded, a "tunnel >mode" is just "transport mode applied to IP tunnel" (even though, the >tunnel wrap/unwrap is also done within IPSEC) . Again, using my above >definition, this is "internal implementation issue". As others have noted, this is definitely not a purely local matter. Steve Steve From owner-ipsec@lists.tislabs.com Tue Apr 3 13:07:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA01645; Tue, 3 Apr 2001 13:07:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01244 Tue, 3 Apr 2001 15:08:18 -0400 (EDT) To: Stephen Kent Cc: Markku.Savela@iki.fi, ipsec@lists.tislabs.com Subject: Re: Two issues: AH death, and SA identification References: <200103231810.NAA16783@bual.research.att.com> <200103232043.WAA28685@burp> <200103240829.KAA29352@burp> From: Derek Atkins Date: 03 Apr 2001 15:12:22 -0400 In-Reply-To: Stephen Kent's message of "Tue, 3 Apr 2001 12:08:36 -0400" Message-ID: Lines: 19 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > True, but the IPsec architecture encompasses multiple protocols, and > may become more IKE dependant in the future, to better coordinate > with IKE. > Steve Speaking as the chair of the KINK WG, I certainly hope that IPSec does not become more dependent on IKE. Having multiple keying methods is a Good Thing (TM), and the clear split between ESP/AH and the keying method was a good decision. I would hate to see that choice reversed. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Apr 3 13:58:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA05875; Tue, 3 Apr 2001 13:58:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01390 Tue, 3 Apr 2001 16:06:30 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: <200103231810.NAA16783@bual.research.att.com> <200103232043.WAA28685@burp> <200103240829.KAA29352@burp> Date: Tue, 3 Apr 2001 16:05:42 -0400 To: Derek Atkins From: Stephen Kent Subject: Re: Two issues: AH death, and SA identification Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:12 PM -0400 4/3/01, Derek Atkins wrote: >Stephen Kent writes: > >> True, but the IPsec architecture encompasses multiple protocols, and >> may become more IKE dependant in the future, to better coordinate >> with IKE. > >> Steve > >Speaking as the chair of the KINK WG, I certainly hope that IPSec does >not become more dependent on IKE. Having multiple keying methods is a >Good Thing (TM), and the clear split between ESP/AH and the keying >method was a good decision. I would hate to see that choice reversed. Negotiation of SA parameters is an SA management function, though not necessarily a key management function. We have disconnects today between IKE capabilities and IPsec architecture. I want to close those gaps in the next rev, and not by reducing IPsec functionality. Perhaps what I should say is that I want to specify more concretely what an SA management protocol must provide for IPsec, whether that protocol is IKE or not. Steve From owner-ipsec@lists.tislabs.com Tue Apr 3 16:38:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA13660; Tue, 3 Apr 2001 16:38:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01635 Tue, 3 Apr 2001 18:34:43 -0400 (EDT) To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: Re: Two issues: AH death, and SA identification References: <200103231810.NAA16783@bual.research.att.com> <200103232043.WAA28685@burp> <200103240829.KAA29352@burp> From: Derek Atkins Date: 03 Apr 2001 18:38:56 -0400 In-Reply-To: Stephen Kent's message of "Tue, 3 Apr 2001 16:05:42 -0400" Message-ID: Lines: 24 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Perhaps we need yet another "line" separating SA management and key management? (As it is, KINK will probably incorporate much of IKE phase-II quick-mode for the SA negotiation). -derek Stephen Kent writes: > Negotiation of SA parameters is an SA management function, though not > necessarily a key management function. We have disconnects today > between IKE capabilities and IPsec architecture. I want to close > those gaps in the next rev, and not by reducing IPsec functionality. > > Perhaps what I should say is that I want to specify more concretely > what an SA management protocol must provide for IPsec, whether that > protocol is IKE or not. > > Steve -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Apr 3 17:02:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA15714; Tue, 3 Apr 2001 17:02:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01757 Tue, 3 Apr 2001 19:15:15 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <001f01c05ee1$09bae630$1e72788a@andrewk3.ca.alcatel.com> References: <001f01c05ee1$09bae630$1e72788a@andrewk3.ca.alcatel.com> Date: Tue, 3 Apr 2001 19:20:35 -0400 To: From: Stephen Kent Subject: RE: On transport-level policy enforcement (was Re: RFC 2401...) Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew, > > 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. > >Steve, > >If you'd like to discuss how this will be done, either on the list or at the >meeting, I think several of us would be interested. My instinct tells me >that this is going to require some extra rules that limit the ways in which >policy can be expressed, and I'm wondering what they are. Whoops! I lost this one in my inbox for quite a while! Sorry about that. During some work for DARPA on security policy management in complex security domain topologies, some BBN researchers came across the idea of decorrelating the entries in the SPD, i.e., processing them so that no two entries overlap. This increases the size of the SPD, but the resulting database no longer needs to be ordered. since any packet will match at most one entry. So, I propose adopting a model that shows the SPD as a decorrelated database, and adding an SPD cache to the model. When an SA is established, one looks into the SPD and finds a match, then moves the entry to the SPD cache, where all future searches for outbound packets take place. Only if you have a miss on this cache for an outbound packet do you go back to search the SPD, e.g., as would occur if an SG encountered a new traffic stream. I think will make the explanation much clearer, and if one chooses to mimic it in an implementation (which is not required, of course) the lookup time for outbound traffic generally would be faster too. As for your concern re policy, I don't see a problem, since the decorrleation process transforms the original, ordered SPD into an unordered, but equivalent database. Steve From owner-ipsec@lists.tislabs.com Wed Apr 4 06:14:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA24638; Wed, 4 Apr 2001 06:14:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA03498 Wed, 4 Apr 2001 08:04:54 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15051.3785.744052.329698@thomasm-u1.cisco.com> Date: Wed, 4 Apr 2001 05:08:41 -0700 (PDT) To: ipsec@lists.tislabs.com Subject: IPsec and RTP crypto 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 Jeff Schiller according to Basavaraj Patil's minutes (mobile IP WG chair) quotes Jeff as saying that IPsec is not really a good fit in situations where you want to protect some of the traffic, but not all of the traffic to another host. I'd like to actually get some clarification on this because it seems like a pretty serious restriction for VoIP. Consider a simple SIP VoIP client. It exchanges UDP SIP traffic on a well known port and RTP/RTCP traffic on a dynamic set of ports. You would like both to be secure, but you'd really, really like the RTP traffic to do payload crypto so that it's friendly to header compression schemes. You can't use TLS because you'd like to use UDP. So what's left of the usual suspects? IPsec for the SIP. A similar set of considerations (but not indentical) is true for MEGACO, and may be true for RTSP as well. But... now I'm hearing that this is pressing my luck and that it's a questionable use of IPsec to desire such a pedestrian combination? Please tell me that this is not true, because if IPsec doesn't have the ability to be more discriminating in transport mode, it has really missed one of the key abilities needed to build end to end crypto systems *and* save a million and seven non-security working groups from having to constantly roll their own crypto schemes which they inevitably screw up. Mike From owner-ipsec@lists.tislabs.com Wed Apr 4 07:26:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA00909; Wed, 4 Apr 2001 07:26:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03888 Wed, 4 Apr 2001 09:28:12 -0400 (EDT) Message-Id: <200104040742.f347gTG06063@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Death to AH (was Re: SA identification) In-reply-to: Your message of "Mon, 26 Mar 2001 09:47:36 PST." <10C8636AE359D4119118009027AE9987064C4439@FMSMSX34> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 04 Apr 2001 03:42:27 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I got one response to my question: "where is it written that you must implement AH for IPv4" (IPv6 specs say that you must do so to be v6 compliant, but that isn't in the IPsec specs) The answer I got from Jesse Walker of Intel was: >RFC 2407, clauses 4.4.3.1 and 4.4.3.2, state explicitly that all >implementations claiming conforming to the IP DOI must implement AH_MD5 and >AH_SHA. It seems kind of funny to me that we should state that AH is mandatory in this part of the spec. In particular, it is in a/the *keying* draft. If removing this one "MUST" makes VPN people stop complaining, then this is pretty simple. I'm still haven't received a really convincing reason why VPN vendors didn't cheat here. ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Wed Apr 4 08:14:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA03633; Wed, 4 Apr 2001 08:14:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04520 Wed, 4 Apr 2001 10:25:36 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200104040742.f347gTG06063@marajade.sandelman.ottawa.on.ca> References: <200104040742.f347gTG06063@marajade.sandelman.ottawa.on.ca> Date: Wed, 4 Apr 2001 10:24:14 -0400 To: Michael Richardson From: Stephen Kent Subject: Re: Death to AH (was Re: SA identification) Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael, RFC 2401 states that compliant implementations MUST support AH in several places. This language is present because the WG strongly endorsed it. Fejj Schiller took a straw poll after Peter Ford (MS) put forth a proposal that AH become optional at an IETF meeting. So, any vendor that wants to claim compliance with 2401 must support AH. As you suggest, that can be changed if the WG sentiment has changed, but I am surprised by the form of your question. It seemed to suggest that a desire to claim compliance with the IETF standard for the IPsec architecture was not sufficient motivation, whereas compliance with industry test programs that are not aligned with IETF standards was a good motivation. if you really feel this way, perhaps you should focus more on contributing to ICSA and related efforts, vs. the IPsec WG :-). Steve From owner-ipsec@lists.tislabs.com Wed Apr 4 08:58:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA10038; Wed, 4 Apr 2001 08:58:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04646 Wed, 4 Apr 2001 11:05:17 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <15051.3785.744052.329698@thomasm-u1.cisco.com> References: <15051.3785.744052.329698@thomasm-u1.cisco.com> Date: Wed, 4 Apr 2001 11:03:39 -0400 To: Michael Thomas From: Stephen Kent Subject: Re: IPsec and RTP crypto Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mike, >Jeff Schiller according to Basavaraj Patil's >minutes (mobile IP WG chair) quotes Jeff as saying >that IPsec is not really a good fit in situations >where you want to protect some of the traffic, but >not all of the traffic to another host. I'd like >to actually get some clarification on this because >it seems like a pretty serious restriction for >VoIP. I am surprised to hear Jeff reported as saying what you cite above. IPsec has facilities to allow selective protection of traffic between two hosts or two sites, based on appropriate population of the SPDs at each end. So long as one can specify the traffic to be protected and not protected using the selectors employed in SPD entries, this should work fine. >Consider a simple SIP VoIP client. It exchanges >UDP SIP traffic on a well known port and RTP/RTCP >traffic on a dynamic set of ports. You would like >both to be secure, but you'd really, really like >the RTP traffic to do payload crypto so that it's >friendly to header compression schemes. You can't >use TLS because you'd like to use UDP. So what's >left of the usual suspects? IPsec for the SIP. A >similar set of considerations (but not indentical) >is true for MEGACO, and may be true for RTSP as >well. Traffic sent over dynamically selected ports are not readily accommodated by the SPD selectors as currently defined. We had a facility that would accommodate a range of ports, much as we accommodate a range of addresses, but we had to drop it because IKE could not negotiate the facility. However, discussions about son-of-IKE capabilities have included adding back this facility. So, if you can define a range of ports within which the RTP/RTCP connections will be negotiated, then IPsec with son-of-IKE could handle them. >But... now I'm hearing that this is pressing my >luck and that it's a questionable use of IPsec to >desire such a pedestrian combination? > >Please tell me that this is not true, because if >IPsec doesn't have the ability to be more >discriminating in transport mode, it has really >missed one of the key abilities needed to build >end to end crypto systems *and* save a million and >seven non-security working groups from having to >constantly roll their own crypto schemes which >they inevitably screw up. The discussion above applies to both transport and tunnel mode. Steve From owner-ipsec@lists.tislabs.com Wed Apr 4 09:33:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA12376; Wed, 4 Apr 2001 09:33:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04799 Wed, 4 Apr 2001 11:41:22 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15051.16770.221208.795052@thomasm-u1.cisco.com> Date: Wed, 4 Apr 2001 08:45:06 -0700 (PDT) To: Stephen Kent Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: IPsec and RTP crypto In-Reply-To: References: <15051.3785.744052.329698@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > I am surprised to hear Jeff reported as saying what you cite above. > IPsec has facilities to allow selective protection of traffic between > two hosts or two sites, based on appropriate population of the SPDs > at each end. So long as one can specify the traffic to be protected > and not protected using the selectors employed in SPD entries, this > should work fine. Just as a note, this was the minutes. I don't recall Jeff putting it in those exact terms, but my memory isn't perfect either. > >Consider a simple SIP VoIP client. It exchanges > >UDP SIP traffic on a well known port and RTP/RTCP > >traffic on a dynamic set of ports. You would like > >both to be secure, but you'd really, really like > >the RTP traffic to do payload crypto so that it's > >friendly to header compression schemes. You can't > >use TLS because you'd like to use UDP. So what's > >left of the usual suspects? IPsec for the SIP. A > >similar set of considerations (but not indentical) > >is true for MEGACO, and may be true for RTSP as > >well. > > Traffic sent over dynamically selected ports are not readily > accommodated by the SPD selectors as currently defined. If, say, I had an SPD entry which was specific to port 5060 with a wildcarded source address, this should work in theory, right? The RTP and other stuff that you don't care about would just pass through to the IP stack, right? I seem to recall Bill Sommerfeld making similar remarks as Jeff about Sun's stack and I think I remember that Freeswan doesn't have the ability to filter off of ports yet... So part of my question is really whether reality is anywhere close to theory too. > We had a > facility that would accommodate a range of ports, much as we > accommodate a range of addresses, but we had to drop it because IKE > could not negotiate the facility. However, discussions about > son-of-IKE capabilities have included adding back this facility. So, > if you can define a range of ports within which the RTP/RTCP > connections will be negotiated, then IPsec with son-of-IKE could > handle them. Yes, port ranges would be a very nice feature, though a sufficiently giant SPD could express the same thing though, right? Mike From owner-ipsec@lists.tislabs.com Wed Apr 4 09:40:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA12679; Wed, 4 Apr 2001 09:40:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04837 Wed, 4 Apr 2001 11:51:51 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15051.17372.411108.967545@thomasm-u1.cisco.com> Date: Wed, 4 Apr 2001 08:55:08 -0700 (PDT) To: Derek Atkins Cc: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: Two issues: AH death, and SA identification In-Reply-To: References: <200103231810.NAA16783@bual.research.att.com> <200103232043.WAA28685@burp> <200103240829.KAA29352@burp> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'd like to second this. I really see not much point in having two SA negotiation capabilities (KINK/IKE) so long as the line is cleanly drawn such that son-of-IKE doesn't keep breaking KINK and visa versa. As it stands right now, we are going to copy-by-value all of the SA negotition from IKE into KINK and delete stuff that's not appropriate for KINK. A propos the previous mail about port range selectors, it would be nice to be able to have KINK inherit that ability as well. Maybe what we could do is do a split in Son-of-ike for just the SA management and have both KINK and IKE reference that, or be able to reference that RFC in the future. For the time being, KINK should still do the copy by value, but structure it so that we can drop in another SA-negotiation subsystem in the future. The same could be done for IKE, I suppose. Mike, who knows this goes against the general desire for consolidation... Derek Atkins writes: > Perhaps we need yet another "line" separating SA management and key > management? (As it is, KINK will probably incorporate much of IKE > phase-II quick-mode for the SA negotiation). > > -derek > > Stephen Kent writes: > > > Negotiation of SA parameters is an SA management function, though not > > necessarily a key management function. We have disconnects today > > between IKE capabilities and IPsec architecture. I want to close > > those gaps in the next rev, and not by reducing IPsec functionality. > > > > Perhaps what I should say is that I want to specify more concretely > > what an SA management protocol must provide for IPsec, whether that > > protocol is IKE or not. > > > > Steve > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Apr 4 10:30:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA14759; Wed, 4 Apr 2001 10:30:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05035 Wed, 4 Apr 2001 12:43:33 -0400 (EDT) Message-Id: <200104041647.f34GlZ912178@thunk.east.sun.com> From: Bill Sommerfeld To: Michael Thomas cc: ipsec@lists.tislabs.com Subject: Re: IPsec and RTP crypto In-reply-to: Your message of "Wed, 04 Apr 2001 05:08:41 PDT." <15051.3785.744052.329698@thomasm-u1.cisco.com> Reply-to: sommerfeld@East.Sun.COM Date: Wed, 04 Apr 2001 12:47:34 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Jeff Schiller according to Basavaraj Patil's > minutes (mobile IP WG chair) quotes Jeff as saying > that IPsec is not really a good fit in situations > where you want to protect some of the traffic, but > not all of the traffic to another host. IPsec is a poor fit when you only want to protect some traffic of a particular flow (e.g., only packets which contain passwords, or only the packets with a mobile ip binding update). > Consider a simple SIP VoIP client. It exchanges > UDP SIP traffic on a well known port and RTP/RTCP > traffic on a dynamic set of ports. You would like > both to be secure, but you'd really, really like > the RTP traffic to do payload crypto so that it's > friendly to header compression schemes. You can't > use TLS because you'd like to use UDP. So what's > left of the usual suspects? IPsec for the SIP. All of the IPsec implementations I'm familiar with can handle that. If both source and destination ports are dynamic, the best way to approach this is to have the RTP/RTCP implementations on each end specify per-socket policy on their endpoints. - Bill From owner-ipsec@lists.tislabs.com Wed Apr 4 10:34:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA14983; Wed, 4 Apr 2001 10:34:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04983 Wed, 4 Apr 2001 12:25:36 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <15051.16770.221208.795052@thomasm-u1.cisco.com> References: <15051.3785.744052.329698@thomasm-u1.cisco.com> <15051.16770.221208.795052@thomasm-u1.cisco.com> Date: Wed, 4 Apr 2001 12:29:55 -0400 To: Michael Thomas From: Stephen Kent Subject: Re: IPsec and RTP crypto Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:45 AM -0700 4/4/01, Michael Thomas wrote: >Stephen Kent writes: > > I am surprised to hear Jeff reported as saying what you cite above. > > IPsec has facilities to allow selective protection of traffic between > > two hosts or two sites, based on appropriate population of the SPDs > > at each end. So long as one can specify the traffic to be protected > > and not protected using the selectors employed in SPD entries, this > > should work fine. > > Just as a note, this was the minutes. I don't > recall Jeff putting it in those exact terms, > but my memory isn't perfect either. > > > >Consider a simple SIP VoIP client. It exchanges > > >UDP SIP traffic on a well known port and RTP/RTCP > > >traffic on a dynamic set of ports. You would like > > >both to be secure, but you'd really, really like > > >the RTP traffic to do payload crypto so that it's > > >friendly to header compression schemes. You can't > > >use TLS because you'd like to use UDP. So what's > > >left of the usual suspects? IPsec for the SIP. A > > >similar set of considerations (but not indentical) > > >is true for MEGACO, and may be true for RTSP as > > >well. > > > > Traffic sent over dynamically selected ports are not readily > > accommodated by the SPD selectors as currently defined. > > If, say, I had an SPD entry which was specific to > port 5060 with a wildcarded source address, this > should work in theory, right? The RTP and other > stuff that you don't care about would just pass > through to the IP stack, right? You have not said anything about the other selectors, so this is not a completely well-formed question. is the protocol selector is set to UDP? if so, a compliant implementation would use such an SPD entry to match all traffic to that port from any port on any source host to any destination host (assuming the dest address is also wild carded. > > I seem to recall Bill Sommerfeld making similar > remarks as Jeff about Sun's stack and I think > I remember that Freeswan doesn't have the ability > to filter off of ports yet... So part of my > question is really whether reality is anywhere > close to theory too. I can't say what non-complaint implementations do. I have seen implementations that do support port-level selectors, e.g., Checkpoint and Microsoft come to mind. > >> We had a > > facility that would accommodate a range of ports, much as we > > accommodate a range of addresses, but we had to drop it because IKE > > could not negotiate the facility. However, discussions about > > son-of-IKE capabilities have included adding back this facility. So, > > if you can define a range of ports within which the RTP/RTCP > > connections will be negotiated, then IPsec with son-of-IKE could > > handle them. > > Yes, port ranges would be a very nice feature, > though a sufficiently giant SPD could express > the same thing though, right? right. One could create individual SPD entries covering all the relevant ports, but with wild card entries for other selectors, as appropriate. Steve From owner-ipsec@lists.tislabs.com Wed Apr 4 10:46:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA16491; Wed, 4 Apr 2001 10:46:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05051 Wed, 4 Apr 2001 12:54:37 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15051.21169.345775.650356@thomasm-u1.cisco.com> Date: Wed, 4 Apr 2001 09:58:25 -0700 (PDT) To: sommerfeld@East.Sun.COM Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: IPsec and RTP crypto In-Reply-To: <200104041647.f34GlZ912178@thunk.east.sun.com> References: <15051.3785.744052.329698@thomasm-u1.cisco.com> <200104041647.f34GlZ912178@thunk.east.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill Sommerfeld writes: > > Jeff Schiller according to Basavaraj Patil's > > minutes (mobile IP WG chair) quotes Jeff as saying > > that IPsec is not really a good fit in situations > > where you want to protect some of the traffic, but > > not all of the traffic to another host. > > IPsec is a poor fit when you only want to protect some traffic of a > particular flow (e.g., only packets which contain passwords, or only > the packets with a mobile ip binding update). Thank you (and Mohan). I thought I remembered a subtlety to this that wasn't captured correctly in the MIP minutes. > > Consider a simple SIP VoIP client. It exchanges > > UDP SIP traffic on a well known port and RTP/RTCP > > traffic on a dynamic set of ports. You would like > > both to be secure, but you'd really, really like > > the RTP traffic to do payload crypto so that it's > > friendly to header compression schemes. You can't > > use TLS because you'd like to use UDP. So what's > > left of the usual suspects? IPsec for the SIP. > > All of the IPsec implementations I'm familiar with can handle that. Great. This was, as they say, a sanity check. > If both source and destination ports are dynamic, the best way to > approach this is to have the RTP/RTCP implementations on each end > specify per-socket policy on their endpoints. That is the case with RTP. Each side decides which ports it wants to receive on and is typically transmitted in SDP (or h.245, I 'spose). Mike From owner-ipsec@lists.tislabs.com Wed Apr 4 11:29:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA18743; Wed, 4 Apr 2001 11:29:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05186 Wed, 4 Apr 2001 13:35:44 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200104041647.f34GlZ912178@thunk.east.sun.com> References: <200104041647.f34GlZ912178@thunk.east.sun.com> Date: Wed, 4 Apr 2001 13:33:05 -0400 To: sommerfeld@East.Sun.COM From: Stephen Kent Subject: Re: IPsec and RTP crypto Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:47 PM -0400 4/4/01, Bill Sommerfeld wrote: > > Jeff Schiller according to Basavaraj Patil's >> minutes (mobile IP WG chair) quotes Jeff as saying >> that IPsec is not really a good fit in situations >> where you want to protect some of the traffic, but >> not all of the traffic to another host. > >IPsec is a poor fit when you only want to protect some traffic of a >particular flow (e.g., only packets which contain passwords, or only >the packets with a mobile ip binding update). Ah, that makes sense as something Jeff might have said! Steve From owner-ipsec@lists.tislabs.com Wed Apr 4 12:19:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA21846; Wed, 4 Apr 2001 12:19:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05423 Wed, 4 Apr 2001 14:27:12 -0400 (EDT) Message-ID: <3ACB6853.A2694E85@storm.ca> Date: Wed, 04 Apr 2001 14:30:43 -0400 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: IPsec and RTP crypto References: <200104041647.f34GlZ912178@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill Sommerfeld wrote: > > > Jeff Schiller according to Basavaraj Patil's > > minutes (mobile IP WG chair) quotes Jeff as saying > > that IPsec is not really a good fit in situations > > where you want to protect some of the traffic, but > > not all of the traffic to another host. > > IPsec is a poor fit when you only want to protect some traffic of a > particular flow (e.g., only packets which contain passwords, or only > the packets with a mobile ip binding update). There's a reasonable argument, though, that the best way to protect a small part of your traffic is to encrypt as much of the total traffic as possible, not just the part you want to protect. If you only encrypt "some traffic of a particular flow" you may give an eavesdropper information useful in traffic analysis. Certainly you help him target a cryptographic attack. He knows what packets are of interest; the ones you've encrypted. There are additional problems if you encrypt only control packets such as mobile binding updates. For one thing, any enemy who reads the RFCs may know quite a bit about their structure, which makes many cryptgraphic attacks easier. Also, even without breaking the crypto, he may get enough information from the pattern of these packets to make some denial of service attacks easier. In general, I think this argument holds. I see IPSEC's ability to select packets for encryption by complex rules as an unnecessary complication in most situations. The sensible thing is to encrypt everything passing between two gateways. Mobile devices may be an exception, since they have rather limited resources in many cases. > > Consider a simple SIP VoIP client. It exchanges > > UDP SIP traffic on a well known port and RTP/RTCP > > traffic on a dynamic set of ports. You would like > > both to be secure, but you'd really, really like > > the RTP traffic to do payload crypto so that it's > > friendly to header compression schemes. You can't > > use TLS because you'd like to use UDP. So what's > > left of the usual suspects? IPsec for the SIP. > > All of the IPsec implementations I'm familiar with can handle that. > > If both source and destination ports are dynamic, the best way to > approach this is to have the RTP/RTCP implementations on each end > specify per-socket policy on their endpoints. Or, if you have the resources, just encrypt everything. From owner-ipsec@lists.tislabs.com Wed Apr 4 12:26:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA22724; Wed, 4 Apr 2001 12:26:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05453 Wed, 4 Apr 2001 14:31:34 -0400 (EDT) From: Mohan Parthasarathy Message-Id: <200104041553.f34FrPZ05925@locked.eng.sun.com> Subject: Re: IPsec and RTP crypto In-Reply-To: <15051.3785.744052.329698@thomasm-u1.cisco.com> from Michael Thomas at "Apr 4, 2001 05:08:41 am" To: Michael Thomas Date: Wed, 4 Apr 2001 08:53:25 -0700 (PDT) CC: ipsec@lists.tislabs.com 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 > > Jeff Schiller according to Basavaraj Patil's > minutes (mobile IP WG chair) quotes Jeff as saying > that IPsec is not really a good fit in situations > where you want to protect some of the traffic, but > not all of the traffic to another host. I'd like > to actually get some clarification on this because > it seems like a pretty serious restriction for > VoIP. > I think there seems to be some confusion. This was discussed in the context of piggybacking binding updates (IPv6 destination option) instead of sending binding updates all by itself. If it is the latter, there is no issue as you can have a policy that says "Protect binding updates" (it is a different issue that there is no selector for a specific destination option). Piggybacking is an issue because binding update protected using AH may not be accepted on a TCP connection that accepts clear packets. Assume you have a policy that says "Protect with AH all packets from host A to host B destined to port 23". This means you can't send clear packets once in a while for packets destined to port 23. Similarly the converse is true. If there is no policy at all, then you can't send a AH protected packet (binding update) once in a while. It will be dropped. -mohan > Consider a simple SIP VoIP client. It exchanges > UDP SIP traffic on a well known port and RTP/RTCP > traffic on a dynamic set of ports. You would like > both to be secure, but you'd really, really like > the RTP traffic to do payload crypto so that it's > friendly to header compression schemes. You can't > use TLS because you'd like to use UDP. So what's > left of the usual suspects? IPsec for the SIP. A > similar set of considerations (but not indentical) > is true for MEGACO, and may be true for RTSP as > well. > > But... now I'm hearing that this is pressing my > luck and that it's a questionable use of IPsec to > desire such a pedestrian combination? > > Please tell me that this is not true, because if > IPsec doesn't have the ability to be more > discriminating in transport mode, it has really > missed one of the key abilities needed to build > end to end crypto systems *and* save a million and > seven non-security working groups from having to > constantly roll their own crypto schemes which > they inevitably screw up. > > Mike From owner-ipsec@lists.tislabs.com Wed Apr 4 12:36:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA24291; Wed, 4 Apr 2001 12:36:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05547 Wed, 4 Apr 2001 14:46:34 -0400 (EDT) Message-Id: <200104041551.f34FpZw04440@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Death to AH (was Re: SA identification) In-reply-to: Your message of "Wed, 04 Apr 2001 10:24:14 EDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 04 Apr 2001 11:51:34 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Stephen" == Stephen Kent writes: Stephen> RFC 2401 states that compliant implementations MUST support AH in Stephen> several places. This language is present because the WG strongly Stephen> endorsed it. Fejj Schiller took a straw poll after Peter Ford (MS) Yes, I understood the argument at the time, and I agreed with it. What I am trying to get at, is... when the VPN vendors say that they are "compliant", what does that specifically mean. I.e. when marketing says "do IPsec", on what basis does engineering translate this to. Does this mean "RFC2401" (which wouldn't necessarily mean that you have had IKE, btw), etc. So, it then falls to the compliance testers to say, "IPsec = 2401...2409, plus some PKI subset" since there aren't any PKI requirements stated in that list, they have to add those from the appropriate PKIX work, etc. So, when VPN vendors say that they don't like AH for some set of reasons and like to remove it, I ask the question: "who said you had to implement it?" (Recall the joke with the patient who says "Doctor, it hurts when I do this!", Doctor says "Don't do that!") IPsec is a tool to implement many things, including VPNs, but VPN is clearly the primary user at present. I would hate to have AH junked for all end hosts because it didn't agree with the VPN subset. As a precedent, we have different router and end-system requirements at present. I think that 2401 speaks to end systems requirements, not gateway requirements. It seems that the appropriate thing to do is to write a BCP on the "VPN" problem, and then the VPN vendor's can claim compliance to *that* rather than to 2401. The full blown host systems (Sun, KAME, Win2k,...) are the ones that we want to be 2401 compliant. I haven't seen any of them argue strongly for removing AH (or transport mode). The water will get even more muddy as IPSP and IPSRA work goes to PS. What will "IPsec compliant" mean then? Stephen> but I am surprised by the form of your question. It seemed to suggest Stephen> that a desire to claim compliance with the IETF standard for the Stephen> IPsec architecture was not sufficient motivation, whereas compliance Stephen> with industry test programs that are not aligned with IETF standards Stephen> was a good motivation. if you really feel this way, perhaps you Stephen> should focus more on contributing to ICSA and related efforts, vs. Stephen> the IPsec WG :-). This issue is that the industry test programs are not handing out "IPsec" conformance certificates, because 1) it is a hard thing (i.e. $$$) to fully test 2) the end-customers don't really want all of of what "IPsec" could be. They mostly want VPNs. ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Wed Apr 4 12:38:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA24543; Wed, 4 Apr 2001 12:38:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05546 Wed, 4 Apr 2001 14:46:34 -0400 (EDT) Message-Id: <200104041605.f34G5ZZ04984@marajade.sandelman.ottawa.on.ca> To: "Angelos D. Keromytis" cc: ipsec@lists.tislabs.com Subject: Re: SCTP and IPsec issues In-reply-to: Your message of "Thu, 29 Mar 2001 21:25:31 EST." <200103300225.f2U2PVm19707@nyarlathotep.keromytis.org> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 04 Apr 2001 12:05:35 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Angelos" == Angelos D Keromytis writes: Angelos> but that can be done by a series of Phase 2 exchanges just as Angelos> easily. In any situation that involves automatic keying (e.g., Angelos> "telnet -secure foo.com"), I don't see how this would buy you Angelos> anything, other than increased complexity. >> >> "ftp -secure foo.com" Angelos> That won't do you any good, since in neither passive or active Angelos> FTP do you know Angelos> the server side's port until after you've started an exchange. That's my point. It doesn't work. You can't ask to have the data connected added to the control connections' SA. You have to do a new phase 2 for each file transfered. ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Wed Apr 4 12:38:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA24557; Wed, 4 Apr 2001 12:38:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05558 Wed, 4 Apr 2001 14:48:29 -0400 (EDT) Message-ID: <3ACB68B3.924A7F3E@NORTELNETWORKS.COM> Date: Wed, 04 Apr 2001 14:32:19 -0400 From: "Marcus Leech" X-Mailer: Mozilla 4.73C-CCK-MCD [en] (X11; U; HP-UX B.10.20 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: IPsec and RTP crypto References: <15051.3785.744052.329698@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > > I am surprised to hear Jeff reported as saying what you cite above. > IPsec has facilities to allow selective protection of traffic between > two hosts or two sites, based on appropriate population of the SPDs > at each end. So long as one can specify the traffic to be protected > and not protected using the selectors employed in SPD entries, this > should work fine. What Jeff said was that IPSEC was a poor fit when you want to protect bits and pieces of a single flow/protocol--which is exactly what MIPV6 wanted. They didn't realize that you couldn't say "protect only protocol element FOO in protocol BAR" in the SPD. -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 8M70, MS 012, FITZ Advisor Phone: (ESN) 393-9145 +1 613 763 9145 Security Architecture and Planning Fax: (ESN) 393-9435 +1 613 763 9435 Nortel Networks mleech@nortelnetworks.com -----------------Expressed opinions are my own, not my employer's------ From owner-ipsec@lists.tislabs.com Wed Apr 4 13:58:31 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA00489; Wed, 4 Apr 2001 13:58:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05809 Wed, 4 Apr 2001 16:02:12 -0400 (EDT) Message-Id: <200104041959.f34Jxmx27255@potassium.cips.nokia.com> To: Michael Richardson cc: ipsec@lists.tislabs.com Subject: Re: Death to AH (was Re: SA identification) In-Reply-To: Your message of "Wed, 04 Apr 2001 11:51:34 EDT." <200104041551.f34FpZw04440@marajade.sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27252.986414388.1@potassium.cips.nokia.com> Date: Wed, 04 Apr 2001 12:59:48 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk RFC2401 includes a requirement to support manually keyed SAs yet there are lots of VPN vendors that either don't support it or disabled it in their products because customers got confused or demanded it be disabled or some combination of the two. All of these vendors claim they are "IPsec compliant". (I'm reminded of Claude Reins in Casablanca being shocked that gambling was taking place at Rick's-- vendors claiming compliance when they are not 100% compliant!) My experience with IPsec compliance organizations is that they do not test full compliance with the RFCs. They test a small subset and then incrementally add things to justify the pound (ton actually) of flesh they take each year for vendors to remain "compliant". I think the decision to remove the MUST language for AH from the RFCs should not be influenced either by vendors desire to claim compliance-- they will anyway-- or the business models of the various compliance organizations-- they will not test full compliance anyway or they'd go out of business. And Steve's memory is the same as mine. It was an end-system vendor, Peter Ford "from the Microsoft Corporation", who argued quite strongly for the removal of AH. Dan. VPN vendors claim compliance to RFC2401 yet On Wed, 04 Apr 2001 11:51:34 EDT you wrote > > >>>>> "Stephen" == Stephen Kent writes: > Stephen> RFC 2401 states that compliant implementations MUST support AH i >n > Stephen> several places. This language is present because the WG strongly > > Stephen> endorsed it. Fejj Schiller took a straw poll after Peter Ford (M >S) > > Yes, I understood the argument at the time, and I agreed with it. > > What I am trying to get at, is... when the VPN vendors say that they are > "compliant", what does that specifically mean. I.e. when marketing says "do > IPsec", on what basis does engineering translate this to. Does this mean > "RFC2401" (which wouldn't necessarily mean that you have had IKE, btw), etc. > > So, it then falls to the compliance testers to say, > "IPsec = 2401...2409, plus some PKI subset" > > since there aren't any PKI requirements stated in that list, they have to > add those from the appropriate PKIX work, etc. > > So, when VPN vendors say that they don't like AH for some set of reasons > and like to remove it, I ask the question: "who said you had to implement > it?" > > (Recall the joke with the patient who says "Doctor, it hurts when I do this >!", > Doctor says "Don't do that!") > > IPsec is a tool to implement many things, including VPNs, but VPN is > clearly the primary user at present. I would hate to have AH junked for all > end hosts because it didn't agree with the VPN subset. > As a precedent, we have different router and end-system requirements at > present. I think that 2401 speaks to end systems requirements, not gateway > requirements. > > It seems that the appropriate thing to do is to write a BCP on the "VPN" > problem, and then the VPN vendor's can claim compliance to *that* rather than > > to 2401. > > The full blown host systems (Sun, KAME, Win2k,...) are the ones that we > want to be 2401 compliant. I haven't seen any of them argue strongly for > removing AH (or transport mode). > > The water will get even more muddy as IPSP and IPSRA work goes to PS. What > will "IPsec compliant" mean then? > > Stephen> but I am surprised by the form of your question. It seemed to su >ggest > Stephen> that a desire to claim compliance with the IETF standard for the > > Stephen> IPsec architecture was not sufficient motivation, whereas compli >ance > Stephen> with industry test programs that are not aligned with IETF stand >ards > Stephen> was a good motivation. if you really feel this way, perhaps you > Stephen> should focus more on contributing to ICSA and related efforts, v >s. > Stephen> the IPsec WG :-). > > This issue is that the industry test programs are not handing out "IPsec" > conformance certificates, because > 1) it is a hard thing (i.e. $$$) to fully test > 2) the end-customers don't really want all of of what "IPsec" > could be. They mostly want VPNs. > > ] Train travel features AC outlets with no take-off restrictions|gigabit is n >o[ > ] Michael Richardson, Solidum Systems Oh where, oh where has|problem wit >h[ > ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 110 >0[ > ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); > [ > > > From owner-ipsec@lists.tislabs.com Wed Apr 4 15:12:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA05433; Wed, 4 Apr 2001 15:12:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06009 Wed, 4 Apr 2001 17:11:49 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Wed, 04 Apr 2001 13:46:49 -0600 From: "Hilarie Orman" To: Cc: Subject: Re: IPsec and RTP crypto Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id PAA05766 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Long ago we implemented this selective use of IPsec by permitting connections to mix protected and unprotected traffic. The send and receive interfaces made the level of protection obvious; the application layer could decide whether or not to accept data for each received chunk (all the bytes in a chunk had the same protections). This allowed password protection, in particular. It didn't seem (at the time), that IPsec was an impediment to this usage. Hilarie >>> Stephen Kent 04/04/01 11:33AM >>> At 12:47 PM -0400 4/4/01, Bill Sommerfeld wrote: > > Jeff Schiller according to Basavaraj Patil's >> minutes (mobile IP WG chair) quotes Jeff as saying >> that IPsec is not really a good fit in situations >> where you want to protect some of the traffic, but >> not all of the traffic to another host. > >IPsec is a poor fit when you only want to protect some traffic of a >particular flow (e.g., only packets which contain passwords, or only >the packets with a mobile ip binding update). Ah, that makes sense as something Jeff might have said! Steve From owner-ipsec@lists.tislabs.com Wed Apr 4 16:51:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA10908; Wed, 4 Apr 2001 16:51:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06301 Wed, 4 Apr 2001 19:06:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200104041959.f34Jxmx27255@potassium.cips.nokia.com> References: <200104041959.f34Jxmx27255@potassium.cips.nokia.com> Date: Wed, 4 Apr 2001 16:11:08 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Death to AH (was Re: SA identification) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:59 PM -0700 4/4/01, Dan Harkins wrote: > I think the decision to remove the MUST language for AH from the RFCs >should not be influenced either by vendors desire to claim compliance-- >they will anyway-- or the business models of the various compliance >organizations-- they will not test full compliance anyway or they'd go >out of business. Fully agree with both reasons. This WG is not in the business of making it easier for a vendor to say whether or not it complies with a spec; vendors will say that they are even in the face of countervailing facts. This WG is not in the business of helping organizations that test our specs. This WG is in the business of making sensible standards, if that is possible in this space. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Apr 4 16:51:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA10916; Wed, 4 Apr 2001 16:51:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06275 Wed, 4 Apr 2001 19:03:01 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200104041959.f34Jxmx27255@potassium.cips.nokia.com> References: <200104041959.f34Jxmx27255@potassium.cips.nokia.com> Date: Wed, 4 Apr 2001 16:07:15 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Death to AH (was Re: SA identification) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:59 PM -0700 4/4/01, Dan Harkins wrote: > My experience with IPsec compliance organizations is that they do not >test full compliance with the RFCs. They test a small subset and then >incrementally add things to justify the pound (ton actually) of flesh >they take each year for vendors to remain "compliant". Sorry, I can't let that one go as universally true. Some organizations work on that model, others don't. VPNC is one that doesn't (either on the "ton" part or on the "each year" part). See the first section at for more details. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Apr 4 17:00:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA11397; Wed, 4 Apr 2001 17:00:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06289 Wed, 4 Apr 2001 19:05:50 -0400 (EDT) Date: Wed, 4 Apr 2001 19:09:38 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: IPsec and RTP crypto In-Reply-To: <15051.16770.221208.795052@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 4 Apr 2001, Michael Thomas wrote: > I seem to recall Bill Sommerfeld making similar > remarks as Jeff about Sun's stack and I think > I remember that Freeswan doesn't have the ability > to filter off of ports yet... Correct on the FreeS/WAN part (can't answer for Sun!). This is being fixed, although as Sandy commented, we belong to the faction which says that you are usually better off just encrypting *everything* -- if only because it denies useful information to the bad guys -- unless there are truly compelling reasons not to. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Apr 4 17:05:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA11662; Wed, 4 Apr 2001 17:05:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06363 Wed, 4 Apr 2001 19:24:24 -0400 (EDT) to: ipsec@lists.tislabs.com In-reply-to: HORMAN's message of Wed, 04 Apr 2001 13:46:49 CST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPsec and RTP crypto From: itojun@iijlab.net Date: Thu, 05 Apr 2001 08:28:40 +0900 Message-ID: <16603.986426920@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>> Stephen Kent 04/04/01 11:33AM >>> >At 12:47 PM -0400 4/4/01, Bill Sommerfeld wrote: >> > Jeff Schiller according to Basavaraj Patil's >>> minutes (mobile IP WG chair) quotes Jeff as saying >>> that IPsec is not really a good fit in situations >>> where you want to protect some of the traffic, but >>> not all of the traffic to another host. >> >>IPsec is a poor fit when you only want to protect some traffic of a >>particular flow (e.g., only packets which contain passwords, or only >>the packets with a mobile ip binding update). i don't think it a "poor fit" by definition. it highly depends on the design of your policy engine, and API for security extension. I can think of RFC2292-like API if you want to control per-packet IPsec requirements, if such a requirement exists (yes, it is hard to control policy for a certain segment in TCP flow. but it is inherently hard for TCP API, this is independent from ipsec). for mobile-ip6 in particular, it is very easy to use particular protection mechanism for outgoing/incoming binding updates. binding updates are normally sent by kernel and received by kernel, so it is trivial for us to tweak/annotate policy lookup. even with a packet with piggybacked binding update, it is not that hard. i don't think it a "poor fit" in mobile-ip6 case. itojun From owner-ipsec@lists.tislabs.com Wed Apr 4 17:10:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA12049; Wed, 4 Apr 2001 17:10:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06381 Wed, 4 Apr 2001 19:30:30 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 4 Apr 2001 19:36:04 -0400 To: Henry Spencer From: Stephen Kent Subject: Re: IPsec and RTP crypto Cc: IP Security List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:09 PM -0400 4/4/01, Henry Spencer wrote: >On Wed, 4 Apr 2001, Michael Thomas wrote: >> I seem to recall Bill Sommerfeld making similar >> remarks as Jeff about Sun's stack and I think >> I remember that Freeswan doesn't have the ability >> to filter off of ports yet... > >Correct on the FreeS/WAN part (can't answer for Sun!). This is being >fixed, although as Sandy commented, we belong to the faction which says >that you are usually better off just encrypting *everything* -- if only >because it denies useful information to the bad guys -- unless there are >truly compelling reasons not to. > Port-level SPD selectors, like all other SPD entry selectors, are part of an access control mechanism, as described in 2401. So, even if one does elect to "encrypt everything" to a destination, there is good reason for complying with the standard in this regard. Steve From owner-ipsec@lists.tislabs.com Wed Apr 4 17:45:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA12936; Wed, 4 Apr 2001 17:45:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA06465 Wed, 4 Apr 2001 20:02:28 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: IPsec and RTP crypto Date: Wed, 4 Apr 2001 17:03:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4683.0 Message-ID: <6A05D00595BE644E9F435BE5947423F20535B318@fifi.dogfood> Thread-Topic: IPsec and RTP crypto Thread-Index: AcC9YEPjF3Ykd0V8R365+hrGP5ECVQAAtc1A From: "William Dixon" To: "Stephen Kent" , "Henry Spencer" Cc: "IP Security List" X-OriginalArrivalTime: 05 Apr 2001 00:07:23.0406 (UTC) FILETIME=[63BCA2E0:01C0BD64] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Agree with Steve. I have seen many customers wanting to control which applications (dest ports) are allowed to come in IPSec protected, because if one IPSec peer is compromised, they don't want to receive all traffic from the now malicious but authenticated peer. Now you have to decide whether you propose the 5-tuple of the IPSec policy filter or the particular packet 5-tuple in order to make the most of the access policy on the responder. In Win2k we chose to propose the filter 5-tuple so that we could get the best performance (aggregation of connections across 1 SA pair) out of an all-traffic selector. I've noticed interop issues where the responder has many overlapping (various degrees of specificity) 5-tuple selectors. And of course the configuration difficulty of choosing the right auth method in main mode when you don't have access to the full selector of quick mode. -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Wednesday, April 04, 2001 4:36 PM To: Henry Spencer Cc: IP Security List Subject: Re: IPsec and RTP crypto At 7:09 PM -0400 4/4/01, Henry Spencer wrote: >On Wed, 4 Apr 2001, Michael Thomas wrote: >> I seem to recall Bill Sommerfeld making similar >> remarks as Jeff about Sun's stack and I think >> I remember that Freeswan doesn't have the ability >> to filter off of ports yet... > >Correct on the FreeS/WAN part (can't answer for Sun!). This is being >fixed, although as Sandy commented, we belong to the faction which says >that you are usually better off just encrypting *everything* -- if only >because it denies useful information to the bad guys -- unless there >are truly compelling reasons not to. > Port-level SPD selectors, like all other SPD entry selectors, are part of an access control mechanism, as described in 2401. So, even if one does elect to "encrypt everything" to a destination, there is good reason for complying with the standard in this regard. Steve From owner-ipsec@lists.tislabs.com Thu Apr 5 02:20:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA23532; Thu, 5 Apr 2001 02:20:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA07855 Thu, 5 Apr 2001 04:18:25 -0400 (EDT) Message-Id: <200104050821.f358LwA16204@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Stephen Kent cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: IPsec and RTP crypto In-reply-to: Your message of Wed, 04 Apr 2001 11:03:39 EDT. Date: Thu, 05 Apr 2001 10:21:58 +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: >Jeff Schiller according to Basavaraj Patil's >minutes (mobile IP WG chair) quotes Jeff as saying >that IPsec is not really a good fit in situations >where you want to protect some of the traffic, but >not all of the traffic to another host. I'd like >to actually get some clarification on this because >it seems like a pretty serious restriction for >VoIP. I am surprised to hear Jeff reported as saying what you cite above. => so we should get a copy of Jeff's slides asap... IPsec has facilities to allow selective protection of traffic between two hosts or two sites, based on appropriate population of the SPDs at each end. So long as one can specify the traffic to be protected and not protected using the selectors employed in SPD entries, this should work fine. => in the context of Jeff's presentation fix protocols/profiles/ports are used so the dynamically selected port stuff doesn't apply. But the argument was not that it is impossible (ie. cannot) but that many implementations don't support this (ie. should not). I know some VPN implementations don't support selective protection but is this so common? Of course all implementations analysed for mobile IPv6 support have selective protection but they are host implementations too so perhaps not in the main stream... Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu Apr 5 08:10:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA21180; Thu, 5 Apr 2001 08:10:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08794 Thu, 5 Apr 2001 09:49:31 -0400 (EDT) Message-ID: <20010405135352.21236.qmail@web1401.mail.yahoo.com> Date: Thu, 5 Apr 2001 06:53:52 -0700 (PDT) From: Pyda Srisuresh Subject: Re: SCTP and IPsec issues To: ipsec@lists.tislabs.com In-Reply-To: <200104041605.f34G5ZZ04984@marajade.sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is yet another case (application specific dynamically generated sessions) addressed by . A new Policy Payload, replacing ID payload in Quick mode, does the trick. There is no need to negotiate a new SA, when changes to SPD can be acceptable to both IKE peers. cheers, suresh --- Michael Richardson wrote: > > >>>>> "Angelos" == Angelos D Keromytis writes: > Angelos> but that can be done by a series of Phase 2 exchanges just as > Angelos> easily. In any situation that involves automatic keying (e.g., > Angelos> "telnet -secure foo.com"), I don't see how this would buy you > Angelos> anything, other than increased complexity. > >> > >> "ftp -secure foo.com" > > Angelos> That won't do you any good, since in neither passive or active > Angelos> FTP do you know > Angelos> the server side's port until after you've started an exchange. > > That's my point. It doesn't work. > You can't ask to have the data connected added to the control connections' > SA. > You have to do a new phase 2 for each file transfered. > > ] Train travel features AC outlets with no take-off restrictions|gigabit is > no[ > ] Michael Richardson, Solidum Systems Oh where, oh where has|problem > with[ > ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port > 1100[ > ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ ===== __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ From owner-ipsec@lists.tislabs.com Thu Apr 5 10:53:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA02487; Thu, 5 Apr 2001 10:53:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10150 Thu, 5 Apr 2001 12:38:06 -0400 (EDT) Message-Id: <200104051642.f35GgF913404@thunk.east.sun.com> From: Bill Sommerfeld To: itojun@iijlab.net cc: ipsec@lists.tislabs.com Subject: Re: IPsec and RTP crypto In-reply-to: Your message of "Thu, 05 Apr 2001 08:28:40 +0900." <16603.986426920@coconut.itojun.org> Reply-to: sommerfeld@East.Sun.COM Date: Thu, 05 Apr 2001 12:42:15 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > i don't think it a "poor fit" in mobile-ip6 case. Here's a more specific concern: The use of ipsec for protecting piggybacked binding updates interferes with safe use of ipsec opportunistic encryption. A service may set up a listening tcp port with a policy which says "allow cleartext, or AH-protected, but once encryption is used, require it on all subsequent packets". Now, it receives an AH-protected TCP SYN with a binding update attached (which seems to be a highly likely combination). Is the receiver to interpret the use of ipsec for that packet as: a) an indication that all other traffic on this connection will be protected with AH? b) a signal that just the segment with the binding update is protected and to expect cleartext on other packets? The conservative thing to do is to assume (a), and prevent the connection from being assassinated by forged unauthenticated RST's. - Bill From owner-ipsec@lists.tislabs.com Thu Apr 5 11:30:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA05056; Thu, 5 Apr 2001 11:30:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10364 Thu, 5 Apr 2001 13:34:09 -0400 (EDT) Message-ID: <36C2EB69D2F9D411A9AB00D0B72003344ACD59@eniwest.inside.efficient.com> From: Richard Robinson To: "'ipsec@lists.tislabs.com'" Subject: Invalid SPI RFC2408 5.5 Date: Thu, 5 Apr 2001 10:34:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0BDF6.B608AC00" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0BDF6.B608AC00 Content-Type: text/plain; charset="iso-8859-1" hi- I hope this is the right place to get this question answered. If not, my apologies. I am trying to fix a problem when we send a notification payload with message type CONNECTED. The other end of the tunnel does not accept a zero-length SPI which we had been doing. I am now trying to find out where to get a nice 4-octet SPI that it will accept (it's logs are indicating that it does not like the SPI we are supplying). Is it the same SPI that we send out in a RESPONDER_LIFETIME notification? Just what makes an SPI valid or invalid (aside from using 0-255)? As a small aside, what situations were envisaged when the COMMIT bit was designed? Why would I, the responder, not be ready for traffic, at the end of phase 2 negotiations? thanks, richard Richard Robinson, Senior Software Engineer Efficient Networks rrobinson@efficient.com 408-357-6703 All disclaimers apply. ------_=_NextPart_000_01C0BDF6.B608AC00 Content-Type: application/octet-stream; name="Richard Robinson.vcf" Content-Disposition: attachment; filename="Richard Robinson.vcf" BEGIN:VCARD VERSION:2.1 N:Robinson;Richard FN:Richard Robinson ORG:Efficient Networks, Inc.;Software Engineering TITLE:Sr. Software Engineer TEL;WORK;VOICE:(408) 357-6600 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;ENI WEST;983 University Ave.=0D=0ABldg. A;Los Gatos;CA;95032;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:ENI WEST=0D=0A983 University Ave.=0D=0ABldg. A=0D=0ALos Gatos, CA 95032=0D= =0AUSA EMAIL;PREF;INTERNET:rrobinson@efficient.com REV:20001114T174501Z END:VCARD ------_=_NextPart_000_01C0BDF6.B608AC00-- From owner-ipsec@lists.tislabs.com Thu Apr 5 14:45:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA20425; Thu, 5 Apr 2001 14:45:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11031 Thu, 5 Apr 2001 16:32:40 -0400 (EDT) Message-Id: <200104052030.f35KUHx44255@potassium.cips.nokia.com> To: Paul Hoffman / VPNC cc: ipsec@lists.tislabs.com Subject: Re: Death to AH (was Re: SA identification) In-Reply-To: Your message of "Wed, 04 Apr 2001 16:07:15 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <44252.986502617.1@potassium.cips.nokia.com> Date: Thu, 05 Apr 2001 13:30:17 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, I'm sorry. You're absolutely right. I was talking about ICSA. VPNC does not have this business model nor do they insist on vendors to change their implementation to do things that are clearly not in the RFC and are of questionable security (i.e. ignoring the lifetime in one's configured policy). Sorry for any misunderstanding. I would say a VPNC certification means much more than an ICSA one. More testing of more features my more competent testers. Dan, who does not speak for his employer but from experience. On Wed, 04 Apr 2001 16:07:15 PDT you wrote > At 12:59 PM -0700 4/4/01, Dan Harkins wrote: > > My experience with IPsec compliance organizations is that they do not > >test full compliance with the RFCs. They test a small subset and then > >incrementally add things to justify the pound (ton actually) of flesh > >they take each year for vendors to remain "compliant". > > Sorry, I can't let that one go as universally true. Some > organizations work on that model, others don't. VPNC is one that > doesn't (either on the "ton" part or on the "each year" part). See > the first section at for more > details. > > --Paul Hoffman, Director > --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Apr 5 16:22:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA25440; Thu, 5 Apr 2001 16:22:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11353 Thu, 5 Apr 2001 18:34:37 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4683.0 content-class: urn:content-classes:message Subject: RE: Death to AH (was Re: SA identification) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 5 Apr 2001 12:18:34 -0700 Message-ID: Thread-Topic: Death to AH (was Re: SA identification) Thread-Index: AcC9RAC7oVa6cnNkSPWX9XoFJ6HJ1AAYDcqwABdkWQA= From: "Peter Ford" To: X-OriginalArrivalTime: 05 Apr 2001 19:18:34.0671 (UTC) FILETIME=[356B43F0:01C0BE05] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id PAA10790 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > And Steve's memory is the same as mine. It was an end-system vendor, Peter >Ford "from the Microsoft Corporation", who argued quite strongly for the >removal of AH. In deference to IETF tradition I should complain and state that I am not from an end-system vendor, I work for a Host vendor, although I suspect Microsoft has as many hosts operating as intermediate systems and NATs as most vendors! The issues I brought up against AH were based on several issues: AH is/was fully redundant, and therefore did nothing but bloat the size of an "IPSEC compliant" piece of software and hardware. There were Silicon vendors who told us that the combination of AH and other enveloping (ESP-NULL, tunneling, etc.) would blow the computational and datapipe budgets they had in their designs. One large silicon vendor asked us to consider not supporting AH in combination with other IPSEC and tunneling configurations. Lastly, AH would confuse the "best common practice" of deploying IPSEC - do you use AH or ESP with NULL crypto or .... Extending ESP was a superior way to address the requirements presented in the course of IPSEC development. The arguments for AH: I) the document was already written and we are in a hurry because IPSEC can not happen until docs went to PS II)there are existing/working implementations III) and my favorite - and I paraphrase - this AH issue was already discussed, and most experts agree that AH was something akin to unnecessary/botch/etc., but since the pesky critter was still in the doc we needed to move on. It could be fixed at DS or later. IV) AH was the way to say "no data encryption in this packet" to comply with crypto wary governments. Jeff Schiller asked me if we/they left AH in the arch doc would Microsoft build versions of IPSEC without AH? To which I noted that this was not a proper question for a standards meeting and that for PC and Server implementations this was less of an issue, but for small devices (which MS also builds for) it could become a large issue. If AH can be left for historical, so much the better. cheers, peter From owner-ipsec@lists.tislabs.com Thu Apr 5 17:27:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA28424; Thu, 5 Apr 2001 17:27:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11468 Thu, 5 Apr 2001 19:39:59 -0400 (EDT) To: sommerfeld@East.Sun.COM cc: ipsec@lists.tislabs.com In-reply-to: sommerfeld's message of Thu, 05 Apr 2001 12:42:15 -0400. <200104051642.f35GgF913404@thunk.east.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: IPsec and RTP crypto From: itojun@iijlab.net Date: Fri, 06 Apr 2001 08:44:14 +0900 Message-ID: <3516.986514254@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> i don't think it a "poor fit" in mobile-ip6 case. >Here's a more specific concern: >The use of ipsec for protecting piggybacked binding updates interferes >with safe use of ipsec opportunistic encryption. >A service may set up a listening tcp port with a policy which says >"allow cleartext, or AH-protected, but once encryption is used, >require it on all subsequent packets". >Now, it receives an AH-protected TCP SYN with a binding update >attached (which seems to be a highly likely combination). >Is the receiver to interpret the use of ipsec for that packet as: >a) an indication that all other traffic on this connection will be >protected with AH? >b) a signal that just the segment with the binding update is protected >and to expect cleartext on other packets? >The conservative thing to do is to assume (a), and prevent the >connection from being assassinated by forged unauthenticated RST's. i see. in this case AH is not the culprit, mobile-ip6 binding update piggyback is! i don't understand why people are attacking AH. itojun From owner-ipsec@lists.tislabs.com Thu Apr 5 17:42:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA29567; Thu, 5 Apr 2001 17:42:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA11549 Thu, 5 Apr 2001 20:00:03 -0400 (EDT) Message-Id: <200104060004.f3604B915467@thunk.east.sun.com> From: Bill Sommerfeld To: itojun@iijlab.net cc: sommerfeld@East.Sun.COM, ipsec@lists.tislabs.com Subject: Re: IPsec and RTP crypto In-reply-to: Your message of "Fri, 06 Apr 2001 08:44:14 +0900." <3516.986514254@coconut.itojun.org> Reply-to: sommerfeld@East.Sun.COM Date: Thu, 05 Apr 2001 20:04:11 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > i see. in this case AH is not the culprit, mobile-ip6 binding update > piggyback is! Exactly. - Bill From owner-ipsec@lists.tislabs.com Fri Apr 6 07:09:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA29299; Fri, 6 Apr 2001 07:09:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13624 Fri, 6 Apr 2001 08:58:33 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Stephen Kent'" Cc: Subject: RE: On transport-level policy enforcement (was Re: RFC 2401...) Date: Fri, 6 Apr 2001 08:57:24 -0400 Message-Id: <00e701c0be99$30ff3800$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-reply-to: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, Thanks for clarifying this. I only asked because we had heard of earlier suggestions for caching SPD rules where the requirement that the decorrelated database be fully precalculated was not stated. I agree that it makes sense to store the database in this format. Yes, the SPD will be larger, but I am willing to bet that the scaling will be better than O(n). This seems like an implementation detail, and an implementation doing it this way today wouldn't really be non-compliant, since it is merely an optimization of an ordered database. But it's worth mentioning in the RFC anyway... One potential complication is dynamic SPD rules. An application will need to be able to add and delete rules dynamically without having to rebuild the entire database. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Tuesday, April 03, 2001 7:21 PM > To: andrew.krywaniuk@alcatel.com > Cc: ipsec@lists.tislabs.com > Subject: RE: On transport-level policy enforcement (was Re: > RFC 2401...) > > > Andrew, > > > > 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. > > > >Steve, > > > >If you'd like to discuss how this will be done, either on > the list or at the > >meeting, I think several of us would be interested. My > instinct tells me > >that this is going to require some extra rules that limit > the ways in which > >policy can be expressed, and I'm wondering what they are. > > Whoops! I lost this one in my inbox for quite a while! > Sorry about that. > > During some work for DARPA on security policy management in complex > security domain topologies, some BBN researchers came across the idea > of decorrelating the entries in the SPD, i.e., processing them so > that no two entries overlap. This increases the size of the SPD, but > the resulting database no longer needs to be ordered. since any > packet will match at most one entry. So, I propose adopting a model > that shows the SPD as a decorrelated database, and adding an SPD > cache to the model. When an SA is established, one looks into the SPD > and finds a match, then moves the entry to the SPD cache, where all > future searches for outbound packets take place. Only if you have a > miss on this cache for an outbound packet do you go back to search > the SPD, e.g., as would occur if an SG encountered a new traffic > stream. > > I think will make the explanation much clearer, and if one chooses > to mimic it in an implementation (which is not required, of course) > the lookup time for outbound traffic generally would be faster too. > > > As for your concern re policy, I don't see a problem, since the > decorrleation process transforms the original, ordered SPD into an > unordered, but equivalent database. > > Steve > From owner-ipsec@lists.tislabs.com Fri Apr 6 15:28:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA04547; Fri, 6 Apr 2001 15:28:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA15288 Fri, 6 Apr 2001 17:08:40 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <00e701c0be99$30ff3800$1e72788a@andrewk3.ca.newbridge.com> References: <00e701c0be99$30ff3800$1e72788a@andrewk3.ca.newbridge.com> Date: Fri, 6 Apr 2001 17:08:00 -0400 To: From: Stephen Kent Subject: RE: On transport-level policy enforcement (was Re: RFC 2401...) Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew, >Steve, > >Thanks for clarifying this. I only asked because we had heard of earlier >suggestions for caching SPD rules where the requirement that the >decorrelated database be fully precalculated was not stated. I agree that it >makes sense to store the database in this format. Yes, the SPD will be >larger, but I am willing to bet that the scaling will be better than O(n). >This seems like an implementation detail, and an implementation doing it >this way today wouldn't really be non-compliant, since it is merely an >optimization of an ordered database. But it's worth mentioning in the RFC >anyway... > >One potential complication is dynamic SPD rules. An application will need to >be able to add and delete rules dynamically without having to rebuild the >entire database. I think there is an opportunity for folks to work on optimizing the decorrelation algorithm for dynamic addition/deletion operations. Deletion should not be a problem; back pointers to the decorrelated entries will enable one to remove them. Addition may be a bit harder. Steve From owner-ipsec@lists.tislabs.com Fri Apr 6 19:36:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA16296; Fri, 6 Apr 2001 19:36:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA15754 Fri, 6 Apr 2001 21:24:07 -0400 (EDT) Message-ID: <20010407012830.18023.qmail@web1403.mail.yahoo.com> Date: Fri, 6 Apr 2001 18:28:30 -0700 (PDT) From: Pyda Srisuresh Subject: RE: On transport-level policy enforcement (was Re: RFC 2401...) To: Stephen Kent , andrew.krywaniuk@alcatel.com Cc: ipsec@lists.tislabs.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --- Stephen Kent wrote: > Andrew, > > >Steve, > > > >Thanks for clarifying this. I only asked because we had heard of earlier > >suggestions for caching SPD rules where the requirement that the > >decorrelated database be fully precalculated was not stated. I agree that it > >makes sense to store the database in this format. Yes, the SPD will be > >larger, but I am willing to bet that the scaling will be better than O(n). > >This seems like an implementation detail, and an implementation doing it > >this way today wouldn't really be non-compliant, since it is merely an > >optimization of an ordered database. But it's worth mentioning in the RFC > >anyway... > > > >One potential complication is dynamic SPD rules. An application will need to > >be able to add and delete rules dynamically without having to rebuild the > >entire database. > > I think there is an opportunity for folks to work on optimizing the > decorrelation algorithm for dynamic addition/deletion operations. > Deletion should not be a problem; back pointers to the decorrelated > entries will enable one to remove them. Addition may be a bit harder. > > Steve Addition is even easier, if you assume that dynamic SPD entries will be session specific (i.e, no regular expressions) and will only need exact match. In such a case, each new SPD entry can simply be prepended at the start of the SPD list (de-correlated, cached SPD). Assuming that the order is no longer important, it is quite reasonable to seperate individual session specific entries from the regular expression based entries and list them in that order. cheers, suresh __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ From owner-ipsec@lists.tislabs.com Mon Apr 9 08:29:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA06462; Mon, 9 Apr 2001 08:29:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21708 Mon, 9 Apr 2001 10:11:08 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <20010407012830.18023.qmail@web1403.mail.yahoo.com> References: <20010407012830.18023.qmail@web1403.mail.yahoo.com> Date: Mon, 9 Apr 2001 10:09:53 -0400 To: Pyda Srisuresh 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 Surseh, >--- Stephen Kent wrote: >> Andrew, >> >> >Steve, >> > >> >Thanks for clarifying this. I only asked because we had heard of earlier >> >suggestions for caching SPD rules where the requirement that the >> >decorrelated database be fully precalculated was not stated. I >>agree that it >> >makes sense to store the database in this format. Yes, the SPD will be >> >larger, but I am willing to bet that the scaling will be better than O(n). >> >This seems like an implementation detail, and an implementation doing it >> >this way today wouldn't really be non-compliant, since it is merely an >> >optimization of an ordered database. But it's worth mentioning in the RFC >> >anyway... >> > >> >One potential complication is dynamic SPD rules. An application >>will need to >> >be able to add and delete rules dynamically without having to rebuild the >> >entire database. >> >> I think there is an opportunity for folks to work on optimizing the >> decorrelation algorithm for dynamic addition/deletion operations. >> Deletion should not be a problem; back pointers to the decorrelated >> entries will enable one to remove them. Addition may be a bit harder. >> >> Steve > >Addition is even easier, if you assume that dynamic SPD entries will be >session specific (i.e, no regular expressions) and will only need exact >match. In such a case, each new SPD entry can simply be prepended at the >start of the SPD list (de-correlated, cached SPD). yes, if dynamic entries are fully specified (no wildcards) then it should be easy to add a cache entry. >Assuming that the order is no longer important, it is quite reasonable to >seperate individual session specific entries from the regular expression >based entries and list them in that order. Order is still important in the uncorrelated (base) SPD, but adding fully qualified entries is independent of order. Steve From owner-ipsec@lists.tislabs.com Mon Apr 9 10:49:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA17209; Mon, 9 Apr 2001 10:49:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22327 Mon, 9 Apr 2001 12:53:44 -0400 (EDT) From: "Christian Franzen" To: Subject: PKI and IPSec Date: Mon, 9 Apr 2001 18:58:46 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am searching for information about PKI used with IPSec. IKE does not describe how to fetch certificate data, right? Which documents describe the way how to handle certificates? How to enroll them? Are there differences between PKI used with clients or gateways? Thank you Christian From owner-ipsec@lists.tislabs.com Mon Apr 9 11:30:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA20096; Mon, 9 Apr 2001 11:30:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA22497 Mon, 9 Apr 2001 13:41:01 -0400 (EDT) Message-ID: <3AD1ED5B.2D68703B@miel.mot.com> Date: Mon, 09 Apr 2001 22:41:55 +0530 From: Rohit Aradhya Organization: Motorola, India X-Mailer: Mozilla 4.51 [en] (X11; I; HP-UX B.10.20 9000/782) X-Accept-Language: en MIME-Version: 1.0 To: Christian Franzen , ipsec@lists.tislabs.com Subject: Re: PKI and IPSec References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Checkout RFC 2459, it has details regarding PKI certificate and CRL profiles.. -Rohit Christian Franzen wrote: > Hi, > > I am searching for information about PKI used with IPSec. IKE does not > describe how to fetch certificate data, right? > Which documents describe the way how to handle certificates? How to enroll > them? Are there differences between PKI used with clients or gateways? > > Thank you > Christian -- -------------------------------------------------------- [x] General Business Information [ ] Motorola Internal Use only [ ] Motorola Confidential Proprietary -------------------------------------------------------- Rohit Aradhya, Motorola Banglore, India Ph- (080)5598615 X-4005 From owner-ipsec@lists.tislabs.com Wed Apr 11 12:28:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA07978; Wed, 11 Apr 2001 12:28:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00123 Wed, 11 Apr 2001 13:58:28 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 11 Apr 2001 14:02:24 -0400 To: "Peter Ford" From: Stephen Kent Subject: RE: Death to AH (was Re: SA identification) Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Peter, > > >The issues I brought up against AH were based on several issues: > >AH is/was fully redundant, and therefore did nothing but bloat the size >of an "IPSEC compliant" piece of software and hardware. There were >Silicon vendors who told us that the combination of AH and other >enveloping (ESP-NULL, tunneling, etc.) would blow the computational and >datapipe budgets they had in their designs. One large silicon vendor >asked us to consider not supporting AH in combination with other IPSEC >and tunneling configurations. Lastly, AH would confuse the "best >common practice" of deploying IPSEC - do you use AH or ESP with NULL >crypto or .... Extending ESP was a superior way to address the >requirements presented in the course of IPSEC development. AH is not fully redundant. It is fair to say that one can achieve ALMOST ALL the features of AH through the use of tunnel mode ESP, sans encryption, but the two are not exactly equivalent. Presumably the argument we've having now is determining whether the situations where AH offers unique services warrant keeping it as part of the IPsec suite, in a mandatory capacity. Your reference to the difficulty chip vendors envisioned in supporting AH seemed to be a major motivation for the argument you put forth, and that's an understandable concern. However, the IETF, for better or worse, has usually not deferred to hardware vendor concerns about implementation issues, relying on Moore's law to address these issues over time. Instead, we often focus on software implementation issues. I don't understand the reference to "best common practice .." above. Extending ESP was never seriously considered. No I-Ds on the topic were ever published. There was considerable sentiment that making one protocol (ESP) more complex as a means to avoid the need to implement another protocol (AH) was not going to result in an overall simpler system. I think this sentiment is accurate and persists today. > >The arguments for AH: > >I) the document was already written and we are in a hurry because IPSEC >can not happen until docs went to PS I believe the IETF meeting I referred to took place well before we submitted 2401 as an RFC, so this argument seems a bit out of sync. >II)there are existing/working implementations true >III) and my favorite - and I paraphrase - this AH issue was already >discussed, and most experts agree that AH was something akin to >unnecessary/botch/etc., but since the pesky critter was still in the doc >we needed to move on. It could be fixed at DS or later. I don't recall that. >IV) AH was the way to say "no data encryption in this packet" to comply >with crypto wary governments. Still true, but given the IAB position on crypto, not a good rationale. > >Jeff Schiller asked me if we/they left AH in the arch doc would >Microsoft build versions of IPSEC without AH? To which I noted that >this was not a proper question for a standards meeting and that for PC >and Server implementations this was less of an issue, but for small >devices (which MS also builds for) it could become a large issue. Unfortunately, my cursory examination of the MS implementation of IPsec for PCs and servers last May revealed that it is not compliant with 2401 anyway, e.g., it fails to provide a means for a user or administrator to order the SPD entries, a very explicit requirement. the lack of this facility makes it hard, if not impossible, for one to determine how the implementation will process traffic. Steve From owner-ipsec@lists.tislabs.com Wed Apr 11 12:29:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA08000; Wed, 11 Apr 2001 12:29:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00129 Wed, 11 Apr 2001 13:58:30 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200104041551.f34FpZw04440@marajade.sandelman.ottawa.on.ca> References: <200104041551.f34FpZw04440@marajade.sandelman.ottawa.on.ca> Date: Wed, 11 Apr 2001 12:35:37 -0400 To: Michael Richardson From: Stephen Kent Subject: Re: Death to AH (was Re: SA identification) Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:51 AM -0400 4/4/01, Michael Richardson wrote: > >>>>> "Stephen" == Stephen Kent writes: > Stephen> RFC 2401 states that compliant implementations MUST support AH in > Stephen> several places. This language is present because the WG strongly > Stephen> endorsed it. Fejj Schiller took a straw poll after >Peter Ford (MS) > > Yes, I understood the argument at the time, and I agreed with it. > > What I am trying to get at, is... when the VPN vendors say that they are >"compliant", what does that specifically mean. I.e. when marketing says "do >IPsec", on what basis does engineering translate this to. Does this mean >"RFC2401" (which wouldn't necessarily mean that you have had IKE, btw), etc. > > So, it then falls to the compliance testers to say, > "IPsec = 2401...2409, plus some PKI subset" yes, one needs to identify a set of RFCs, but adherence to 2401 includes several other RFCs by reference, because 2401 does mandate AH, ESP, selected algorithms, etc. The one big thing it misses is a requirement for automated key management. I would have liked to include it, but Ran, and a few other folks, were insistent about not mandating anything more than manual key management. I think this is a mistake. The KINK folks will argue that IKE should not be mandated, but I would like to see a requirement for SOME automated key management. After all, we have made value judgements about other things to include or exclude based on our perception of whether the resulting system would be acceptably secure, in principle. One can argue that, in general, manual key management is likely to be done so poorly as to undermine the security of the system, and thus should be discouraged. But, unless the WG agrees with this position, we'll be stuck with a partial definition of what it means to be IPsec compliant. > since there aren't any PKI requirements stated in that list, they have to >add those from the appropriate PKIX work, etc. Yes, we are clearly missing a PKI profile, for those who choose to use certs with IKE. That should be linked to IKE, though, not to the base IPsec specs. > > So, when VPN vendors say that they don't like AH for some set of reasons >and like to remove it, I ask the question: "who said you had to implement >it?" > > (Recall the joke with the patient who says "Doctor, it hurts when >I do this!", > Doctor says "Don't do that!") I think the answer os because the vendors view 2401 as the base standard for IPsec [I do :-)] and thus they want to comply with it, which mandates AH support. > > IPsec is a tool to implement many things, including VPNs, but VPN is >clearly the primary user at present. I would hate to have AH junked for all >end hosts because it didn't agree with the VPN subset. > As a precedent, we have different router and end-system requirements at >present. I think that 2401 speaks to end systems requirements, not gateway >requirements. I disagree; 2401 speaks to both. We impose different requirements on hosts vs. SGs in 2401 and we will try to do an even better job in the next pass. > > It seems that the appropriate thing to do is to write a BCP on the "VPN" >problem, and then the VPN vendor's can claim compliance to *that* rather than >to 2401. > > The full blown host systems (Sun, KAME, Win2k,...) are the ones that we >want to be 2401 compliant. I haven't seen any of them argue strongly for >removing AH (or transport mode). A security gateway that is not 2401 compliant has a very limited basis for claiming IPsec compliance, as it's hard to cite what the device can claim to support, exclusive of 2401, and still be interoperable and offer a well-defined service. > The water will get even more muddy as IPSP and IPSRA work goes to PS. What >will "IPsec compliant" mean then? I would expect vendors to claim compliance with 2401bis and with appropriate IPRSA RFCs, for those devices that are intended to support remote access. > > Stephen> but I am surprised by the form of your question. It >seemed to suggest > Stephen> that a desire to claim compliance with the IETF standard for the > Stephen> IPsec architecture was not sufficient motivation, >whereas compliance > Stephen> with industry test programs that are not aligned with >IETF standards > Stephen> was a good motivation. if you really feel this way, perhaps you > Stephen> should focus more on contributing to ICSA and related >efforts, vs. > Stephen> the IPsec WG :-). > > This issue is that the industry test programs are not handing out "IPsec" >conformance certificates, because > 1) it is a hard thing (i.e. $$$) to fully test > 2) the end-customers don't really want all of of what "IPsec" > could be. They mostly want VPNs. > I've always thought that the groups that had out compliance certificates for IPSec [sic] compliance were engaged in a subtle game that motivated the misspelling of the protocol suite :-). Steve From owner-ipsec@lists.tislabs.com Wed Apr 11 19:12:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA05668; Wed, 11 Apr 2001 19:12:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA01325 Wed, 11 Apr 2001 21:07:58 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: "Hilarie Orman" Cc: kent@bbn.com, ipsec@lists.tislabs.com Subject: Re: IPsec and RTP crypto Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Apr 2001 21:11:30 -0400 Message-Id: <20010412011130.1E29B4D97@challenger.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , "Hilarie Orman" writes: >Long ago we implemented this selective use of IPsec by >permitting connections to mix protected and unprotected >traffic. The send and receive interfaces made the level >of protection obvious; the application layer could decide >whether or not to accept data for each received chunk >(all the bytes in a chunk had the same protections). This >allowed password protection, in particular. It didn't seem >(at the time), that IPsec was an impediment to this usage. > How can you do that? It sounds like it would take some very strange layering, since in most stacks TCP ACKs are sent when the data is received, not when it's passed to the application -- and that, in turn, means that the sending host may have discarded some data before it knows if it needs to be sent with a different security level. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Thu Apr 12 08:22:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA12587; Thu, 12 Apr 2001 08:22:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA02909 Thu, 12 Apr 2001 10:06:04 -0400 (EDT) Message-ID: <80B684C5E29FD211AA8000A0C9CDD91907CBCD25@il0015exch005u.ih.lucent.com> From: "Kopeikin, Roy A (Roy)" To: Stephen Kent , Peter Ford Cc: ipsec@lists.tislabs.com Subject: RE: Death to AH (was Re: SA identification) Date: Thu, 12 Apr 2001 09:10:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Concerning use/need for AH: Do companies like iPASS use it? Their service allows you to login to their POP from anywhere in the world. They encrypt and then authenticate this access attempt (not sure they use IPSec AH today). Once this access is authorized, they encrypt nothing, hence having no use for ESP. However the corporation subscribing to this service has no use for AH, butr could be interested in using ESP. iPASS advertised it was compatible with many VPN solutions, including IPSec ones. So could a company liek iPASS use ESP instead of AH for their service? What about other VPN-access-vendors? What do they want? -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Wednesday, April 11, 2001 1:02 PM To: Peter Ford Cc: ipsec@lists.tislabs.com Subject: RE: Death to AH (was Re: SA identification) Peter, > > >The issues I brought up against AH were based on several issues: > >AH is/was fully redundant, and therefore did nothing but bloat the size >of an "IPSEC compliant" piece of software and hardware. There were >Silicon vendors who told us that the combination of AH and other >enveloping (ESP-NULL, tunneling, etc.) would blow the computational and >datapipe budgets they had in their designs. One large silicon vendor >asked us to consider not supporting AH in combination with other IPSEC >and tunneling configurations. Lastly, AH would confuse the "best >common practice" of deploying IPSEC - do you use AH or ESP with NULL >crypto or .... Extending ESP was a superior way to address the >requirements presented in the course of IPSEC development. AH is not fully redundant. It is fair to say that one can achieve ALMOST ALL the features of AH through the use of tunnel mode ESP, sans encryption, but the two are not exactly equivalent. Presumably the argument we've having now is determining whether the situations where AH offers unique services warrant keeping it as part of the IPsec suite, in a mandatory capacity. Your reference to the difficulty chip vendors envisioned in supporting AH seemed to be a major motivation for the argument you put forth, and that's an understandable concern. However, the IETF, for better or worse, has usually not deferred to hardware vendor concerns about implementation issues, relying on Moore's law to address these issues over time. Instead, we often focus on software implementation issues. I don't understand the reference to "best common practice .." above. Extending ESP was never seriously considered. No I-Ds on the topic were ever published. There was considerable sentiment that making one protocol (ESP) more complex as a means to avoid the need to implement another protocol (AH) was not going to result in an overall simpler system. I think this sentiment is accurate and persists today. > >The arguments for AH: > >I) the document was already written and we are in a hurry because IPSEC >can not happen until docs went to PS I believe the IETF meeting I referred to took place well before we submitted 2401 as an RFC, so this argument seems a bit out of sync. >II)there are existing/working implementations true >III) and my favorite - and I paraphrase - this AH issue was already >discussed, and most experts agree that AH was something akin to >unnecessary/botch/etc., but since the pesky critter was still in the doc >we needed to move on. It could be fixed at DS or later. I don't recall that. >IV) AH was the way to say "no data encryption in this packet" to comply >with crypto wary governments. Still true, but given the IAB position on crypto, not a good rationale. > >Jeff Schiller asked me if we/they left AH in the arch doc would >Microsoft build versions of IPSEC without AH? To which I noted that >this was not a proper question for a standards meeting and that for PC >and Server implementations this was less of an issue, but for small >devices (which MS also builds for) it could become a large issue. Unfortunately, my cursory examination of the MS implementation of IPsec for PCs and servers last May revealed that it is not compliant with 2401 anyway, e.g., it fails to provide a means for a user or administrator to order the SPD entries, a very explicit requirement. the lack of this facility makes it hard, if not impossible, for one to determine how the implementation will process traffic. Steve From owner-ipsec@lists.tislabs.com Thu Apr 12 10:26:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA22519; Thu, 12 Apr 2001 10:26:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03229 Thu, 12 Apr 2001 12:27:14 -0400 (EDT) From: "John Lowry" To: "Kopeikin, Roy A \(Roy\)" , "Stephen Kent" , "Peter Ford" Cc: Subject: RE: Death to AH (was Re: SA identification) Date: Thu, 12 Apr 2001 12:34:47 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <80B684C5E29FD211AA8000A0C9CDD91907CBCD25@il0015exch005u.ih.lucent.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk AH is likely to be attractive to network operators who are running intrusion detection systems and virus checkers at sub-domain (and less frequently at domain) boundaries. It provides authentication while preserving the ability to watch the traffic. A minor point but ... John -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Kopeikin, Roy A (Roy) Sent: Thursday, April 12, 2001 10:10 AM To: Stephen Kent; Peter Ford Cc: ipsec@lists.tislabs.com Subject: RE: Death to AH (was Re: SA identification) Concerning use/need for AH: Do companies like iPASS use it? Their service allows you to login to their POP from anywhere in the world. They encrypt and then authenticate this access attempt (not sure they use IPSec AH today). Once this access is authorized, they encrypt nothing, hence having no use for ESP. However the corporation subscribing to this service has no use for AH, butr could be interested in using ESP. iPASS advertised it was compatible with many VPN solutions, including IPSec ones. So could a company liek iPASS use ESP instead of AH for their service? What about other VPN-access-vendors? What do they want? -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Wednesday, April 11, 2001 1:02 PM To: Peter Ford Cc: ipsec@lists.tislabs.com Subject: RE: Death to AH (was Re: SA identification) Peter, > > >The issues I brought up against AH were based on several issues: > >AH is/was fully redundant, and therefore did nothing but bloat the size >of an "IPSEC compliant" piece of software and hardware. There were >Silicon vendors who told us that the combination of AH and other >enveloping (ESP-NULL, tunneling, etc.) would blow the computational and >datapipe budgets they had in their designs. One large silicon vendor >asked us to consider not supporting AH in combination with other IPSEC >and tunneling configurations. Lastly, AH would confuse the "best >common practice" of deploying IPSEC - do you use AH or ESP with NULL >crypto or .... Extending ESP was a superior way to address the >requirements presented in the course of IPSEC development. AH is not fully redundant. It is fair to say that one can achieve ALMOST ALL the features of AH through the use of tunnel mode ESP, sans encryption, but the two are not exactly equivalent. Presumably the argument we've having now is determining whether the situations where AH offers unique services warrant keeping it as part of the IPsec suite, in a mandatory capacity. Your reference to the difficulty chip vendors envisioned in supporting AH seemed to be a major motivation for the argument you put forth, and that's an understandable concern. However, the IETF, for better or worse, has usually not deferred to hardware vendor concerns about implementation issues, relying on Moore's law to address these issues over time. Instead, we often focus on software implementation issues. I don't understand the reference to "best common practice .." above. Extending ESP was never seriously considered. No I-Ds on the topic were ever published. There was considerable sentiment that making one protocol (ESP) more complex as a means to avoid the need to implement another protocol (AH) was not going to result in an overall simpler system. I think this sentiment is accurate and persists today. > >The arguments for AH: > >I) the document was already written and we are in a hurry because IPSEC >can not happen until docs went to PS I believe the IETF meeting I referred to took place well before we submitted 2401 as an RFC, so this argument seems a bit out of sync. >II)there are existing/working implementations true >III) and my favorite - and I paraphrase - this AH issue was already >discussed, and most experts agree that AH was something akin to >unnecessary/botch/etc., but since the pesky critter was still in the doc >we needed to move on. It could be fixed at DS or later. I don't recall that. >IV) AH was the way to say "no data encryption in this packet" to comply >with crypto wary governments. Still true, but given the IAB position on crypto, not a good rationale. > >Jeff Schiller asked me if we/they left AH in the arch doc would >Microsoft build versions of IPSEC without AH? To which I noted that >this was not a proper question for a standards meeting and that for PC >and Server implementations this was less of an issue, but for small >devices (which MS also builds for) it could become a large issue. Unfortunately, my cursory examination of the MS implementation of IPsec for PCs and servers last May revealed that it is not compliant with 2401 anyway, e.g., it fails to provide a means for a user or administrator to order the SPD entries, a very explicit requirement. the lack of this facility makes it hard, if not impossible, for one to determine how the implementation will process traffic. Steve From owner-ipsec@lists.tislabs.com Fri Apr 13 08:41:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA00483; Fri, 13 Apr 2001 08:41:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05660 Fri, 13 Apr 2001 10:17:26 -0400 (EDT) To: "John Lowry" Cc: "Kopeikin, Roy A \(Roy\)" , "Stephen Kent" , "Peter Ford" , Subject: Re: Death to AH (was Re: SA identification) References: From: Derek Atkins Date: 13 Apr 2001 10:21:41 -0400 In-Reply-To: "John Lowry"'s message of "Thu, 12 Apr 2001 12:34:47 -0400" Message-ID: Lines: 133 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So does ESP with Authentication and NULL-encryption. -derek "John Lowry" writes: > AH is likely to be attractive to network operators > who are running intrusion detection systems and virus > checkers at sub-domain (and less frequently at domain) boundaries. > It provides authentication while preserving the ability to > watch the traffic. > > A minor point but ... > > John > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Kopeikin, Roy A (Roy) > Sent: Thursday, April 12, 2001 10:10 AM > To: Stephen Kent; Peter Ford > Cc: ipsec@lists.tislabs.com > Subject: RE: Death to AH (was Re: SA identification) > > > Concerning use/need for AH: > > Do companies like iPASS use it? Their service allows you to login to their > POP from anywhere in the world. They encrypt and then authenticate this > access attempt (not sure they use IPSec AH today). Once this access is > authorized, they encrypt nothing, hence having no use for ESP. > > However the corporation subscribing to this service has no use for AH, butr > could be interested in using ESP. iPASS advertised it was compatible with > many VPN solutions, including IPSec ones. > > So could a company liek iPASS use ESP instead of AH for their service? What > about other VPN-access-vendors? What do they want? > > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Wednesday, April 11, 2001 1:02 PM > To: Peter Ford > Cc: ipsec@lists.tislabs.com > Subject: RE: Death to AH (was Re: SA identification) > > > Peter, > > > > > > >The issues I brought up against AH were based on several issues: > > > >AH is/was fully redundant, and therefore did nothing but bloat the size > >of an "IPSEC compliant" piece of software and hardware. There were > >Silicon vendors who told us that the combination of AH and other > >enveloping (ESP-NULL, tunneling, etc.) would blow the computational and > >datapipe budgets they had in their designs. One large silicon vendor > >asked us to consider not supporting AH in combination with other IPSEC > >and tunneling configurations. Lastly, AH would confuse the "best > >common practice" of deploying IPSEC - do you use AH or ESP with NULL > >crypto or .... Extending ESP was a superior way to address the > >requirements presented in the course of IPSEC development. > > AH is not fully redundant. It is fair to say that one can achieve > ALMOST ALL the features of AH through the use of tunnel mode ESP, > sans encryption, but the two are not exactly equivalent. Presumably > the argument we've having now is determining whether the situations > where AH offers unique services warrant keeping it as part of the > IPsec suite, in a mandatory capacity. > > Your reference to the difficulty chip vendors envisioned in > supporting AH seemed to be a major motivation for the argument you > put forth, and that's an understandable concern. However, the IETF, > for better or worse, has usually not deferred to hardware vendor > concerns about implementation issues, relying on Moore's law to > address these issues over time. Instead, we often focus on software > implementation issues. > > I don't understand the reference to "best common practice .." above. > > Extending ESP was never seriously considered. No I-Ds on the topic > were ever published. There was considerable sentiment that making one > protocol (ESP) more complex as a means to avoid the need to implement > another protocol (AH) was not going to result in an overall simpler > system. I think this sentiment is accurate and persists today. > > > > >The arguments for AH: > > > >I) the document was already written and we are in a hurry because IPSEC > >can not happen until docs went to PS > > I believe the IETF meeting I referred to took place well before we > submitted 2401 as an RFC, so this argument seems a bit out of sync. > > >II)there are existing/working implementations > > true > > >III) and my favorite - and I paraphrase - this AH issue was already > >discussed, and most experts agree that AH was something akin to > >unnecessary/botch/etc., but since the pesky critter was still in the doc > >we needed to move on. It could be fixed at DS or later. > > I don't recall that. > > >IV) AH was the way to say "no data encryption in this packet" to comply > >with crypto wary governments. > > Still true, but given the IAB position on crypto, not a good rationale. > > > > >Jeff Schiller asked me if we/they left AH in the arch doc would > >Microsoft build versions of IPSEC without AH? To which I noted that > >this was not a proper question for a standards meeting and that for PC > >and Server implementations this was less of an issue, but for small > >devices (which MS also builds for) it could become a large issue. > > Unfortunately, my cursory examination of the MS implementation of > IPsec for PCs and servers last May revealed that it is not compliant > with 2401 anyway, e.g., it fails to provide a means for a user or > administrator to order the SPD entries, a very explicit requirement. > the lack of this facility makes it hard, if not impossible, for one > to determine how the implementation will process traffic. > > Steve -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Apr 13 08:49:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA01930; Fri, 13 Apr 2001 08:49:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05818 Fri, 13 Apr 2001 10:49:31 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Derek Atkins Cc: "John Lowry" , "Kopeikin, Roy A (Roy)" , "Stephen Kent" , "Peter Ford" , ipsec@lists.tislabs.com Subject: Re: Death to AH (was Re: SA identification) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Apr 2001 10:52:55 -0400 Message-Id: <20010413145255.DF2094D97@challenger.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Derek Atkins writes: >So does ESP with Authentication and NULL-encryption. Yes, but it's not context-free -- unless you know a priori that null encryption is being used, you can't monitor it. This is the one point I'll concede to the AH proponents... > >-derek > >"John Lowry" writes: > >> AH is likely to be attractive to network operators >> who are running intrusion detection systems and virus >> checkers at sub-domain (and less frequently at domain) boundaries. >> It provides authentication while preserving the ability to >> watch the traffic. >> >> A minor point but ... >> >> John >> >> -----Original Message----- >> From: owner-ipsec@lists.tislabs.com >> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Kopeikin, Roy A (Roy) >> Sent: Thursday, April 12, 2001 10:10 AM >> To: Stephen Kent; Peter Ford >> Cc: ipsec@lists.tislabs.com >> Subject: RE: Death to AH (was Re: SA identification) >> >> >> Concerning use/need for AH: >> >> Do companies like iPASS use it? Their service allows you to login to their >> POP from anywhere in the world. They encrypt and then authenticate this >> access attempt (not sure they use IPSec AH today). Once this access is >> authorized, they encrypt nothing, hence having no use for ESP. >> >> However the corporation subscribing to this service has no use for AH, butr >> could be interested in using ESP. iPASS advertised it was compatible with >> many VPN solutions, including IPSec ones. >> >> So could a company liek iPASS use ESP instead of AH for their service? What >> about other VPN-access-vendors? What do they want? >> >> -----Original Message----- >> From: Stephen Kent [mailto:kent@bbn.com] >> Sent: Wednesday, April 11, 2001 1:02 PM >> To: Peter Ford >> Cc: ipsec@lists.tislabs.com >> Subject: RE: Death to AH (was Re: SA identification) >> >> >> Peter, >> >> > >> > >> >The issues I brought up against AH were based on several issues: >> > >> >AH is/was fully redundant, and therefore did nothing but bloat the size >> >of an "IPSEC compliant" piece of software and hardware. There were >> >Silicon vendors who told us that the combination of AH and other >> >enveloping (ESP-NULL, tunneling, etc.) would blow the computational and >> >datapipe budgets they had in their designs. One large silicon vendor >> >asked us to consider not supporting AH in combination with other IPSEC >> >and tunneling configurations. Lastly, AH would confuse the "best >> >common practice" of deploying IPSEC - do you use AH or ESP with NULL >> >crypto or .... Extending ESP was a superior way to address the >> >requirements presented in the course of IPSEC development. >> >> AH is not fully redundant. It is fair to say that one can achieve >> ALMOST ALL the features of AH through the use of tunnel mode ESP, >> sans encryption, but the two are not exactly equivalent. Presumably >> the argument we've having now is determining whether the situations >> where AH offers unique services warrant keeping it as part of the >> IPsec suite, in a mandatory capacity. >> >> Your reference to the difficulty chip vendors envisioned in >> supporting AH seemed to be a major motivation for the argument you >> put forth, and that's an understandable concern. However, the IETF, >> for better or worse, has usually not deferred to hardware vendor >> concerns about implementation issues, relying on Moore's law to >> address these issues over time. Instead, we often focus on software >> implementation issues. >> >> I don't understand the reference to "best common practice .." above. >> >> Extending ESP was never seriously considered. No I-Ds on the topic >> were ever published. There was considerable sentiment that making one >> protocol (ESP) more complex as a means to avoid the need to implement >> another protocol (AH) was not going to result in an overall simpler >> system. I think this sentiment is accurate and persists today. >> >> > >> >The arguments for AH: >> > >> >I) the document was already written and we are in a hurry because IPSEC >> >can not happen until docs went to PS >> >> I believe the IETF meeting I referred to took place well before we >> submitted 2401 as an RFC, so this argument seems a bit out of sync. >> >> >II)there are existing/working implementations >> >> true >> >> >III) and my favorite - and I paraphrase - this AH issue was already >> >discussed, and most experts agree that AH was something akin to >> >unnecessary/botch/etc., but since the pesky critter was still in the doc >> >we needed to move on. It could be fixed at DS or later. >> >> I don't recall that. >> >> >IV) AH was the way to say "no data encryption in this packet" to comply >> >with crypto wary governments. >> >> Still true, but given the IAB position on crypto, not a good rationale. >> >> > >> >Jeff Schiller asked me if we/they left AH in the arch doc would >> >Microsoft build versions of IPSEC without AH? To which I noted that >> >this was not a proper question for a standards meeting and that for PC >> >and Server implementations this was less of an issue, but for small >> >devices (which MS also builds for) it could become a large issue. >> >> Unfortunately, my cursory examination of the MS implementation of >> IPsec for PCs and servers last May revealed that it is not compliant >> with 2401 anyway, e.g., it fails to provide a means for a user or >> administrator to order the SPD entries, a very explicit requirement. >> the lack of this facility makes it hard, if not impossible, for one >> to determine how the implementation will process traffic. >> >> Steve > >-- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available > --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Fri Apr 13 09:10:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA03822; Fri, 13 Apr 2001 09:10:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05907 Fri, 13 Apr 2001 11:09:52 -0400 (EDT) To: "Steven M. Bellovin" Cc: "John Lowry" , "Kopeikin, Roy A (Roy)" , "Stephen Kent" , "Peter Ford" , ipsec@lists.tislabs.com Subject: Re: Death to AH (was Re: SA identification) References: <20010413145255.DF2094D97@challenger.research.att.com> From: Derek Atkins Date: 13 Apr 2001 11:14:21 -0400 In-Reply-To: "Steven M. Bellovin"'s message of "Fri, 13 Apr 2001 10:52:55 -0400" Message-ID: Lines: 161 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk True. But you can always look inside the ESP data and check if the data _looks_ reasonable. I mean, a TCP or UDP header is fairly distinctive :) You just aren't guaranteed that this will work at all times. -derek "Steven M. Bellovin" writes: > In message , Derek Atkins writes: > >So does ESP with Authentication and NULL-encryption. > > Yes, but it's not context-free -- unless you know a priori that null > encryption is being used, you can't monitor it. > > This is the one point I'll concede to the AH proponents... > > > > >-derek > > > >"John Lowry" writes: > > > >> AH is likely to be attractive to network operators > >> who are running intrusion detection systems and virus > >> checkers at sub-domain (and less frequently at domain) boundaries. > >> It provides authentication while preserving the ability to > >> watch the traffic. > >> > >> A minor point but ... > >> > >> John > >> > >> -----Original Message----- > >> From: owner-ipsec@lists.tislabs.com > >> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Kopeikin, Roy A (Roy) > >> Sent: Thursday, April 12, 2001 10:10 AM > >> To: Stephen Kent; Peter Ford > >> Cc: ipsec@lists.tislabs.com > >> Subject: RE: Death to AH (was Re: SA identification) > >> > >> > >> Concerning use/need for AH: > >> > >> Do companies like iPASS use it? Their service allows you to login to their > >> POP from anywhere in the world. They encrypt and then authenticate this > >> access attempt (not sure they use IPSec AH today). Once this access is > >> authorized, they encrypt nothing, hence having no use for ESP. > >> > >> However the corporation subscribing to this service has no use for AH, butr > >> could be interested in using ESP. iPASS advertised it was compatible with > >> many VPN solutions, including IPSec ones. > >> > >> So could a company liek iPASS use ESP instead of AH for their service? What > >> about other VPN-access-vendors? What do they want? > >> > >> -----Original Message----- > >> From: Stephen Kent [mailto:kent@bbn.com] > >> Sent: Wednesday, April 11, 2001 1:02 PM > >> To: Peter Ford > >> Cc: ipsec@lists.tislabs.com > >> Subject: RE: Death to AH (was Re: SA identification) > >> > >> > >> Peter, > >> > >> > > >> > > >> >The issues I brought up against AH were based on several issues: > >> > > >> >AH is/was fully redundant, and therefore did nothing but bloat the size > >> >of an "IPSEC compliant" piece of software and hardware. There were > >> >Silicon vendors who told us that the combination of AH and other > >> >enveloping (ESP-NULL, tunneling, etc.) would blow the computational and > >> >datapipe budgets they had in their designs. One large silicon vendor > >> >asked us to consider not supporting AH in combination with other IPSEC > >> >and tunneling configurations. Lastly, AH would confuse the "best > >> >common practice" of deploying IPSEC - do you use AH or ESP with NULL > >> >crypto or .... Extending ESP was a superior way to address the > >> >requirements presented in the course of IPSEC development. > >> > >> AH is not fully redundant. It is fair to say that one can achieve > >> ALMOST ALL the features of AH through the use of tunnel mode ESP, > >> sans encryption, but the two are not exactly equivalent. Presumably > >> the argument we've having now is determining whether the situations > >> where AH offers unique services warrant keeping it as part of the > >> IPsec suite, in a mandatory capacity. > >> > >> Your reference to the difficulty chip vendors envisioned in > >> supporting AH seemed to be a major motivation for the argument you > >> put forth, and that's an understandable concern. However, the IETF, > >> for better or worse, has usually not deferred to hardware vendor > >> concerns about implementation issues, relying on Moore's law to > >> address these issues over time. Instead, we often focus on software > >> implementation issues. > >> > >> I don't understand the reference to "best common practice .." above. > >> > >> Extending ESP was never seriously considered. No I-Ds on the topic > >> were ever published. There was considerable sentiment that making one > >> protocol (ESP) more complex as a means to avoid the need to implement > >> another protocol (AH) was not going to result in an overall simpler > >> system. I think this sentiment is accurate and persists today. > >> > >> > > >> >The arguments for AH: > >> > > >> >I) the document was already written and we are in a hurry because IPSEC > >> >can not happen until docs went to PS > >> > >> I believe the IETF meeting I referred to took place well before we > >> submitted 2401 as an RFC, so this argument seems a bit out of sync. > >> > >> >II)there are existing/working implementations > >> > >> true > >> > >> >III) and my favorite - and I paraphrase - this AH issue was already > >> >discussed, and most experts agree that AH was something akin to > >> >unnecessary/botch/etc., but since the pesky critter was still in the doc > >> >we needed to move on. It could be fixed at DS or later. > >> > >> I don't recall that. > >> > >> >IV) AH was the way to say "no data encryption in this packet" to comply > >> >with crypto wary governments. > >> > >> Still true, but given the IAB position on crypto, not a good rationale. > >> > >> > > >> >Jeff Schiller asked me if we/they left AH in the arch doc would > >> >Microsoft build versions of IPSEC without AH? To which I noted that > >> >this was not a proper question for a standards meeting and that for PC > >> >and Server implementations this was less of an issue, but for small > >> >devices (which MS also builds for) it could become a large issue. > >> > >> Unfortunately, my cursory examination of the MS implementation of > >> IPsec for PCs and servers last May revealed that it is not compliant > >> with 2401 anyway, e.g., it fails to provide a means for a user or > >> administrator to order the SPD entries, a very explicit requirement. > >> the lack of this facility makes it hard, if not impossible, for one > >> to determine how the implementation will process traffic. > >> > >> Steve > > > >-- > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > Member, MIT Student Information Processing Board (SIPB) > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > > warlord@MIT.EDU PGP key available > > > > > --Steve Bellovin, http://www.research.att.com/~smb > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Apr 13 10:22:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA06379; Fri, 13 Apr 2001 10:22:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA06235 Fri, 13 Apr 2001 12:39:01 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Scott Fluhrer Cc: Derek Atkins , "John Lowry" , "Kopeikin, Roy A (Roy)" , "Stephen Kent" , "Peter Ford" , ipsec@lists.tislabs.com Subject: Re: Death to AH (was Re: SA identification) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Apr 2001 12:42:02 -0400 Message-Id: <20010413164202.C94E74D97@challenger.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200104131628.ABY04112@mira-sjcm-3.cisco.com>, Scott Fluhrer writes: >At 07:52 AM 4/13/01 , Steven M. Bellovin wrote: >>In message , Derek Atkins writes: >>>So does ESP with Authentication and NULL-encryption. >> >>Yes, but it's not context-free -- unless you know a priori that null >>encryption is being used, you can't monitor it. >> >>This is the one point I'll concede to the AH proponents... > >Actually, I wouldn't concede quite so quickly. AH is not context-free >either -- unless you know a priori that the packet AH is protecting is >not itself encrypted (e.g. ESP is not being used along with AH), you >can't monitor it either. There's a Next Protocol field in the AH header that you can look at. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Fri Apr 13 10:26:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA06535; Fri, 13 Apr 2001 10:26:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA06165 Fri, 13 Apr 2001 12:24:46 -0400 (EDT) Message-Id: <200104131628.ABY04112@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 13 Apr 2001 09:18:29 -0700 To: "Steven M. Bellovin" , Derek Atkins From: Scott Fluhrer Subject: Re: Death to AH (was Re: SA identification) Cc: "John Lowry" , "Kopeikin, Roy A (Roy)" , "Stephen Kent" , "Peter Ford" , ipsec@lists.tislabs.com In-Reply-To: <20010413145255.DF2094D97@challenger.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 07:52 AM 4/13/01 , Steven M. Bellovin wrote: >In message , Derek Atkins writes: >>So does ESP with Authentication and NULL-encryption. > >Yes, but it's not context-free -- unless you know a priori that null >encryption is being used, you can't monitor it. > >This is the one point I'll concede to the AH proponents... Actually, I wouldn't concede quite so quickly. AH is not context-free either -- unless you know a priori that the packet AH is protecting is not itself encrypted (e.g. ESP is not being used along with AH), you can't monitor it either. > >> >>-derek >> >>"John Lowry" writes: >> >>> AH is likely to be attractive to network operators >>> who are running intrusion detection systems and virus >>> checkers at sub-domain (and less frequently at domain) boundaries. >>> It provides authentication while preserving the ability to >>> watch the traffic. >>> >>> A minor point but ... >>> >>> John >>> >>> -----Original Message----- >>> From: owner-ipsec@lists.tislabs.com >>> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Kopeikin, Roy A (Roy) >>> Sent: Thursday, April 12, 2001 10:10 AM >>> To: Stephen Kent; Peter Ford >>> Cc: ipsec@lists.tislabs.com >>> Subject: RE: Death to AH (was Re: SA identification) >>> >>> >>> Concerning use/need for AH: >>> >>> Do companies like iPASS use it? Their service allows you to login to their >>> POP from anywhere in the world. They encrypt and then authenticate this >>> access attempt (not sure they use IPSec AH today). Once this access is >>> authorized, they encrypt nothing, hence having no use for ESP. >>> >>> However the corporation subscribing to this service has no use for AH, butr >>> could be interested in using ESP. iPASS advertised it was compatible with >>> many VPN solutions, including IPSec ones. >>> >>> So could a company liek iPASS use ESP instead of AH for their service? What >>> about other VPN-access-vendors? What do they want? >>> >>> -----Original Message----- >>> From: Stephen Kent [mailto:kent@bbn.com] >>> Sent: Wednesday, April 11, 2001 1:02 PM >>> To: Peter Ford >>> Cc: ipsec@lists.tislabs.com >>> Subject: RE: Death to AH (was Re: SA identification) >>> >>> >>> Peter, >>> >>> > >>> > >>> >The issues I brought up against AH were based on several issues: >>> > >>> >AH is/was fully redundant, and therefore did nothing but bloat the size >>> >of an "IPSEC compliant" piece of software and hardware. There were >>> >Silicon vendors who told us that the combination of AH and other >>> >enveloping (ESP-NULL, tunneling, etc.) would blow the computational and >>> >datapipe budgets they had in their designs. One large silicon vendor >>> >asked us to consider not supporting AH in combination with other IPSEC >>> >and tunneling configurations. Lastly, AH would confuse the "best >>> >common practice" of deploying IPSEC - do you use AH or ESP with NULL >>> >crypto or .... Extending ESP was a superior way to address the >>> >requirements presented in the course of IPSEC development. >>> >>> AH is not fully redundant. It is fair to say that one can achieve >>> ALMOST ALL the features of AH through the use of tunnel mode ESP, >>> sans encryption, but the two are not exactly equivalent. Presumably >>> the argument we've having now is determining whether the situations >>> where AH offers unique services warrant keeping it as part of the >>> IPsec suite, in a mandatory capacity. >>> >>> Your reference to the difficulty chip vendors envisioned in >>> supporting AH seemed to be a major motivation for the argument you >>> put forth, and that's an understandable concern. However, the IETF, >>> for better or worse, has usually not deferred to hardware vendor >>> concerns about implementation issues, relying on Moore's law to >>> address these issues over time. Instead, we often focus on software >>> implementation issues. >>> >>> I don't understand the reference to "best common practice .." above. >>> >>> Extending ESP was never seriously considered. No I-Ds on the topic >>> were ever published. There was considerable sentiment that making one >>> protocol (ESP) more complex as a means to avoid the need to implement >>> another protocol (AH) was not going to result in an overall simpler >>> system. I think this sentiment is accurate and persists today. >>> >>> > >>> >The arguments for AH: >>> > >>> >I) the document was already written and we are in a hurry because IPSEC >>> >can not happen until docs went to PS >>> >>> I believe the IETF meeting I referred to took place well before we >>> submitted 2401 as an RFC, so this argument seems a bit out of sync. >>> >>> >II)there are existing/working implementations >>> >>> true >>> >>> >III) and my favorite - and I paraphrase - this AH issue was already >>> >discussed, and most experts agree that AH was something akin to >>> >unnecessary/botch/etc., but since the pesky critter was still in the doc >>> >we needed to move on. It could be fixed at DS or later. >>> >>> I don't recall that. >>> >>> >IV) AH was the way to say "no data encryption in this packet" to comply >>> >with crypto wary governments. >>> >>> Still true, but given the IAB position on crypto, not a good rationale. >>> >>> > >>> >Jeff Schiller asked me if we/they left AH in the arch doc would >>> >Microsoft build versions of IPSEC without AH? To which I noted that >>> >this was not a proper question for a standards meeting and that for PC >>> >and Server implementations this was less of an issue, but for small >>> >devices (which MS also builds for) it could become a large issue. >>> >>> Unfortunately, my cursory examination of the MS implementation of >>> IPsec for PCs and servers last May revealed that it is not compliant >>> with 2401 anyway, e.g., it fails to provide a means for a user or >>> administrator to order the SPD entries, a very explicit requirement. >>> the lack of this facility makes it hard, if not impossible, for one >>> to determine how the implementation will process traffic. >>> >>> Steve >> >>-- >> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory >> Member, MIT Student Information Processing Board (SIPB) >> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH >> warlord@MIT.EDU PGP key available >> > > > --Steve Bellovin, http://www.research.att.com/~smb > From owner-ipsec@lists.tislabs.com Fri Apr 13 11:05:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA07904; Fri, 13 Apr 2001 11:05:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06388 Fri, 13 Apr 2001 13:16:36 -0400 (EDT) Message-Id: <200104131720.ABY05275@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 13 Apr 2001 10:10:14 -0700 To: "Steven M. Bellovin" , Scott Fluhrer From: Scott Fluhrer Subject: Re: Death to AH (was Re: SA identification) Cc: Derek Atkins , "John Lowry" , "Kopeikin, Roy A (Roy)" , "Stephen Kent" , "Peter Ford" , ipsec@lists.tislabs.com In-Reply-To: <20010413164202.C94E74D97@challenger.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:42 AM 4/13/01 , Steven M. Bellovin wrote: >In message <200104131628.ABY04112@mira-sjcm-3.cisco.com>, Scott Fluhrer writes: >>At 07:52 AM 4/13/01 , Steven M. Bellovin wrote: >>>In message , Derek Atkins writes: >>>>So does ESP with Authentication and NULL-encryption. >>> >>>Yes, but it's not context-free -- unless you know a priori that null >>>encryption is being used, you can't monitor it. >>> >>>This is the one point I'll concede to the AH proponents... >> >>Actually, I wouldn't concede quite so quickly. AH is not context-free >>either -- unless you know a priori that the packet AH is protecting is >>not itself encrypted (e.g. ESP is not being used along with AH), you >>can't monitor it either. > >There's a Next Protocol field in the AH header that you can look at. If all you're interested in is telling if the encapsulated packet is encrypted or not, there are ways to tell with ESP (with possibly null encryption) as well. In tunnel mode, you can check if the bits where the encapsulated IP header would be makes sense as an unencrypted IP header (IP version number is 4 or 6, checksum is valid). In transport mode, you can (usually) check the transport header. Granted, with AH, it's somewhat easier... > > > --Steve Bellovin, http://www.research.att.com/~smb > From owner-ipsec@lists.tislabs.com Mon Apr 16 12:26:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA23541; Mon, 16 Apr 2001 12:26:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16907 Mon, 16 Apr 2001 14:15:46 -0400 (EDT) Date: Thu, 12 Apr 2001 17:46:57 +0200 From: John Wells To: ipsec@lists.tisliabs.com Subject: Changing destination IP address midstream Message-ID: <20010412174657.A8017@goofy.inrialpes.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.15i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello all, I've reviewed the archives a bit, but haven't found any mention of this; sorry if I'm duplicating questions.. Without furthur ado: Is it possible to change the destination IP address of a packet midstream after it has been IPsec'd? I'd prefer to do this rather than resort to tunnelling for a Mobile IPv6 application, likely using Hierarchical Mobile IPv6 to advertise a "remote" care-of address and a "local" care-of address. I realize this will break the Security Association and that I might have to tweak this method a bit to store an unchanging address with the SA, but other than that, would this break anything else such as in AH or ESP? Regards, John -- John WELLS ENSIMAG/3A T萳萩omm/R萻eaux - INRIA Rh賜e-Alpes Virginia Tech MS/Computer Engineering - Networking and Visualization Lab t萳 : 04 76 70 01 86 (en France) : 011 33 4 76 70 01 86 (from the USA) From owner-ipsec@lists.tislabs.com Mon Apr 16 12:26:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA23571; Mon, 16 Apr 2001 12:26:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16917 Mon, 16 Apr 2001 14:16:45 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Thu, 12 Apr 2001 17:08:43 -0600 From: "Hilarie Orman" To: Cc: Subject: Re: IPsec and RTP crypto Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id TAA04207 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It's an application layer issue. Hilarie >>> "Steven M. Bellovin" 04/11/01 07:11PM >>> In message , "Hilarie Orman" writes: >Long ago we implemented this selective use of IPsec by >permitting connections to mix protected and unprotected >traffic. The send and receive interfaces made the level >of protection obvious; the application layer could decide >whether or not to accept data for each received chunk >(all the bytes in a chunk had the same protections). This >allowed password protection, in particular. It didn't seem >(at the time), that IPsec was an impediment to this usage. > How can you do that? It sounds like it would take some very strange layering, since in most stacks TCP ACKs are sent when the data is received, not when it's passed to the application -- and that, in turn, means that the sending host may have discarded some data before it knows if it needs to be sent with a different security level. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Mon Apr 16 13:27:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA27623; Mon, 16 Apr 2001 13:27:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA17464 Mon, 16 Apr 2001 15:37:08 -0400 (EDT) To: ipsec@lists.tislabs.com cc: minutes@ietf.org Subject: Minutes for the IPSEC meeting in Minneapolis From: tytso@mit.edu Phone: (781) 391-3464 Message-Id: Date: Mon, 16 Apr 2001 15:41:43 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IPsec WG Minutes Monday, March 19, 2000 Taken by Barbara Fraser Agenda Bashing IPSEC MIB documents: These documents will be going to wg last call in two weeks. They've been posted for awhile and there has been little or no discussion on them. Ted Ts'o urged those who did have comments to send them in asap. John Iannodis: pointed out that there is a 3GPP draft out that folks might be interested in IPSEC and IPV6 1. Jari Arkko presented the draft on Effects on ICMPv6 on IKE and IPsec Policies. This draft covers a problem with circular icmp traffic. 2. Jari Arkko also presented the draft on Manual SA Configuration for IPv6 Link Local Messages. Analyzed of icmpv6 security implications. Table presented that showed control functions against weak and strong attackers at low and high levels. DoS for weak attackers under higher layer security; man in the middle, spying, and impersonation for all attackers under no higher layer security; identity selection in all situations, if stateful... He presented possible ways to reduce the configuration effort which was about twice the SAs as the number of nodes. Comments: Dan McDonald draft on link shared secret, presented in Adelaide to the v6 group and it could be dragged back up to help with the manual configuration. Steve Kent suggested that we need a more complete story in order to motivate people. We'll need more discussion on the mailing list to see how to proceed with both of these. 3. Tissa Senevirathne presented draft-tsenevir-smpls-doi-00.txt draft-tsenevir-smpls-doi-00.txt draft-tsevevir-smpls-oo.txt MPLS is considered as secure as atm and frame relay but there is no evidence that these aren't being attacked. Currently have multiple encapsulation: foo/IP/IPsec/MPLS/... Payload encapsulation formats differ in that the next header field is not being used. For the SA, they're using IKE over RSVP (no additional control channel needed and a new RSVP object defined) and separate IKE channel (allows scaling, simpler implementation, but may not provide PFS) Comment that MPLS security is not an IP protocol and hence it doesn't belong at the IETF. Tissa replied that this is the sub-IP layer that the IETF is forming. Tissa also said there wasn't much security expertise present in the MPLS wg. Ted said that a similar issue has come up with IPv6 addressing which will be discussed in SAAG. Tissa: is it ok to run IKE over RSVP? Suggested that he raise this question at the SAAG meeting. A. D. Keromytis, On the Use of SCTP with IPsec draft: SCTP is a Transport protocol that supports multiple addresses for source and destination. Covered the issues related to IPsec. SAs will need to be specified by a set of addresses SPD: processing for the entries will have to support sets of addresses IKE Phase 2 IDs: a couple of problems with several solutions which the working group will need to agree on. IKE phase I IDs and certificates: if using certs, it's possible for two hosts to verify each other's addresses with the info in the certificates. Certs will support multiple addresses but they'll need to be handled. The draft makes suggestions about changes to the architecture as well as to IKE. Only a handful of people said they had enough understanding in order to get consensus at this point. Ted asked that A.D. post a clear list of issues to the list for discussion. IPSEC and NAT William Dixon presented draft-stenberg-ipsec-nat-traversal-02 and draft-huttunen-ipsec-esp-in-udp-01. The two groups have been working together to arrive at a consensus proposal. Of course the first question is if people think NAT will even be needed with IPv6. Question: Is the internal IP address being exposed a legitimate security concern? The current draft it can be actively queried by active negotiation, can be discovered by man in the middle; and using discover payload of IP address hash makes IP discoverable passively. UDP encapsulation done during phase 2; encapsulation attribute expanded to allow for new UDP encap option but would like a better answer in son of IKE attribute negotiation; send original real IP address in IKE notify Described what the encapsulation would look like. See draft. What about AH? It gets very messy and the authors would rather have agreement that having IP address info in the header is ok. Keepalives: for the purpose of keeping the NAT mapping alive, it's not the same as the IKE keepalives discussion. The intellectual property issues are resolved so the drafts are moving forward. Question: what about the patent posted in Europe? SSH has one patent and has a new one coming that is about determining if a NAT is present. Request that the patent application be posted to the list. Answer: it's on the IETF web page. Is the reason we have the cookie mechanism to have 1 rather than 2 ports? Answer was yes. New draft with new name will come out in the next couple of weeks. Son of Ike discussion Ted introduced the discussion with the following ground rules: This is to fix bugs in IKE, not an invitation to add arbitrary features. While we may be talking about bumping major versions numbers, there is a lot of installed base so people will be supporting old IKE and new IKE. Changes will need to be implementation preserving. About twice as many folks felt we did need implementation preservation than not. Dan Harkins presented his ideas for Son of IKE Combine the three into a new draft and deprecate the other three. Why? A lot of folks just don't like IKE, unnecessarily long and hard to read. Duplicate verbage in the docs would be eliminated. IKE has received some crypto analysis and no flaws (unlike WEP and PPTP) and there is wide industry acceptance. It does work. Even though it's very flexible, it hasn't been used so the question is are all these layers necessary. To combine them, we lose the layer violations, less ambiguous and more internally consistent, no repeated text. We also lose the general framework. New group mode? aggressive mode? ISakmp exchange... Advancements in the state of the art (out with DES and in with AES); suggestions for protocol improvement can be considered. Discussion: more interoperabiity among deployed systems is a main objective. smb: It will probably simplify the document even though it may not reduce the code base. There is a risk in characterizing the issues. At the last bakeoff there were still a number of IKE issues. Clarity, extensibility. Taro sent the issues to the list after the last bakeoff. The problem is complexity. Refocus by focusing on the state machine and the bulk of the problems will go away. Rewriting will not solve some of the problems so why don't we leave IKE as it is now with a strict set of problems and start over with a new protocol.??? didn't understand this. Concern that if Dan takes out everything that is problematic, there will be problems. Instead, keep it in but add text that says why it's there and what the issues are. AD: even if we did nothing else than clarify the docs we would have done well. Starting over may not be a good idea and we don't have enough people in the room who are developers to be able to determine this today. Reduce some of the choices that nobody uses; discuss the core set of options that folks are really using. There are areas that are underspecified, e.g., negotiating lifetimes. We could document the types of things that are giving us headaches. Keepalives and XAUTH were sort of shoehorned in, but we might be able to solve these problems with better solutions. Ted: There are have been various strawman proposals for heartbeats, birth certificates, death certificates... For some of these narrow areas it might make sense to use multiple IDs to flesh out the ideas and approaches. Once baked it can be incorporated into the new IKE draft. Someone to keep track of all the places where we've made a change from the original IKE. Could be an ID, or an internal working group document. Ted went through the items that were posted to the list in the past couple of days. Comment that SCTP be addressed as a mod to current IKE so that it doesn't get stalled behind the son of IKE work. Suggestion to advance the elliptic curve draft and the config mode draft to solve the IANA number issue? Ted: no wg consensus. Comment suggesting that we look forward when making changes. From owner-ipsec@lists.tislabs.com Tue Apr 17 09:19:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA01429; Tue, 17 Apr 2001 09:19:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20904 Tue, 17 Apr 2001 11:19:49 -0400 (EDT) Date: Mon, 16 Apr 2001 23:23:02 -0700 (PDT) From: Baccouch Hajer Subject: Question about OSCP To: ipsec@lists.tislabs.com Message-id: <4157018.987488582980.JavaMail.Hajer_Baccouch@gomailjtp01> MIME-version: 1.0 X-Mailer: GoMail 3.0.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I know that OSCP is an Outline Server Certificates Protocol but i don't manage to configure it on a subnet. How can i configure it? Thanks. Hajer. ___________________________________________________ GO.com Mail Get Your Free, Private E-mail at http://mail.go.com From owner-ipsec@lists.tislabs.com Tue Apr 17 09:19:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA01456; Tue, 17 Apr 2001 09:19:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20913 Tue, 17 Apr 2001 11:20:49 -0400 (EDT) Message-ID: <20010417110030.7388.qmail@web3101.mail.yahoo.com> Date: Tue, 17 Apr 2001 21:00:30 +1000 (EST) From: =?iso-8859-1?q?David=20Law?= Subject: Re: Minutes for the IPSEC meeting in Minneapolis To: tytso@mit.edu Cc: ipsec@lists.tislabs.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi I was wondering if anybody knows the document number for the 3GPP draft John Iannodis mentioned below. Many Thanks David --- tytso@mit.edu wrote: > > IPsec WG Minutes > Monday, March 19, 2000 > > Taken by Barbara Fraser > > Agenda Bashing > > IPSEC MIB documents: These documents will be going > to wg last call in > two weeks. They've been posted for awhile and there > has been little or > no discussion on them. Ted Ts'o urged those who did > have comments to send > them in asap. > > John Iannodis: pointed out that there is a 3GPP > draft out that folks > might be interested in > > _____________________________________________________________________________ http://movies.yahoo.com.au - Yahoo! Movies - Now showing: Dude Where's My Car, The Wedding Planner, Traffic.. From owner-ipsec@lists.tislabs.com Tue Apr 17 11:25:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA08200; Tue, 17 Apr 2001 11:25:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21802 Tue, 17 Apr 2001 13:35:05 -0400 (EDT) Message-ID: <004101c0c76d$d51ec4a0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "David Law" , Cc: References: <20010417110030.7388.qmail@web3101.mail.yahoo.com> Subject: Re: Minutes for the IPSEC meeting in Minneapolis Date: Tue, 17 Apr 2001 21:40: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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I was wondering if anybody knows the document number > for the 3GPP draft John Iannodis mentioned below. I believe the reference is to this document: http://search.ietf.org/internet-drafts/draft-arkko-map-doi-01.txt This document deals with using ISAKMP/IKE for securing a legacy protocol, MAP, in the 3G architecture. While we are on the subject, you may also be interested to know that the 3GPP is planning to use IPsec in gateways and/or network nodes to secure IP signalling traffic. This deals only with network internal signaling, not the user's traffic. That would be handled end-to-end. One interesting case for that is the IP multimedia service, which is SIP and RTP based. Various ways to introduce security to SIP have been discussed but nothing is decided yet, neither on actual message protection (e.g. PGP, IPsec, S/MIME, ...) nor the authentication. For the authentication part, a desire propably exists to reuse the UMTS secret-key -based authentication scheme due to its low computational costs and availability. For the actual media flows, the first standard releases propably don't mandate security yet. But when they do, a good candidate to run bandwidth efficient and wireless friendly encryption can be found from http://search.ietf.org/internet-drafts/draft-ietf-avt-srtp-00.txt As always, input is appreciated on these and other topics related to the 3rd generation mobile networks. Jari Arkko Ericsson From owner-ipsec@lists.tislabs.com Tue Apr 17 20:25:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA11291; Tue, 17 Apr 2001 20:25:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA24246 Tue, 17 Apr 2001 22:22:01 -0400 (EDT) Message-Id: <200104172243.f3HMhTx04557@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com From: Michael Richardson - IETF mailbox Subject: Re: Minutes for the IPSEC meeting in Minneapolis In-reply-to: Your message of "Mon, 16 Apr 2001 15:41:43 EDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 17 Apr 2001 15:43:29 -0700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "tytso" == tytso writes: tytso> the IETF is forming. Tissa also said there wasn't much security tytso> expertise present in the MPLS wg. Ted said that a similar issue has tytso> come up with IPv6 addressing which will be discussed in SAAG. My feeling is that there are some serious uissues in MPLS involving abilities to do tracing of packets. Given the bandwidths involved, I predict major DOS on end systems via MPLS soon. While this is not an IPsec issue per se, the various claims that MPLS will enable "provider managed VPN to be easy and secure" should be viewed with skepticism. tytso> Tissa: is it ok to run IKE over RSVP? Suggested that he raise this tytso> question at the SAAG meeting. It seems very strange to me. Why would one do that? ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Wed Apr 18 10:29:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA00206; Wed, 18 Apr 2001 10:29:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27254 Wed, 18 Apr 2001 12:08:41 -0400 (EDT) From: Ricky Charlet To: ipsec@lists.tislabs.com Message-ID: <3ADDB08E.1042D8B9@redcreek.com> Date: Wed, 18 Apr 2001 09:19:42 -0600 Organization: Redcreek Communications X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Minutes for the IPSEC meeting in Minneapolis References: <200104172243.f3HMhTx04557@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, I did not see the IPsec related monitor MIBs mentioned in the minutes. Did they come up? What is their status? If IKE is unified into one document and intentionally removes abstraction layers, then should the moinitor MIB drafts also follow the same course? -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec@lists.tislabs.com Wed Apr 18 14:17:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA16476; Wed, 18 Apr 2001 14:17:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01394 Wed, 18 Apr 2001 16:19:59 -0400 (EDT) From: Ricky Charlet To: Tim Jenkins Cc: ipsec@lists.tislabs.com Message-ID: <3ADDEB6B.9F563A0D@redcreek.com> Date: Wed, 18 Apr 2001 13:30:51 -0600 Organization: Redcreek Communications X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Minutes for the IPSEC meeting in Minneapolis References: <522FDAAFD532D511A0AB0002A51390EB2F6962@cat01s2.catena.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tim Jenkins wrote: > > Ricky, > > The MIBs were mentioned as the second item right after agenda bashing, > reproduced here. doh-- > > >IPSEC MIB documents: These documents will be going to wg last call in > >two weeks. They've been posted for awhile and there has been little or > >no discussion on them. Ted Ts'o urged those who did have comments to send > >them in asap. > > The status is that there are a number of minor edits to be done. This will > be done in about two weeks time, at which time they will be re-released, > along with a summary of the latest changes, and will go for last call. > > As for removal of abstraction layers, I have no desire to delay them to do > that. I see no benefit of doing that at this time, since it is intended that > they reflect what needs to be monitored in the context of the existing RFCs. > Thanks Tim. Sounds reasonable to me. -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec@lists.tislabs.com Thu Apr 19 08:05:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA02295; Thu, 19 Apr 2001 08:05:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06140 Thu, 19 Apr 2001 09:52:41 -0400 (EDT) Message-ID: <522FDAAFD532D511A0AB0002A51390EB2F6962@cat01s2.catena.com> From: Tim Jenkins To: "'Ricky Charlet'" , ipsec@lists.tislabs.com Subject: RE: Minutes for the IPSEC meeting in Minneapolis Date: Wed, 18 Apr 2001 14:25:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ricky, The MIBs were mentioned as the second item right after agenda bashing, reproduced here. >IPSEC MIB documents: These documents will be going to wg last call in >two weeks. They've been posted for awhile and there has been little or >no discussion on them. Ted Ts'o urged those who did have comments to send >them in asap. The status is that there are a number of minor edits to be done. This will be done in about two weeks time, at which time they will be re-released, along with a summary of the latest changes, and will go for last call. As for removal of abstraction layers, I have no desire to delay them to do that. I see no benefit of doing that at this time, since it is intended that they reflect what needs to be monitored in the context of the existing RFCs. Tim > -----Original Message----- > From: Ricky Charlet [mailto:rcharlet@redcreek.com] > Sent: Wednesday, April 18, 2001 11:20 AM > To: ipsec@lists.tislabs.com > Subject: Re: Minutes for the IPSEC meeting in Minneapolis > > > Howdy, > > I did not see the IPsec related monitor MIBs mentioned > in the minutes. > Did they come up? What is their status? If IKE is unified into one > document and intentionally removes abstraction layers, then should the > moinitor MIB drafts also follow the same course? > > > -- > Ricky Charlet : Redcreek Communications : usa (510) 795-6903 > From owner-ipsec@lists.tislabs.com Thu Apr 19 12:11:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA21822; Thu, 19 Apr 2001 12:11:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07199 Thu, 19 Apr 2001 13:49:42 -0400 (EDT) Message-ID: <20010419175359.29544.qmail@web10505.mail.yahoo.com> Date: Thu, 19 Apr 2001 10:53:59 -0700 (PDT) From: kris FALKOWSKI Subject: mib To: TJenkins@Catena.com Cc: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tim; I don't have many experiences with IPSEC MIB so let me ask a few questions. First: In IPSEC monitoring MIB there are many times reference like this: ""The value is taken directly from the optional ID payloads that are exchanged during phase 2 negotiations"". In any references like RFC and Doraswamy/Harkins book - ID payloads are not optional. Could you comment? Second. The tables for IKE monitoring MIB drafts are very entangled and complicated. Could you offer me some guidance why there are so many methods and options to search for SA and how practically I can understand all this. Thank You, Sincerely Kris Falkowski __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From owner-ipsec@lists.tislabs.com Thu Apr 19 12:16:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA21929; Thu, 19 Apr 2001 12:16:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07298 Thu, 19 Apr 2001 14:25:00 -0400 (EDT) X-Apparently-From: Message-ID: <007001c0c8ff$d4423ba0$c783c7cb@vsnl.net.in> From: "Anuradha Pillai" To: "ipsec" Subject: two questions. Date: Fri, 20 Apr 2001 00:07:43 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01C0C92D.EBE2E240" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_006D_01C0C92D.EBE2E240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all ! I'm a student trying to implement ipsec using ESP ( bump-in-stack) with = manual SA & Key management. i had following doubts.... --> how do 2 hosts wanting to use ipsec decide on the SPI (manual SA)? both the user choose common SPI, selector, keys & fill them into = the ipsec Database? basically, the confusion arised when considering the inbound = packet processing. the sender fills in the ESP header which contains the SPI. so the = receiver checks the SPI ( & ofcourse the dest addr & protocol )& decides which SA to use. = so does that mean both the SPI number (at sending & receiving host) has to be same? --> why is it necessary to perform fragmentation/reassembly? or rather, = why is ipsec applied to whole datagrams only? any help will be greatly appreciated. i'm sorry if i'm repeating = questions, but i couldn't really find a satisfactory answer to the above... thanking in anticipation... -Anu. ------=_NextPart_000_006D_01C0C92D.EBE2E240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all !
I'm a student trying to implement = ipsec using=20 ESP ( bump-in-stack) with manual SA & Key management.
i = had following=20 doubts....
--> how do 2 hosts wanting to use = ipsec decide=20 on the SPI (manual SA)?
      both the user = choose=20 common SPI, selector, keys & fill them into the ipsec=20 Database?
      basically, the confusion = arised when=20 considering the inbound packet = processing.
      the=20 sender fills in the ESP header which contains the SPI. so the receiver = checks=20 the SPI
      ( & ofcourse the dest addr = &=20 protocol )& decides which SA to use. so does that=20 mean
      both the SPI number (at sending = &=20 receiving host) has to be same?
--> why is it necessary to perform = fragmentation/reassembly? or rather, why is ipsec=20 applied
      to whole datagrams = only?
 
any help will be greatly appreciated. = i'm sorry if=20 i'm repeating questions, but i couldn't really
find a satisfactory answer to the=20 above...
thanking in = anticipation...
-Anu.
 
------=_NextPart_000_006D_01C0C92D.EBE2E240-- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ipsec@lists.tislabs.com Thu Apr 19 12:32:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA22747; Thu, 19 Apr 2001 12:32:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07502 Thu, 19 Apr 2001 14:50:07 -0400 (EDT) Message-Id: <200104191854.f3JIsQ915853@thunk.east.sun.com> From: Bill Sommerfeld To: "Anuradha Pillai" cc: "ipsec" Subject: Re: two questions. In-reply-to: Your message of "Fri, 20 Apr 2001 00:07:43 +0530." <007001c0c8ff$d4423ba0$c783c7cb@vsnl.net.in> Reply-to: sommerfeld@East.Sun.COM Date: Thu, 19 Apr 2001 14:54:26 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Hi all ! > I'm a student trying to implement ipsec using ESP ( bump-in-stack) with = > manual SA & Key management. > i had following doubts.... > --> how do 2 hosts wanting to use ipsec decide on the SPI (manual SA)? receiver/owner of the destination address picks the spi, communicates it to the sender (either manually or through a key management protocol). the spi value is different in each direction. From owner-ipsec@lists.tislabs.com Fri Apr 20 09:41:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA23871; Fri, 20 Apr 2001 09:41:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10370 Fri, 20 Apr 2001 11:31:02 -0400 (EDT) Message-ID: <522FDAAFD532D511A0AB0002A51390EB2F6974@cat01s2.catena.com> From: Tim Jenkins To: "'kris FALKOWSKI'" Cc: ipsec@lists.tislabs.com Subject: RE: mib Date: Thu, 19 Apr 2001 16:39:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: kris FALKOWSKI [mailto:kfalkowski@yahoo.com] > Sent: Thursday, April 19, 2001 1:54 PM > To: TJenkins@Catena.com > Cc: ipsec@lists.tislabs.com > Subject: mib > > > Tim; > I don't have many experiences with IPSEC MIB so let me > ask a few questions. > First: In IPSEC monitoring MIB there are many times > reference like this: ""The value is taken directly > from the optional ID payloads that are exchanged > during phase 2 negotiations"". In any references like > RFC and Doraswamy/Harkins book - ID payloads are not > optional. Could you comment? RFC 2409 states that the IDs used in quick mode are optional. That is the basis for those statements. (Look on page 18 near the middle of the page.) > Second. > The tables for IKE monitoring MIB drafts are very > entangled and complicated. Could you offer me some > guidance why there are so many methods and options to > search for SA and how practically I can understand all > this. The reason why there are so many ways to look up SAs is that there are many ways that people might be interested in seeing how SAs are being created or used. That's why so many helper tables were included. Since the RFCs on which the MIBs are based is application independent, the MIBs are also application independent, but at the same time make an attempt to assist application specific uses of IPsec. The text to explain the inter-relationships between the MIB tables has undergone numerous changes since the initial version. At this point, unless there's something specific which isn't clear, I don't how I can help clarify those relationships. Note that part of the reason for the relationships is due to the relationships of IKE to ISAKMP to IPsec SAs. Perhaps if for each of the helper tables you try think of a use for them, it might help you to understand why they are there. For example, selectorTable lets you sort the SAs based on selectors. This would be useful to see what SAs a particular type of traffic would put be put through or is being put through. The use for this is in a VPN application or for remote access, for example. > Thank You, > Sincerely > Kris Falkowski > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Auctions - buy the things you want at great prices > http://auctions.yahoo.com/ > From owner-ipsec@lists.tislabs.com Fri Apr 20 12:13:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA02899; Fri, 20 Apr 2001 12:13:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10938 Fri, 20 Apr 2001 14:04:56 -0400 (EDT) Message-ID: <3AE07A90.8F94DE54@lucent.com> Date: Fri, 20 Apr 2001 11:06:09 -0700 From: Emmanuel Hislen Organization: Lucent Technologies INS X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Tim Jenkins CC: ipsec@lists.tislabs.com Subject: Re: mib References: <522FDAAFD532D511A0AB0002A51390EB2F6974@cat01s2.catena.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am also a recent reader of this MIB, and have various questions. Forgive me if this has already been discussed, I am also a recent subscriber to this mailing list... 1. SA definition. I kow everywhere it is said that one of the three keys to identify an SA is an IP destination address: It makes little sense to me. The meaning of "destination" is different depending on wether we deal with an inbound or outbound SA. For an outbound SA, the destination address is actually the right key. For an inbound SA, the IP address wich allows us to uniquely identify an SA, along with the SPI and the protocol, is the SOURCE IP address. There is no reason why two remote peers would not allocate the same SPI. RFCs make this confusing. 2. Shouldn't the selectors table be divided into inbound and outbound selectors? I can see you chose "local" and "remote" rather than "source" and "destination" to make a SelectorEntry generic. But what is the idea here? Do you implicitely consider that the inbound and outbound selectors of a given SA are symmetric, that is you just swap destination and source for IP addresses and Port numbers? 3. My understanding is that Inbound and Outbound SAs provided by a single Phase 2 negotiation only differ by their Key (because they have different SPIs). Everything else is identical: same IPSEC protocol, same transform, same lifetime, and the selectors are symmetric. Is this correct? If yes does it still make sense to have inbound and outbound SA tables? Also if yes, I never understood how the lifetime in kiloBytes is working: I mean is it applied to each SA or to both SAs together (inbound + outbound traffic). Sorry for asking so many questions at once... Any light you can shed on any of these issues woud be greatly appreciated. Thanks & Regards, Emmanuel Hislen. Tim Jenkins wrote: > > -----Original Message----- > > From: kris FALKOWSKI [mailto:kfalkowski@yahoo.com] > > Sent: Thursday, April 19, 2001 1:54 PM > > To: TJenkins@Catena.com > > Cc: ipsec@lists.tislabs.com > > Subject: mib > > > > > > Tim; > > I don't have many experiences with IPSEC MIB so let me > > ask a few questions. > > First: In IPSEC monitoring MIB there are many times > > reference like this: ""The value is taken directly > > from the optional ID payloads that are exchanged > > during phase 2 negotiations"". In any references like > > RFC and Doraswamy/Harkins book - ID payloads are not > > optional. Could you comment? > > RFC 2409 states that the IDs used in quick mode are optional. That is the > basis for those statements. (Look on page 18 near the middle of the page.) > > > Second. > > The tables for IKE monitoring MIB drafts are very > > entangled and complicated. Could you offer me some > > guidance why there are so many methods and options to > > search for SA and how practically I can understand all > > this. > > The reason why there are so many ways to look up SAs is that there are many > ways that people might be interested in seeing how SAs are being created or > used. That's why so many helper tables were included. Since the RFCs on > which the MIBs are based is application independent, the MIBs are also > application independent, but at the same time make an attempt to assist > application specific uses of IPsec. > > The text to explain the inter-relationships between the MIB tables has > undergone numerous changes since the initial version. At this point, unless > there's something specific which isn't clear, I don't how I can help clarify > those relationships. Note that part of the reason for the relationships is > due to the relationships of IKE to ISAKMP to IPsec SAs. > > Perhaps if for each of the helper tables you try think of a use for them, it > might help you to understand why they are there. For example, selectorTable > lets you sort the SAs based on selectors. This would be useful to see what > SAs a particular type of traffic would put be put through or is being put > through. The use for this is in a VPN application or for remote access, for > example. > > > Thank You, > > Sincerely > > Kris Falkowski > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Auctions - buy the things you want at great prices > > http://auctions.yahoo.com/ > > -- Emmanuel Hislen Lucent Technologies mailto:hislen@lucent.com From owner-ipsec@lists.tislabs.com Mon Apr 23 13:45:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA24846; Mon, 23 Apr 2001 13:45:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA18136 Mon, 23 Apr 2001 15:15:23 -0400 (EDT) Message-ID: <3AE48059.8C57B476@lucent.com> Date: Mon, 23 Apr 2001 12:19:53 -0700 From: Emmanuel Hislen Organization: Lucent Technologies INS 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 Subject: Misc. issues: Inbound SA triple identification / Inbound&Outbound SA, selectors exchange Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, After reading most IPSEC related RFCs and various books, and discussing with many people, I am still bumping on the following issues. Hopefully some of you have already been though these questions and can give me some hints or a different point of view. 1. SA definition (RFC 2401, section 4.1, p. 8). In most places it is said that one of the three keys to identify an SA is the IP destination address: but he meaning of "destination" is different depending on wether we deal with an inbound or outbound SA. For an outbound SA, the destination address is actually the right key. For an inbound SA, the IP address wich allows us to uniquely identify an SA, along with the SPI and the protocol, is the SOURCE IP address. There is no reason why two remote peers would not allocate the same SPI. I'd say we even need to consider the source IP address of the cryptographic endpoint: in tunnel mode we need to know the IP address of the IPSEC tunnel endpoint in order to uniquely identify the SA for an incoming packet. Is this correct? 2. My understanding is that Inbound and Outbound SAs derived from a single Phase 2 negotiation only differ by their Key (because they have different SPIs). Everything else is identical: same IPSEC protocol, same transform, same lifetime, and the selectors are symmetric. Is this correct? If yes I never understood how the lifetime in kiloBytes is working: I mean is it applied to each SA or to both SAs together (inbound + outbound traffic). 3. Policy Decisions/Selectors/ID Payloads ID payloads are used to pass selectors from Initiator to responder in a Phase 2 exchange. ID payloads are optional in Quick mode: does this mean that when they are not included this is a request to establish an SA for ALL traffic between the ISAKMP peers? What about Phase 1 SAs? Port and Protocol fields are set to 0 in ID payloads of a Phase 1 exchange. RFC 2408 (section 2.3 p. 16) says two ISAKMP peers "can" negotiate (and have active) multiple ISAKMP SAs. Is this something each implementation MUST or MAY support?? How does each peer decide to use one IKE SA rather than another one? Sorry for asking so many questions at once... Any light you can shed on any of these issues would be greatly appreciated!!! Thanks & Regards, Emmanuel Hislen. -- Emmanuel Hislen Lucent Technologies INS From owner-ipsec@lists.tislabs.com Mon Apr 23 14:26:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA28860; Mon, 23 Apr 2001 14:26:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA18248 Mon, 23 Apr 2001 16:13:21 -0400 (EDT) Message-Id: <200104232017.f3NKHk924973@thunk.east.sun.com> From: Bill Sommerfeld To: Emmanuel Hislen cc: ipsec@lists.tislabs.com Subject: Re: Misc. issues: Inbound SA triple identification / Inbound&Outbound SA, selectors exchange In-reply-to: Your message of "Mon, 23 Apr 2001 12:19:53 PDT." <3AE48059.8C57B476@lucent.com> Reply-to: sommerfeld@East.Sun.COM Date: Mon, 23 Apr 2001 16:17:46 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > For an outbound SA, the destination address is actually the right key. > > For an inbound SA, the IP address wich allows us to uniquely identify an > SA, along with the SPI and the protocol, is the SOURCE IP address. There > is no reason why two remote peers would not allocate the same SPI. I'd > say we even need to consider the source IP address of the cryptographic > endpoint: in tunnel mode we need to know the IP address of the IPSEC > tunnel endpoint in order to uniquely identify the SA for an incoming > packet. > > Is this correct? No. The receiver is responsible for allocating unique SPI values and communicating them to the sender. - Bill From owner-ipsec@lists.tislabs.com Mon Apr 23 15:04:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA00987; Mon, 23 Apr 2001 15:04:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA18496 Mon, 23 Apr 2001 17:05:08 -0400 (EDT) Message-ID: <3AE49A1E.FBDDF409@lucent.com> Date: Mon, 23 Apr 2001 14:09:50 -0700 From: Emmanuel Hislen Organization: Lucent Technologies INS X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sommerfeld@East.Sun.COM CC: ipsec@lists.tislabs.com Subject: Re: Misc. issues: Inbound SA triple identification / Inbound&Outbound SA, selectors exchange References: <200104232017.f3NKHk924973@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill Sommerfeld wrote: > > For an outbound SA, the destination address is actually the right key. > > > > For an inbound SA, the IP address wich allows us to uniquely identify an > > SA, along with the SPI and the protocol, is the SOURCE IP address. There > > is no reason why two remote peers would not allocate the same SPI. I'd > > say we even need to consider the source IP address of the cryptographic > > endpoint: in tunnel mode we need to know the IP address of the IPSEC > > tunnel endpoint in order to uniquely identify the SA for an incoming > > packet. > > > > Is this correct? > > No. The receiver is responsible for allocating unique SPI values and > communicating them to the sender. > > - Bill Thanks for the fast answer! I now understand what I missed in the RFC: "The SPI chosen by the destination of the SA is used to derive KEYMAT for that SA". I just thought it was the contrary... So for an incoming IPSEC packet, the SPI is the one that was allocated locally. Still I do not get it: why should we use the destination address from the outer IP header for a lookup in our SAD?? We ARE the destination, this is no information!! I see 2 possibilities: - we allocated the SPI, so if we made it unique "system-wide" for the current protocol, we do not even need any IP address information to find the SA. - we allocated the SPI but we only guarantee it is unique for the current remote peer and the current protocol. Then we need to make a lookup based on the Source IP address of the incoming packet (and the protocol, and the SPI of course). Is this better??? Thanks again, Emmanuel. -- Emmanuel Hislen Lucent Technologies INS From owner-ipsec@lists.tislabs.com Mon Apr 23 15:14:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA02151; Mon, 23 Apr 2001 15:14:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA18535 Mon, 23 Apr 2001 17:23:41 -0400 (EDT) Message-Id: <200104232127.f3NLRD925275@thunk.east.sun.com> From: Bill Sommerfeld To: Emmanuel Hislen cc: ipsec@lists.tislabs.com Subject: Re: Misc. issues: Inbound SA triple identification / Inbound&Outbound SA, selectors exchange In-reply-to: Your message of "Mon, 23 Apr 2001 14:09:50 PDT." <3AE49A1E.FBDDF409@lucent.com> Reply-to: sommerfeld@East.Sun.COM Date: Mon, 23 Apr 2001 17:27:13 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I now understand what I missed in the RFC: "The SPI chosen by the destination > of the SA is used to derive KEYMAT for that SA". I just thought it was the > contrary... > > So for an incoming IPSEC packet, the SPI is the one that was allocated > locally. Still I do not get it: why should we use the destination address > from the outer IP header for a lookup in our SAD?? This was discussed recently in this WG; this may change in a future version of the spec. The one answer which seemed to "stick" best is "Multicast". That said, there's nothing stopping an implementation today from doing as you described and allocating unique SPI's for unicast addresses from a space shared across all its destination addresses. - Bill From owner-ipsec@lists.tislabs.com Tue Apr 24 11:12:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA05818; Tue, 24 Apr 2001 11:12:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA22054 Tue, 24 Apr 2001 13:07:39 -0400 (EDT) Message-ID: <4652644B98DFF34696801F8F3070D3FE04B486@D2CSPEXM001.smartpipes.com> From: "Jain, Gautam" To: "'ipsec@lists.tislabs.com'" Subject: tunnle mode SAs... Date: Tue, 24 Apr 2001 17:11:49 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk With reference to section 4.1 in RFC 2401 I have a question on the following statement. 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. How does a tunnel mode SA avoid the fragmentation problem and why is a transport mode SA a problem if there exist multiple paths to the same destination behind the security gateways ? gautam From owner-ipsec@lists.tislabs.com Tue Apr 24 11:12:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA05842; Tue, 24 Apr 2001 11:12:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA22028 Tue, 24 Apr 2001 13:03:59 -0400 (EDT) Message-ID: <4652644B98DFF34696801F8F3070D3FE04B485@D2CSPEXM001.smartpipes.com> From: "Jain, Gautam" To: "'ipsec@lists.tislabs.com'" Subject: allowing transport mode... Date: Tue, 24 Apr 2001 17:08:08 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk With reference to section 4.1 in RFC 2401 I have a question on the following statement. Note that for the case where traffic is destined for a security gateway, e.g., SNMP commands, the security gateway is acting as a host and transport mode is allowed. What is the rationale behind allowing transport mode in case of one of the peers being a security gateway. One seems to be network management. What others would allow a security gateway to act as a host in the ipsec world. If we were to collectively ( instead of identifying applications that allow this ) say, what would we the bottomline for allowing transport mode in case of a security gateway acting as a host in IPSec. gautam From owner-ipsec@lists.tislabs.com Tue Apr 24 13:47:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA17786; Tue, 24 Apr 2001 13:47:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA22579 Tue, 24 Apr 2001 15:50:59 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3AE48059.8C57B476@lucent.com> References: <3AE48059.8C57B476@lucent.com> Date: Tue, 24 Apr 2001 15:51:22 -0400 To: Emmanuel Hislen From: Stephen Kent Subject: Re: Misc. issues: Inbound SA triple identification / Inbound&Outbound SA, selectors exchange Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:19 PM -0700 4/23/01, Emmanuel Hislen wrote: >Hi, > >After reading most IPSEC related RFCs and various books, and discussing >with many people, I am still bumping on the following issues. Hopefully >some of you have already been though these questions and can give me >some hints or a different point of view. > >1. >SA definition (RFC 2401, section 4.1, p. 8). >In most places it is said that one of the three keys to identify an SA >is the IP destination address: but he meaning of "destination" is >different depending on wether we deal with an inbound or outbound SA. The discussion in 4.1 refers only to inbound traffic that has been IPsec protected, and thus carries an SPI. Outbound traffic (not yet IPsec processed by the device in question) has no SPI (applied by this IPsec device). > >For an outbound SA, the destination address is actually the right key. For outbound traffic, SPD entries specify the "keys" used to map traffic to SAs and there are 5 different types of packet selectors, as described in 4.4.2. >For an inbound SA, the IP address wich allows us to uniquely identify an >SA, along with the SPI and the protocol, is the SOURCE IP address. There >is no reason why two remote peers would not allocate the same SPI. I'd >say we even need to consider the source IP address of the cryptographic >endpoint: in tunnel mode we need to know the IP address of the IPSEC >tunnel endpoint in order to uniquely identify the SA for an incoming >packet. > >Is this correct? No. For unicast SAs, the SPI is allocated by the target of the SA and thus need be only locally unique. The dest Ip address is needed to differentiate among SAs only to accommodate multicast, where the SPI is assigned by the multicast controller. Steve From owner-ipsec@lists.tislabs.com Tue Apr 24 22:04:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA14403; Tue, 24 Apr 2001 22:04:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA23556 Wed, 25 Apr 2001 00:02:33 -0400 (EDT) From: Renu Agarwal To: "Jain, Gautam" Cc: "'ipsec@lists.tislabs.com'" Message-ID: <3AE64DA4.A9272C68@globespan.net> Date: Wed, 25 Apr 2001 09:38:04 +0530 Organization: Globespan India Pvt Ltd., X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: allowing transport mode... References: <4652644B98DFF34696801F8F3070D3FE04B485@D2CSPEXM001.smartpipes.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Jain, Gautam" wrote: > With reference to section 4.1 in RFC 2401 I have a question on the following > statement. > > Note that for the case where traffic is destined for a > security gateway, e.g., SNMP commands, the security gateway is acting > as a host and transport mode is allowed. > > What is the rationale behind allowing transport mode in case > of one of the peers being a security gateway. One seems to be > network management. What others would allow a security gateway > to act as a host in the ipsec world. If we were to collectively ( instead of > identifying > applications that allow this ) say, what would we the bottomline > for allowing transport mode in case of a security gateway acting > as a host in IPSec. > > gautam If the security gateway is running an application over IP then it should use the transport mode for all packets orginating /destined for those applications. The applications could be anything like FTP, TFTP including any proprietary application running on the securtiy gateway. Hope it answers your question, Renu -- __________________________________________________________ Renu Agarwal Globespan Inc. E-mail: mailto:ragarwal@globespan.net Web : http://www.globespan.net __________________________________________________________ ******************Legal Disclaimer************************** "This email message is for the sole use of the intended recipient(s) and may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender by reply email. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of GLOBESPAN, INC. or any of its subsidiaries." **************************************************************** From owner-ipsec@lists.tislabs.com Wed Apr 25 06:33:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA29489; Wed, 25 Apr 2001 06:33:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24892 Wed, 25 Apr 2001 08:00:07 -0400 (EDT) Date: Wed, 25 Apr 2001 08:03:37 -0400 From: Ramin Alidousti To: Renu Agarwal Cc: "Jain, Gautam" , "'ipsec@lists.tislabs.com'" Subject: Re: allowing transport mode... Message-ID: <20010425080336.A18508@UU.NET> References: <4652644B98DFF34696801F8F3070D3FE04B485@D2CSPEXM001.smartpipes.com> <3AE64DA4.A9272C68@globespan.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: <3AE64DA4.A9272C68@globespan.net>; from ragarwal@globespan.net on Wed, Apr 25, 2001 at 09:38:04AM +0530 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Apr 25, 2001 at 09:38:04AM +0530, Renu Agarwal wrote: > "Jain, Gautam" wrote: > > If the security gateway is running an application over IP then it should > use the transport mode for all packets orginating /destined for those > applications. The applications could be anything like FTP, TFTP including > any proprietary application running on the securtiy gateway. Is it a must that one should use transport mode for the security gateway which is running an application or does one have a choice in this case to use either modes? Ramin > > Hope it answers your question, > > Renu > > > -- > __________________________________________________________ > Renu Agarwal > Globespan Inc. > > E-mail: mailto:ragarwal@globespan.net > Web : http://www.globespan.net > __________________________________________________________ > > > > ******************Legal Disclaimer************************** > "This email message is for the sole use of the intended recipient(s) and may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender by reply email. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of GLOBESPAN, INC. or any of its subsidiaries." > **************************************************************** From owner-ipsec@lists.tislabs.com Wed Apr 25 08:00:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA03134; Wed, 25 Apr 2001 07:59:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29250 Wed, 25 Apr 2001 09:22:52 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <4652644B98DFF34696801F8F3070D3FE04B486@D2CSPEXM001.smartpipes.com> References: <4652644B98DFF34696801F8F3070D3FE04B486@D2CSPEXM001.smartpipes.com> Date: Wed, 25 Apr 2001 09:29:26 -0400 To: "Jain, Gautam" From: Stephen Kent Subject: Re: tunnle mode SAs... Cc: "'ipsec@lists.tislabs.com'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 5:11 PM +0000 4/24/01, Jain, Gautam wrote: >With reference to section 4.1 in RFC 2401 I have a question on the >following statement. > >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. > >How does a tunnel mode SA avoid the fragmentation problem and why >is a transport mode SA a problem if there exist multiple paths to the >same destination behind the security gateways ? In tunnel mode packets are addressed to a single target SG, thus ensuring that all fragments arrive at one point, where they can be reassembled. In transport mode, the address of the ultimate target, not the SG, would allow traffic, including fragments, on one SA to be routed to different SGs, and this would preclude reassembly at an intermediate SG. Steve From owner-ipsec@lists.tislabs.com Wed Apr 25 08:31:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA04072; Wed, 25 Apr 2001 08:31:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29676 Wed, 25 Apr 2001 09:39:08 -0400 (EDT) Message-ID: From: Chris Trobridge To: Ramin Alidousti , Renu Agarwal Cc: "Jain, Gautam" , "'ipsec@lists.tislabs.com'" Subject: RE: allowing transport mode... Date: Wed, 25 Apr 2001 14:44:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You don't have to use transport mode at all, according to the RFC. In fact sometimes you have to use tunnel mode, eg when the service is being accessed by non-IPSEC client behind an IPSEC gateway. CL <--> SGW1 <===> SGW2 When the Client accesses, eg, an FTP server on SGW2 the path between SGW1 and SGW2 must be protected by tunnel mode. (Well unless the access is via a proxy on SGW1...) Chris > -----Original Message----- > From: Ramin Alidousti [mailto:ramin@uu.net] > Sent: 25 April 2001 13:04 > To: Renu Agarwal > Cc: Jain, Gautam; 'ipsec@lists.tislabs.com' > Subject: Re: allowing transport mode... > > > On Wed, Apr 25, 2001 at 09:38:04AM +0530, Renu Agarwal wrote: > > > "Jain, Gautam" wrote: > > > > If the security gateway is running an application over IP > then it should > > use the transport mode for all packets orginating /destined > for those > > applications. The applications could be anything like FTP, > TFTP including > > any proprietary application running on the securtiy gateway. > > Is it a must that one should use transport mode for the > security gateway > which is running an application or does one have a choice in > this case to > use either modes? > > Ramin > > > > > Hope it answers your question, > > > > Renu > > > > > > -- > > __________________________________________________________ > > Renu Agarwal > > Globespan Inc. > > > > E-mail: mailto:ragarwal@globespan.net > > Web : http://www.globespan.net > > __________________________________________________________ > > > > > > > > ******************Legal Disclaimer************************** > > "This email message is for the sole use of the intended > recipient(s) and may contain confidential, proprietary or > legally privileged information. No confidentiality or > privilege is waived or lost by any mistransmission. If you > receive this message in error, please immediately delete it > and all copies of it from your system, destroy any hard > copies of it and notify the sender by reply email. You must > not, directly or indirectly, use, disclose, distribute, > print, or copy any part of this message if you are not the > intended recipient. Any views expressed in this message are > those of the individual sender, except where the message > states otherwise and the sender is authorised to state them > to be the views of GLOBESPAN, INC. or any of its subsidiaries." > > **************************************************************** > > > This footnote confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From owner-ipsec@lists.tislabs.com Wed Apr 25 10:23:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA09936; Wed, 25 Apr 2001 10:23:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00585 Wed, 25 Apr 2001 12:20:23 -0400 (EDT) Message-ID: <3AE6FA9D.A868D19F@certicom.com> Date: Wed, 25 Apr 2001 12:26:05 -0400 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Chris Trobridge CC: Stephen Kent , "Jain, Gautam" , "'ipsec@lists.tislabs.com'" Subject: Re: tunnle mode SAs... References: <1D43F5BAFBD6459D85256A390055FCCD.0056227D85256A39@certicom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk No, I don't think there is a problem, you can always tell to which packet a particular fragment belongs. If so, you can always tell what port/protocol you have to use. Normally, on inboud you should collect all fragments before decryption or any security policy check, otherwise you would have to maintain a state - I don't know why you would do it. Any particular reason? On outbound 1. - fragment a packet - encrypt each fragment or 2. - encrypt a packet - fragment a packet On inbound 1. - dencrypt each fragment - defragment a packet or 2. - defragment a packet - dencrypt a packet The second case (2), I think, is used more often. You should handle both cases if you want to cover all situations. -Yuri Chris Trobridge wrote: > > I thought the problem was to do with inbound policy processing. > > If a packet is fragmented before encryption then you can't tell the > protocol/ports/whatever of the later fragments when they're decoded (I > suppose this is a problem outbound too). > > Transport mode is end-to-end, so why would intermediates get involved? > > I think fragmenting the ciphertext is ok, in principle, but fragmenting > plaintext datagrams prevents gateways from processing policy. > > Chris > > > -----Original Message----- > > From: Stephen Kent [mailto:kent@bbn.com] > > Sent: 25 April 2001 14:29 > > To: Jain, Gautam > > Cc: 'ipsec@lists.tislabs.com' > > Subject: Re: tunnle mode SAs... > > > > > > At 5:11 PM +0000 4/24/01, Jain, Gautam wrote: > > >With reference to section 4.1 in RFC 2401 I have a question on the > > >following statement. > > > > > >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. > > > > > >How does a tunnel mode SA avoid the fragmentation problem and why > > >is a transport mode SA a problem if there exist multiple paths to the > > >same destination behind the security gateways ? > > > > In tunnel mode packets are addressed to a single target SG, thus > > ensuring that all fragments arrive at one point, where they can be > > reassembled. In transport mode, the address of the ultimate target, > > not the SG, would allow traffic, including fragments, on one SA to be > > routed to different SGs, and this would preclude reassembly at an > > intermediate SG. > > > > Steve > > > > > > > > > > This footnote confirms that this email message has been swept by > > MIMEsweeper for the presence of computer viruses. > > > > ----------------------------------------------------------------------------------------------------------------- > The information contained in this message is confidential and is intended > for the addressee(s) only. If you have received this message in error or > there are any problems please notify the originator immediately. The > unauthorized use, disclosure, copying or alteration of this message is > strictly forbidden. Baltimore Technologies plc will not be liable for > direct, > special, indirect or consequential damages arising from alteration of the > contents of this message by a third party or as a result of any virus being > passed on. > > In addition, certain Marketing collateral may be added from time to time to > promote Baltimore Technologies products, services, Global e-Security or > appearance at trade shows and conferences. > > This footnote confirms that this email message has been swept by > Baltimore MIMEsweeper for Content Security threats, including > computer viruses. From owner-ipsec@lists.tislabs.com Wed Apr 25 10:50:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA12317; Wed, 25 Apr 2001 10:50:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00684 Wed, 25 Apr 2001 12:56:48 -0400 (EDT) Message-Id: <200104251652.f3PGqBx42590@potassium.cips.nokia.com> To: Yuri Poeluev cc: Chris Trobridge , Stephen Kent , "Jain, Gautam" , "'ipsec@lists.tislabs.com'" Subject: Re: tunnle mode SAs... In-Reply-To: Your message of "Wed, 25 Apr 2001 12:26:05 EDT." <3AE6FA9D.A868D19F@certicom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42587.988217531.1@potassium.cips.nokia.com> Date: Wed, 25 Apr 2001 09:52:11 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 25 Apr 2001 12:26:05 EDT you wrote > > On inbound > 1. - dencrypt each fragment > - defragment a packet > or > 2. - defragment a packet > - dencrypt a packet > > The second case (2), I think, is used more often. > You should handle both cases if you want to cover all situations. I don't think 1 is possible. We authenticate encrypted packets and you must reconstruct the entire packet before you can authenticate it. Dan. From owner-ipsec@lists.tislabs.com Wed Apr 25 11:05:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA12632; Wed, 25 Apr 2001 11:05:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00407 Wed, 25 Apr 2001 11:12:14 -0400 (EDT) Message-ID: From: Chris Trobridge To: Stephen Kent , "Jain, Gautam" Cc: "'ipsec@lists.tislabs.com'" Subject: RE: tunnle mode SAs... Date: Wed, 25 Apr 2001 16:17:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I thought the problem was to do with inbound policy processing. If a packet is fragmented before encryption then you can't tell the protocol/ports/whatever of the later fragments when they're decoded (I suppose this is a problem outbound too). Transport mode is end-to-end, so why would intermediates get involved? I think fragmenting the ciphertext is ok, in principle, but fragmenting plaintext datagrams prevents gateways from processing policy. Chris > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: 25 April 2001 14:29 > To: Jain, Gautam > Cc: 'ipsec@lists.tislabs.com' > Subject: Re: tunnle mode SAs... > > > At 5:11 PM +0000 4/24/01, Jain, Gautam wrote: > >With reference to section 4.1 in RFC 2401 I have a question on the > >following statement. > > > >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. > > > >How does a tunnel mode SA avoid the fragmentation problem and why > >is a transport mode SA a problem if there exist multiple paths to the > >same destination behind the security gateways ? > > In tunnel mode packets are addressed to a single target SG, thus > ensuring that all fragments arrive at one point, where they can be > reassembled. In transport mode, the address of the ultimate target, > not the SG, would allow traffic, including fragments, on one SA to be > routed to different SGs, and this would preclude reassembly at an > intermediate SG. > > Steve > > > > > This footnote confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From owner-ipsec@lists.tislabs.com Wed Apr 25 12:04:27 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA13862; Wed, 25 Apr 2001 12:04:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00930 Wed, 25 Apr 2001 14:08:57 -0400 (EDT) Message-ID: <3AE713E5.493814A@certicom.com> Date: Wed, 25 Apr 2001 14:13:57 -0400 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Dan Harkins CC: "'ipsec@lists.tislabs.com'" Subject: Re: tunnle mode SAs... References: <7550F251EA0C410285256A39005D5BE1.005D804385256A39@certicom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, Actually each fragment has it's own authentication trailer. So, you don't have to defragment packet to verify that authentication is OK. -Yuri Dan Harkins wrote: > > On Wed, 25 Apr 2001 12:26:05 EDT you wrote > > > > On inbound > > 1. - dencrypt each fragment > > - defragment a packet > > or > > 2. - defragment a packet > > - dencrypt a packet > > > > The second case (2), I think, is used more often. > > You should handle both cases if you want to cover all situations. > > I don't think 1 is possible. We authenticate encrypted packets and you > must reconstruct the entire packet before you can authenticate it. > > Dan. From owner-ipsec@lists.tislabs.com Wed Apr 25 12:31:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA14268; Wed, 25 Apr 2001 12:31:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01030 Wed, 25 Apr 2001 14:30:50 -0400 (EDT) From: Steve.Robinson@psti.com Subject: Re: tunnel mode SAs... To: Dan Harkins Cc: Chris Trobridge , "Jain, Gautam" , "'ipsec@lists.tislabs.com'" , Stephen Kent , owner-ipsec@lists.tislabs.com, Yuri Poeluev X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 25 Apr 2001 14:38:15 -0400 X-MIMETrack: Serialize by Router on ARCVAUTO/ARC(Release 5.0.5 |September 22, 2000) at 04/25/2001 02:38:55 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >On Wed, 25 Apr 2001 12:26:05 EDT you wrote >> >> On inbound >> 1. - dencrypt each fragment >> - defragment a packet >> or >> 2. - defragment a packet >> - dencrypt a packet >> >> The second case (2), I think, is used more often. >> You should handle both cases if you want to cover all situations. > >I don't think 1 is possible. We authenticate encrypted packets and you >must reconstruct the entire packet before you can authenticate it. > > Dan. Couldn't you just use NULL authentication? Anyway, isn't this discussion irrelevant? Section 5.2 of RFC 2401 clearly states that: "Prior to performing AH or ESP processing, any IP fragments are reassembled." So only the second case is allowed. Steve From owner-ipsec@lists.tislabs.com Wed Apr 25 12:40:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA14443; Wed, 25 Apr 2001 12:40:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01076 Wed, 25 Apr 2001 14:51:57 -0400 (EDT) Message-Id: <200104251847.f3PIlax42960@potassium.cips.nokia.com> To: Yuri Poeluev cc: "'ipsec@lists.tislabs.com'" Subject: Re: tunnle mode SAs... In-Reply-To: Your message of "Wed, 25 Apr 2001 14:13:57 EDT." <3AE713E5.493814A@certicom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42957.988224456.1@potassium.cips.nokia.com> Date: Wed, 25 Apr 2001 11:47:36 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If each fragment is a separate IPsec datagram (each with it's own auth data and sequence number) then I don't see how #1 can happen. We're talking about the situation where the box is a security gateway and the selector has port and/or protocol information. Isn't fragmentation done after IPsec processing? In that case #1 (for outbound) would never happen. If the other side is an endhost it wouldn't fragment a packet and then apply IPsec to the fragments. If it's a router then it'd have to reconstruct the whole packet prior to IPsec processing anyway, right? If the selector did not specify port and/or protocol information and the router received a fragment it would just process it like it was a normal IP datagram and you'd receive a bunch of IPsec-protected fragments. And if that's the case then #1 for inbound would not happen. When your selector specifies port and/or protocol information I think you can only expect to get a fragmented IPsec packet, not IPsec-protected fragments which need to be decrypted and recontructed. If the selector doesn't specify port and/or protocol information then the IPsec-protected fragments are just IP packets and let the ultimate destination reassemble everything-- no reason to reassemble them yourself. Or am I missing something? Dan. On Wed, 25 Apr 2001 14:13:57 EDT you wrote > Dan, > > Actually each fragment has it's own authentication trailer. > So, you don't have to defragment packet to verify that > authentication is OK. > > -Yuri > > Dan Harkins wrote: > > > > On Wed, 25 Apr 2001 12:26:05 EDT you wrote > > > > > > On inbound > > > 1. - dencrypt each fragment > > > - defragment a packet > > > or > > > 2. - defragment a packet > > > - dencrypt a packet > > > > > > The second case (2), I think, is used more often. > > > You should handle both cases if you want to cover all situations. > > > > I don't think 1 is possible. We authenticate encrypted packets and you > > must reconstruct the entire packet before you can authenticate it. > > > > Dan. From owner-ipsec@lists.tislabs.com Wed Apr 25 14:26:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA16739; Wed, 25 Apr 2001 14:26:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01416 Wed, 25 Apr 2001 16:22:48 -0400 (EDT) Message-ID: <3AE73360.BFBC7E8C@certicom.com> Date: Wed, 25 Apr 2001 16:28:16 -0400 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Dan Harkins CC: "'ipsec@lists.tislabs.com'" Subject: Re: tunnle mode SAs... References: <9ADE6D985B11524085256A390069D7CB.0069F63385256A39@certicom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I wrote my notes below. Dan Harkins wrote: > > If each fragment is a separate IPsec datagram (each with it's own > auth data and sequence number) then I don't see how #1 can happen. We're > talking about the situation where the box is a security gateway and the > selector has port and/or protocol information. If the selector has port and/or protocol number then I don't see how case 1 is different from case 2 when you hasn't decrypted a packet yet. In case two, you have a packet encrypted/authenticated and you don't know what port/protocol is in the inner packet until you decrypt it. In case 1, we have a fragment and before decryption takes place you also don't know what port/protocol is used inside (actually in the first fragment). In both cases you can't verify port/protocol selectors until you get an original inner packet (case 2) or defragmented packet (case 1). Note that after decryption logic is different for two cases. In case 1 you have to decrypt and queue fragments before you can apply your security policy. That's only difference I can see and it requires more packet processing, which happens on different levels in network stack. > > Isn't fragmentation done after IPsec processing? In that case #1 (for > outbound) would never happen. If the other side is an endhost it wouldn't > fragment a packet and then apply IPsec to the fragments. If it's a router > then it'd have to reconstruct the whole packet prior to IPsec processing > anyway, right? If the selector did not specify port and/or protocol > information and the router received a fragment it would just process it > like it was a normal IP datagram and you'd receive a bunch of > IPsec-protected > fragments. As I wrote above, fragmentation theoretically can be done before encryption. I said theoretically because I don't know who is actually doing it. Maybe nobody has thought about it? Why do you say it's impossible to fragment before encryption? If we define the rule "fragment only after encryption", I agree case 1 would never happen. I just don't see why technically case 1 is impossible even considering all RFC and drafts we have now. Or maybe I missed something? > > And if that's the case then #1 for inbound would not happen. When your > selector specifies port and/or protocol information I think you can only > expect to get a fragmented IPsec packet, not IPsec-protected fragments > which > need to be decrypted and recontructed. If the selector doesn't specify > port and/or protocol information then the IPsec-protected fragments are > just IP packets and let the ultimate destination reassemble everything-- no > reason to reassemble them yourself. > > Or am I missing something? > > Dan. > > On Wed, 25 Apr 2001 14:13:57 EDT you wrote > > Dan, > > > > Actually each fragment has it's own authentication trailer. > > So, you don't have to defragment packet to verify that > > authentication is OK. > > > > -Yuri > > > > Dan Harkins wrote: > > > > > > On Wed, 25 Apr 2001 12:26:05 EDT you wrote > > > > > > > > On inbound > > > > 1. - dencrypt each fragment > > > > - defragment a packet > > > > or > > > > 2. - defragment a packet > > > > - dencrypt a packet > > > > > > > > The second case (2), I think, is used more often. > > > > You should handle both cases if you want to cover all situations. > > > > > > I don't think 1 is possible. We authenticate encrypted packets and you > > > must reconstruct the entire packet before you can authenticate it. > > > > > > Dan. Thanks, -Yuri From owner-ipsec@lists.tislabs.com Wed Apr 25 14:26:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA16753; Wed, 25 Apr 2001 14:26:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01442 Wed, 25 Apr 2001 16:31:14 -0400 (EDT) Message-ID: <3AE7356F.F87EDF7E@certicom.com> Date: Wed, 25 Apr 2001 16:37:03 -0400 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: ipsec@lists.tislabs.com, Steve.Robinson@psti.com Subject: Re: tunnel mode SAs... References: <4CAA6040F17BF38E85256A39006806A0.0068245285256A39@certicom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If we have logic that defore decryption you are trying to defragment first if required (found fragments), and also trying to defragment after decryption but before applying security policy. This will cover both case 1 and case 2 at the same time on the receive side. Thanks, -Yuri Steve.Robinson@psti.com wrote: > > >On Wed, 25 Apr 2001 12:26:05 EDT you wrote > >> > >> On inbound > >> 1. - dencrypt each fragment > >> - defragment a packet > >> or > >> 2. - defragment a packet > >> - dencrypt a packet > >> > >> The second case (2), I think, is used more often. > >> You should handle both cases if you want to cover all situations. > > > >I don't think 1 is possible. We authenticate encrypted packets and you > >must reconstruct the entire packet before you can authenticate it. > > > > Dan. > > Couldn't you just use NULL authentication? Anyway, isn't this discussion > irrelevant? Section 5.2 of RFC 2401 clearly states that: "Prior to > performing AH or ESP processing, any IP fragments are > reassembled." So only the second case is allowed. > > Steve From owner-ipsec@lists.tislabs.com Wed Apr 25 15:25:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA17889; Wed, 25 Apr 2001 15:25:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01553 Wed, 25 Apr 2001 17:38:27 -0400 (EDT) Message-Id: <200104252134.f3PLYFx43541@potassium.cips.nokia.com> To: Yuri Poeluev cc: "'ipsec@lists.tislabs.com'" Subject: Re: tunnle mode SAs... In-Reply-To: Your message of "Wed, 25 Apr 2001 16:28:16 EDT." <3AE73360.BFBC7E8C@certicom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <43538.988234455.1@potassium.cips.nokia.com> Date: Wed, 25 Apr 2001 14:34:15 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 25 Apr 2001 16:28:16 EDT you wrote > Dan Harkins wrote: > > Isn't fragmentation done after IPsec processing? In that case #1 (for > > outbound) would never happen. If the other side is an endhost it wouldn't > > fragment a packet and then apply IPsec to the fragments. If it's a router > > then it'd have to reconstruct the whole packet prior to IPsec processing > > anyway, right? If the selector did not specify port and/or protocol > > information and the router received a fragment it would just process it > > like it was a normal IP datagram and you'd receive a bunch of > > IPsec-protected > > fragments. > > As I wrote above, fragmentation theoretically can be done before encryption. > I said theoretically because I don't know who is actually doing it. > Maybe nobody has thought about it? Why do you say it's impossible to > fragment before encryption? If we define the rule "fragment only after > encryption", I agree case 1 would never happen. I just don't see > why technically case 1 is impossible even considering all RFC and > drafts we have now. Or maybe I missed something? Section 3.3.4 of RFC2402 and section 3.3.5 of RFC2406 both say that fragmentation is performed _after_ outbound IPsec processing. Dan. From owner-ipsec@lists.tislabs.com Wed Apr 25 16:43:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA18938; Wed, 25 Apr 2001 16:43:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01722 Wed, 25 Apr 2001 18:49:15 -0400 (EDT) Message-ID: <3AE755C4.BC85B781@certicom.com> Date: Wed, 25 Apr 2001 18:55:00 -0400 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Dan Harkins CC: ipsec@lists.tislabs.com Subject: Re: tunnle mode SAs... References: <11FF95E8F84A683385256A39007728B3.0077D10E85256A39@certicom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: > > On Wed, 25 Apr 2001 16:28:16 EDT you wrote > > Dan Harkins wrote: > > > Isn't fragmentation done after IPsec processing? In that case #1 (for > > > outbound) would never happen. If the other side is an endhost it > wouldn't > > > fragment a packet and then apply IPsec to the fragments. If it's a > router > > > then it'd have to reconstruct the whole packet prior to IPsec > processing > > > anyway, right? If the selector did not specify port and/or protocol > > > information and the router received a fragment it would just process it > > > like it was a normal IP datagram and you'd receive a bunch of > > > IPsec-protected > > > fragments. > > > > As I wrote above, fragmentation theoretically can be done before > encryption. > > I said theoretically because I don't know who is actually doing it. > > Maybe nobody has thought about it? Why do you say it's impossible to > > fragment before encryption? If we define the rule "fragment only after > > encryption", I agree case 1 would never happen. I just don't see > > why technically case 1 is impossible even considering all RFC and > > drafts we have now. Or maybe I missed something? > > Section 3.3.4 of RFC2402 and section 3.3.5 of RFC2406 both say that > fragmentation is performed _after_ outbound IPsec processing. > > Dan. Thanks Dan. I agree that it makes sense to define one rule only for packet processing. And I thought such rule should be defined somewhere, but I didn't know where exactly. I was also considering a situation when a developer has difficulties of implementing IPSec above the level where packet fragmentation is done, due to OS architecture. So, I guess he doesn't have a choice but to give up. That's why I included case 1 to give him a hope :-) And apparently there is no hope unless we want to break this rule. I guess there is a similar rule defining case 2 for inbound traffic as well. -Yuri From owner-ipsec@lists.tislabs.com Wed Apr 25 19:40:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA22668; Wed, 25 Apr 2001 19:40:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA02086 Wed, 25 Apr 2001 21:44:26 -0400 (EDT) Message-ID: <01f201c0cdf4$496453c0$1cab7018@cr592232-b.flfrd1.on.wave.home.com> Reply-To: "Claudio Lordello" From: "Claudio Lordello" To: "Yuri Poeluev" , "Dan Harkins" Cc: Subject: Re: tunnle mode SAs... Date: Wed, 25 Apr 2001 21:57:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >On Wed, 25 Apr 2001 16:28:16 EDT you wrote >> Dan Harkins wrote: >> > Isn't fragmentation done after IPsec processing? In that case #1 (for >> > outbound) would never happen. If the other side is an endhost it wouldn't >> > fragment a packet and then apply IPsec to the fragments. If it's a router >> > then it'd have to reconstruct the whole packet prior to IPsec processing >> > anyway, right? If the selector did not specify port and/or protocol >> > information and the router received a fragment it would just process it >> > like it was a normal IP datagram and you'd receive a bunch of >> > IPsec-protected >> > fragments. >> >> As I wrote above, fragmentation theoretically can be done before encryption. >> I said theoretically because I don't know who is actually doing it. >> Maybe nobody has thought about it? Why do you say it's impossible to >> fragment before encryption? If we define the rule "fragment only after >> encryption", I agree case 1 would never happen. I just don't see >> why technically case 1 is impossible even considering all RFC and >> drafts we have now. Or maybe I missed something? > >Section 3.3.4 of RFC2402 and section 3.3.5 of RFC2406 both say that >fragmentation is performed _after_ outbound IPsec processing. > > Dan. > Yes. But does that mean that fragmentation before IPsec is not allowed. I didn't think so. I understood that to say: if you IPsec a packet and it grows beyond the interface MTU, than fragment it. What stops a SG from receiving already fragmented packets from the host it is protecting? How different is IPsec'ing those fragment from receiving a whole packet, fragmenting it within the SG and then IPsec'ing it? Granted, there is a problem when protocol/ports are used as selectors, as Dan already pointed out. But if they are not, then both options 1 and 2 are OK. My point is that I do not understand the need to disallow fragmentation before IPsec for every situation. In fact, fragmenting to a IPsec-overhead-discounted MTU before IPsec'ing has the advantage of removing the burden of reassembly on the remote SG. Claudio. From owner-ipsec@lists.tislabs.com Wed Apr 25 22:30:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA25308; Wed, 25 Apr 2001 22:30:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA02344 Thu, 26 Apr 2001 00:40:46 -0400 (EDT) Message-Id: <200104260436.f3Q4aNx44334@potassium.cips.nokia.com> To: "Claudio Lordello" cc: "Yuri Poeluev" , ipsec@lists.tislabs.com Subject: Re: tunnle mode SAs... In-Reply-To: Your message of "Wed, 25 Apr 2001 21:57:44 EDT." <01f201c0cdf4$496453c0$1cab7018@cr592232-b.flfrd1.on.wave.home.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <44331.988259783.1@potassium.cips.nokia.com> Date: Wed, 25 Apr 2001 21:36:23 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 25 Apr 2001 21:57:44 EDT you wrote > > >On Wed, 25 Apr 2001 16:28:16 EDT you wrote > > > >Section 3.3.4 of RFC2402 and section 3.3.5 of RFC2406 both say that > >fragmentation is performed _after_ outbound IPsec processing. > > > > Dan. > > > > Yes. But does that mean that fragmentation before IPsec is not allowed. I did >n't think so. I > understood that to say: if you IPsec a packet and it grows beyond the interfa >ce MTU, than fragment > it. > > What stops a SG from receiving already fragmented packets from the host it is > protecting? How > different is IPsec'ing those fragment from receiving a whole packet, fragment >ing it within the SG > and then IPsec'ing it? Granted, there is a problem when protocol/ports are us >ed as selectors, as > Dan already pointed out. But if they are not, then both options 1 and 2 are O >K. My point is that I > do not understand the need to disallow fragmentation before IPsec for every s >ituation. In fact, > fragmenting to a IPsec-overhead-discounted MTU before IPsec'ing has the advan >tage of removing the > burden of reassembly on the remote SG. > > Claudio. A security gateway receiving an already fragmented packet is different from a security gateway receiving a non-fragmented packet, fragmenting it and then applying IPsec to each fragment. The rules for the former are very well stated and not being debated. Since I don't believe compliant devices are supposed to do the latter then I don't believe a security gateway will ever receive encrypted fragments that it has to independently IPsec process and then combine to reconstruct a packet which is forwarded on to the ultimate destination. That was case #2 from Yuri's post. If the selector had port and/or protocol information the gateway would not be receiving IPsec-protected fragments of the original packet, it would be receiving fragments of the IPsec protected original packet. If the selector did not have port and/or protocol information the gateway would just process the fragments as normal IP packets and no reassembly on either end would be necessary. Dan. From owner-ipsec@lists.tislabs.com Thu Apr 26 00:57:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA13104; Thu, 26 Apr 2001 00:57:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA02721 Thu, 26 Apr 2001 02:48:48 -0400 (EDT) Message-ID: <007501c0ce1d$c27d0300$3f02a8c0@garibaldi> From: "Sami Vaarala" To: "Yuri Poeluev" , "Dan Harkins" Cc: References: <11FF95E8F84A683385256A39007728B3.0077D10E85256A39@certicom.com> <3AE755C4.BC85B781@certicom.com> Subject: Re: tunnle mode SAs... Date: Thu, 26 Apr 2001 09:54:35 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yuri and others, > Dan Harkins wrote: > > [snip] > > > > Section 3.3.4 of RFC2402 and section 3.3.5 of RFC2406 both say that > > fragmentation is performed _after_ outbound IPsec processing. > > > > Dan. > > Thanks Dan. I agree that it makes sense to define one rule only for packet > processing. And I thought such rule should be defined somewhere, > but I didn't know where exactly. I was also considering a situation when a > developer has difficulties of implementing IPSec above the level where packet > fragmentation is done, due to OS architecture. So, I guess he doesn't > have a choice but to give up. That's why I included case 1 to give him > a hope :-) And apparently there is no hope unless we want to break > this rule. I guess there is a similar rule defining case 2 for inbound > traffic as well. > > -Yuri How is the following paragraph of RFC 2401 Appendix B to be understood? As far as I understand, it is stating that encrypting fragments in tunnel mode is acceptable? What do you do with extremely large packets if you cannot fragment prior to encryption? Eg. you have a 65535 byte IP packet, and you want to ESP tunnel it. The processed packet is larger than maximum IPv4 packet size. If you are allowed to fragment this datagram eg into two roughly 32k pieces and tunnel them separately, there is no connectivity problem. And as Yuri pointed out, this is no problem if your processing first decrypts and reassembles, and then checks policy. ----- B.2 Fragmentation If required, IP fragmentation occurs after IPsec processing within an IPsec implementation. Thus, transport mode AH or ESP is applied only to whole IP datagrams (not to IP fragments). An IP packet to which AH or ESP has been applied may itself be fragmented by routers en route, and such fragments MUST be reassembled prior to IPsec processing at a receiver. In tunnel mode, AH or ESP is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway, "bump-in-the-stack" (BITS), or "bump- in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to such fragments. Note that BITS or BITW implementations are examples of where a host IPsec implementation might receive fragments to which tunnel mode is to be applied. However, if transport mode is to be applied, then these implementations MUST reassemble the fragments prior to applying IPsec. ----- -Sami From owner-ipsec@lists.tislabs.com Thu Apr 26 03:48:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA28700; Thu, 26 Apr 2001 03:48:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA03125 Thu, 26 Apr 2001 05:52:12 -0400 (EDT) From: "Jian-Rong Chen" To: "Dan Harkins" , "Claudio Lordello" Cc: "Yuri Poeluev" , Subject: RE: tunnel mode SAs... Date: Thu, 26 Apr 2001 10:57:24 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200104260436.f3Q4aNx44334@potassium.cips.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 25 Apr 2001 21:57:44 EDT Dan wrote > > A security gateway receiving an already fragmented packet is different > from a security gateway receiving a non-fragmented packet, fragmenting > it and then applying IPsec to each fragment. The rules for the former > are very well stated and not being debated. > > Since I don't believe compliant devices are supposed to do the latter > then I don't believe a security gateway will ever receive encrypted > fragments that it has to independently IPsec process and then combine to > reconstruct a packet which is forwarded on to the ultimate destination. > That was case #2 from Yuri's post. > > If the selector had port and/or protocol information the gateway would > not be receiving IPsec-protected fragments of the original packet, it > would be receiving fragments of the IPsec protected original packet. > If the selector did not have port and/or protocol information the > gateway would just process the fragments as normal IP packets and no > reassembly on either end would be necessary. > > Dan. > If the selector had port and/or protocol information, could the gateway receive plain fragments (not IPsec protected) of the original packet? If it could, then reassembly would be needed before forward IPsec processing. If we think of un-protected packets as packets protected by a NULL SA, then this is equivalent to cascading a NULL SA with a tunnel SA in a gateway. I don't know if cascading (not bundling) of two SA tunnels in a security gateway is allowed or not in IPsec architecture. If it is, then packets could go through a sequence of "inbound IPsec processing(SA1) -> reassembly -> outbound IPsec processing(SA2)" JR Chen ************************************************************************* The information contained in this message or any of its attachments may be privileged and confidential and intended for the exclusive use of the addressee. If you are not the addressee any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited ************************************************************************** From owner-ipsec@lists.tislabs.com Thu Apr 26 04:30:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA02230; Thu, 26 Apr 2001 04:30:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA03258 Thu, 26 Apr 2001 06:48:22 -0400 (EDT) Message-ID: From: Chris Trobridge To: Jian-Rong Chen , Dan Harkins , Claudio Lordello Cc: Yuri Poeluev , ipsec@lists.tislabs.com Subject: RE: tunnel mode SAs... Date: Thu, 26 Apr 2001 11:53:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Not all the fragments are guaranteed to go through one SGW. Chris > -----Original Message----- > From: Jian-Rong Chen [mailto:jrc@adv.sonybpe.com] > Sent: 26 April 2001 10:57 > To: Dan Harkins; Claudio Lordello > Cc: Yuri Poeluev; ipsec@lists.tislabs.com > Subject: RE: tunnel mode SAs... > > > > On Wed, 25 Apr 2001 21:57:44 EDT Dan wrote > > > > A security gateway receiving an already fragmented packet > is different > > from a security gateway receiving a non-fragmented packet, > fragmenting > > it and then applying IPsec to each fragment. The rules for > the former > > are very well stated and not being debated. > > > > Since I don't believe compliant devices are supposed to do > the latter > > then I don't believe a security gateway will ever receive encrypted > > fragments that it has to independently IPsec process and > then combine to > > reconstruct a packet which is forwarded on to the ultimate > destination. > > That was case #2 from Yuri's post. > > > > If the selector had port and/or protocol information the > gateway would > > not be receiving IPsec-protected fragments of the original > packet, it > > would be receiving fragments of the IPsec protected original packet. > > If the selector did not have port and/or protocol information the > > gateway would just process the fragments as normal IP packets and no > > reassembly on either end would be necessary. > > > > Dan. > > > If the selector had port and/or protocol information, could > the gateway > receive plain fragments (not IPsec protected) of the original > packet? If > it could, then reassembly would be needed before forward > IPsec processing. > If we think of un-protected packets as packets protected by a > NULL SA, then > this is equivalent to cascading a NULL SA with a tunnel SA in > a gateway. > I don't know if cascading (not bundling) of two SA tunnels in > a security > gateway is allowed or not in IPsec architecture. If it is, > then packets > could go through a sequence of "inbound IPsec processing(SA1) > -> reassembly > -> outbound IPsec processing(SA2)" > > JR Chen > > > > ************************************************************** > *********** > The information contained in this message or any of its > attachments may be privileged and confidential and intended > for the exclusive use of the addressee. If you are not the > addressee any disclosure, reproduction, distribution or other > dissemination or use of this communication is strictly prohibited > ************************************************************** > ************ > > > This footnote confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From owner-ipsec@lists.tislabs.com Thu Apr 26 08:05:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA17066; Thu, 26 Apr 2001 08:05:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA03954 Thu, 26 Apr 2001 10:14:41 -0400 (EDT) Message-ID: <8894CA1F87A5D411BD24009027EE78381280A7@md-exchange1.nai.com> From: "Mason, David" To: "'Claudio Lordello'" , Yuri Poeluev , Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: tunnle mode SAs... Date: Thu, 26 Apr 2001 07:18:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Support for fragmenting before applying IPsec is a requirement (for the case where handling the DF bit for the outer header of tunnels is set to Set - re Arch RFC). -dave -----Original Message----- From: Claudio Lordello [mailto:clordello@home.com] Sent: Wednesday, April 25, 2001 9:58 PM To: Yuri Poeluev; Dan Harkins Cc: ipsec@lists.tislabs.com Subject: Re: tunnle mode SAs... >On Wed, 25 Apr 2001 16:28:16 EDT you wrote >> Dan Harkins wrote: >> > Isn't fragmentation done after IPsec processing? In that case #1 (for >> > outbound) would never happen. If the other side is an endhost it wouldn't >> > fragment a packet and then apply IPsec to the fragments. If it's a router >> > then it'd have to reconstruct the whole packet prior to IPsec processing >> > anyway, right? If the selector did not specify port and/or protocol >> > information and the router received a fragment it would just process it >> > like it was a normal IP datagram and you'd receive a bunch of >> > IPsec-protected >> > fragments. >> >> As I wrote above, fragmentation theoretically can be done before encryption. >> I said theoretically because I don't know who is actually doing it. >> Maybe nobody has thought about it? Why do you say it's impossible to >> fragment before encryption? If we define the rule "fragment only after >> encryption", I agree case 1 would never happen. I just don't see >> why technically case 1 is impossible even considering all RFC and >> drafts we have now. Or maybe I missed something? > >Section 3.3.4 of RFC2402 and section 3.3.5 of RFC2406 both say that >fragmentation is performed _after_ outbound IPsec processing. > > Dan. > Yes. But does that mean that fragmentation before IPsec is not allowed. I didn't think so. I understood that to say: if you IPsec a packet and it grows beyond the interface MTU, than fragment it. What stops a SG from receiving already fragmented packets from the host it is protecting? How different is IPsec'ing those fragment from receiving a whole packet, fragmenting it within the SG and then IPsec'ing it? Granted, there is a problem when protocol/ports are used as selectors, as Dan already pointed out. But if they are not, then both options 1 and 2 are OK. My point is that I do not understand the need to disallow fragmentation before IPsec for every situation. In fact, fragmenting to a IPsec-overhead-discounted MTU before IPsec'ing has the advantage of removing the burden of reassembly on the remote SG. Claudio. From owner-ipsec@lists.tislabs.com Thu Apr 26 08:05:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA17080; Thu, 26 Apr 2001 08:05:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03904 Thu, 26 Apr 2001 09:58:38 -0400 (EDT) Message-ID: <3AE82AD9.1B574FB4@certicom.com> Date: Thu, 26 Apr 2001 10:04:09 -0400 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Sami Vaarala CC: ipsec@lists.tislabs.com, Dan Harkins Subject: Re: tunnle mode SAs... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks Sami, Sami Vaarala wrote: > > Yuri and others, > > > Dan Harkins wrote: > > > > [snip] > > > > > > Section 3.3.4 of RFC2402 and section 3.3.5 of RFC2406 both say that > > > fragmentation is performed _after_ outbound IPsec processing. > > > > > > Dan. > > > > Thanks Dan. I agree that it makes sense to define one rule only for > packet > > processing. And I thought such rule should be defined somewhere, > > but I didn't know where exactly. I was also considering a situation when > a > > developer has difficulties of implementing IPSec above the level where > packet > > fragmentation is done, due to OS architecture. So, I guess he doesn't > > have a choice but to give up. That's why I included case 1 to give him > > a hope :-) And apparently there is no hope unless we want to break > > this rule. I guess there is a similar rule defining case 2 for inbound > > traffic as well. > > > > -Yuri > > How is the following paragraph of RFC 2401 Appendix B to be understood? > As far as I understand, it is stating that encrypting fragments in tunnel > mode is acceptable? > > What do you do with extremely large packets if you cannot fragment prior > to encryption? Eg. you have a 65535 byte IP packet, and you want to ESP > tunnel it. The processed packet is larger than maximum IPv4 packet size. > If you are allowed to fragment this datagram eg into two roughly 32k pieces > and tunnel them separately, there is no connectivity problem. > > And as Yuri pointed out, this is no problem if your processing first > decrypts and reassembles, and then checks policy. > > ----- > > B.2 Fragmentation > > If required, IP fragmentation occurs after IPsec processing within an > IPsec implementation. Thus, transport mode AH or ESP is applied only > to whole IP datagrams (not to IP fragments). An IP packet to which > AH or ESP has been applied may itself be fragmented by routers en > route, and such fragments MUST be reassembled prior to IPsec > processing at a receiver. In tunnel mode, AH or ESP is applied to an > IP packet, the payload of which may be a fragmented IP packet. For > example, a security gateway, "bump-in-the-stack" (BITS), or "bump- > in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to > such fragments. Note that BITS or BITW implementations are examples > of where a host IPsec implementation might receive fragments to which > tunnel mode is to be applied. However, if transport mode is to be > applied, then these implementations MUST reassemble the fragments > prior to applying IPsec. > > ----- > > -Sami I would allow encrypting/decrypting fragments especially when we have it written already. Though, then SG would have to add more logic into packet processing. And if we do it, we are not going to change the current behavior, but only to add functionality into SG. I don't see a problem here and to me case 1 is not very different from case 2 except that to cover case 1 we have to add more rules. -Yuri From owner-ipsec@lists.tislabs.com Fri Apr 27 04:46:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA14568; Fri, 27 Apr 2001 04:46:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA06398 Fri, 27 Apr 2001 06:39:44 -0400 (EDT) Message-Id: <200104271044.GAA21046@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-flow-monitoring-mib-01.txt Date: Fri, 27 Apr 2001 06:44:33 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IPsec Flow Monitoring MIB Author(s) : C. Madson, L. Temoshenko, C. Pellacuru, B. Harrison, S. Ramakrishnan Filename : draft-ietf-ipsec-flow-monitoring-mib-01.txt Pages : 144 Date : 26-Apr-01 This document describes a high-level MIB for monitoring, accounting trending and failure detection for IPsec-based VPNs. Optional features of the MIB include trending of IPsec-related metrics and archiving of VPN failures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-flow-monitoring-mib-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-flow-monitoring-mib-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-flow-monitoring-mib-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: <20010426132409.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-flow-monitoring-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-flow-monitoring-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010426132409.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Apr 30 11:57:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA07957; Mon, 30 Apr 2001 11:57:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00678 Mon, 30 Apr 2001 13:35:04 -0400 (EDT) Message-ID: <025301c0d192$9c74bae0$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: IPsec Global Summit 2001 Date: Mon, 30 Apr 2001 18:28:37 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0250_01C0D1A3.5F880CC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0250_01C0D1A3.5F880CC0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello, The third edition of the IPsec Global Summit will be organised next = 23-26 October in Paris. A call for proposals is online at: http://www.upperside.fr/ipsec2001/ipsec01cfp.htm ------=_NextPart_000_0250_01C0D1A3.5F880CC0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello, The third edition of the IPsec Global Summit will be = organised=20 next 23-26 October in Paris. A call for proposals is online at: <3d.htm>http://www.uppe= rside.fr/ipsec2001/ipsec01cfp.<3d.htm>htm ------=_NextPart_000_0250_01C0D1A3.5F880CC0--