From owner-ipsec@lists.tislabs.com Mon Sep 1 09:55:26 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h81GtPgc016723; Mon, 1 Sep 2003 09:55:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA27376 Mon, 1 Sep 2003 11:56:27 -0400 (EDT) Message-ID: <3F532A00.70607@f-secure.com> Date: Mon, 01 Sep 2003 14:14:08 +0300 From: Ari Huttunen Organization: F-Secure Corporation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: IKEv2 and NAT traversal unclear Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Sep 2003 11:14:08.0231 (UTC) FILETIME=[2992BF70:01C3707A] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk All quoted text is from this section of draft-ietf-ipsec-ikev2-10.txt: > 2.23 NAT Traversal ... > It is a common practice of NATs to translate TCP and UDP port numbers > as well as addresses and use the port numbers of inbound packets to > decide which internal node should get a given packet. For this > reason, even though IKE packets MUST be sent from and to UDP port > 500, they MUST be accepted coming from any port and responses MUST be > sent to the port from whence they came. This is because the ports may > be modified as the packets pass through NATs. Similarly, IP addresses > of the IKE endpoints are generally not included in the IKE payloads > because the payloads are cryptographically protected and could not be > transparently modified by NATs. ... > The specific requirements for supporting NAT traversal are listed > below. Support for NAT traversal is optional. In this section only, > requirements listed as MUST only apply to implementations supporting > NAT traversal. It's my opinion that section 2.23 has too much unnecessary explanatory text that makes it unclear. It is not necessary to explain what a NAT is and why they exist. A reference would be almost sufficient. Also, based on reading the paragraphs above, it would seem that only those IKEv2 implementations that support NAT traversal would need to be able to send IKE packets back to the exact port they came from. Of course this is not true, because the requirement is stated outside of section 2.23, but this just shows that you should state each requirement only once. > The IKE responder MUST include in its IKE_SA_INIT response Notify > payloads of type NAT_DETECTION_SOURCE_IP and > NAT_DETECTION_DESTINATION_IP. The IKE initiator MUST check these > payloads if present and if they do not match the addresses in the > > > > IKEv2 draft-ietf-ipsec-ikev2-10.txt [Page 36] > > Internet-Draft August 16, 2003 > > > outer packet MUST tunnel all future IKE, ESP, and AH packets > associated with this IKE_SA over UDP port 4500. To tunnel IKE > packets over UDP port 4500, the IKE header has four octets of zero > prepended and the result immediately follows the UDP header. To > tunnel ESP packets over UDP port 4500, the ESP header immediately > follows the UDP header. Since the first four bytes of the ESP > header contain the SPI, and the SPI cannot validly be zero, it is > always possible to distinguish ESP and IKE messages. Is it really so that the NAT_DETECTION_* payloads are only sent in one direction in IKEv2, while in IKEv1 they are sent both ways? Remember that in IKEv1 the NAT-D payload is sent both ways because an endpoint only knows that a NAT exist when a NAT-D payload it *receives* doesn't match the packet header. Then in IKEv2 the responder will know that a NAT exists iff the initiator switches ports? What if the initiator initiates to 4500 at the beginning already? One inclarity is whether it's possible to use encapsulation in port 4500 for IKE and ESP without the presence of a NAT. I can see reasons for both wanting to allow it and to disallow it, mainly depending on what you think of the firewall in-between. Disclaimer: I've not read the whole IKEv2 draft, just searched for NAT.. Ari -- I play it cool and dig all jive, that's the reason I stay alive. My motto as I live and learn, is dig and be dug in return. Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Tue Sep 2 10:31:51 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82HVogc033052; Tue, 2 Sep 2003 10:31:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27724 Tue, 2 Sep 2003 12:19:24 -0400 (EDT) Date: Tue, 2 Sep 2003 12:09:58 -0400 From: "Theodore Ts'o" To: Black_David@emc.com Cc: kivinen@ssh.fi, ipsec@lists.tislabs.com Subject: Re: ECN and issue 58 Message-ID: <20030902160958.GD1158@think> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, Aug 25, 2003 at 08:14:01PM -0400, Black_David@emc.com wrote: > Tero, > > > The issue 58 is marked closed, but the section 2.24 is still there in > > the draft-ietf-ipsec-ikev2-10.txt. I think we should remove the first > > paragraph of the section, and simply say that we will do ECN as > > specified in the RFC2401bis. > > I'm a little uncomfortable with the wholesale removal of design > explanation/rationale that would result. As an alternative, would > it be ok w/you if I whacked that first paragraph down to a fraction of > its size (and took out some of the details) to focus on the important > point (RFC2401bis encapsulation changes are "MUST use" in order to > avoid breaking ECN)? That seems like a good compromise. Could you send some proposed text to Charlie ASAP? Many thanks!! - Ted From owner-ipsec@lists.tislabs.com Tue Sep 2 10:32:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82HWQgc033194; Tue, 2 Sep 2003 10:32:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29941 Tue, 2 Sep 2003 12:47:11 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f Message-ID: <16203.987.210389.675499@amme.hel.fi.ssh.com> In-Reply-To: References: X-Mailer: VM 7.04 under Emacs 20.7.1 Organization: SSH Communications Security Oy From: Tero Kivinen To: Black_David@emc.com Cc: ipsec@lists.tislabs.com Subject: RE: ECN and issue 58 Date: Tue, 26 Aug 2003 09:53:15 +0300 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Edit-Time: 0 min X-Total-Time: 0 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Black_David@emc.com writes: > > The issue 58 is marked closed, but the section 2.24 is still there in > > the draft-ietf-ipsec-ikev2-10.txt. I think we should remove the first > > paragraph of the section, and simply say that we will do ECN as > > specified in the RFC2401bis. > I'm a little uncomfortable with the wholesale removal of design > explanation/rationale that would result. As an alternative, would > it be ok w/you if I whacked that first paragraph down to a fraction of > its size (and took out some of the details) to focus on the important > point (RFC2401bis encapsulation changes are "MUST use" in order to > avoid breaking ECN)? That is fine by me. I just think tghat the important stuff (i.e MUST use) in the second paragraph is enough, and I don't know if we need any of the first paragraph. That text should be in the rfc2401bis document. I think the text could be something like this: ---------------------------------------------------------------------- 2.24 ECN (Explicit Congestion Notification) The RFC 3168 includes two ECN operating modes. In order to avoid multiple ECN operating modes and negotiation, tunnel decapsulators for tunnel-mode Security Associations (SAs) created by IKEv2 MUST implement the full-functionality option processing specified in [RFC3168] and [RFC2401bis] to prevent discarding of ECN congestion indications. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Sep 2 10:33:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82HXQgc033393; Tue, 2 Sep 2003 10:33:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29899 Tue, 2 Sep 2003 12:47:06 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200308292339.h7TNdxcJ010996@coredump.cs.columbia.edu> References: <200308292339.h7TNdxcJ010996@coredump.cs.columbia.edu> Date: Tue, 2 Sep 2003 12:51:56 -0400 To: "Angelos D. Keromytis" From: Stephen Kent Subject: Re: IPsec issue #46 -- No need for nested SAs or SA bundles Cc: Karen Seo , ipsec@lists.tislabs.com, kivinen@ssh.fi Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 19:39 -0400 8/29/03, Angelos D. Keromytis wrote: >Just to start some discussion on this issue: wouldn't this break (or make it >very difficult) for IPSP to deal with intermediate gateways etc. ? The >advantage >of the current model with respect to nested IPsec processing is that it allows >an implementation to inject a new SPD entry (and associated SAs), and not >having >to link that SA to a bundle but instead deal with the SPD. >-Angelos > Angelos, I find it difficult to parse your comment. In fact, I think the last string of words is not a sentence :-) Steve From owner-ipsec@lists.tislabs.com Tue Sep 2 10:41:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82HfRgc034919; Tue, 2 Sep 2003 10:41:27 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01682 Tue, 2 Sep 2003 13:00:11 -0400 (EDT) Message-Id: <200309021706.h82H6wcJ030575@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Stephen Kent Cc: Karen Seo , ipsec@lists.tislabs.com, kivinen@ssh.fi Subject: Re: IPsec issue #46 -- No need for nested SAs or SA bundles In-reply-to: Your message of "Tue, 02 Sep 2003 12:51:56 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Sep 2003 13:06:58 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Now you know why I went into CS and not English lit :-) Let me decode the sentence: under the current IPsec architecture, it is possible for a host to build a sequence of nested IPsec tunnels iteratively, i.e., simply by setting up the appropriate SPD entries, and then letting IKE set up the SAs. My initial impression is that this is not possible under the new model ? Cheers, -Angelos In message , Stephen Kent writes: >At 19:39 -0400 8/29/03, Angelos D. Keromytis wrote: >>Just to start some discussion on this issue: wouldn't this break (or make it >>very difficult) for IPSP to deal with intermediate gateways etc. ? The >>advantage >>of the current model with respect to nested IPsec processing is that it allow >s >>an implementation to inject a new SPD entry (and associated SAs), and not >>having >>to link that SA to a bundle but instead deal with the SPD. >>-Angelos >> > >Angelos, > >I find it difficult to parse your comment. In fact, I think the last >string of words is not a sentence :-) > >Steve From owner-ipsec@lists.tislabs.com Tue Sep 2 11:22:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82IM7gc039096; Tue, 2 Sep 2003 11:22:07 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05530 Tue, 2 Sep 2003 13:29:58 -0400 (EDT) To: ipsec@lists.tislabs.com cc: byfraser@cisco.com, angelos@cs.columbia.edu, kivinen@ssh.fi Subject: Possible missing messages From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Tue, 02 Sep 2003 12:35:04 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There appear to be a a few messages that were sent to the list, but which have apparently not hit the reflector. In particular, Karen Seo's message on August 27th, 2003 11:10:02 -0400, subject "IPsec issue #46 -- No need for nested SAs or SA bundles" (although Angelos's response, which quoted most of the original message, *did* make the list), as well as Tero Kivinen's message on August 26th 09:53:15 +0300, Subject, "RE: ECN and issue 58", which apparently also lost. (At least, they were not received by neither me or the VPNC mail message archive.) This may have been the result of some virus checking software losing mail messages; I will be following up with postmaster@lists.tislabs.com. In the meantime, folks should keep an eye out and make sure their they see postings being sent back to them by the ipsec mailing list reflector. If you notice any of your messages apparently being lost by the list, please let us know. - Ted From owner-ipsec@lists.tislabs.com Tue Sep 2 13:12:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82KC3gc049544; Tue, 2 Sep 2003 13:12:04 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12390 Tue, 2 Sep 2003 14:43:29 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200309021744.h82HihcJ031565@coredump.cs.columbia.edu> References: <200309021744.h82HihcJ031565@coredump.cs.columbia.edu> Date: Tue, 2 Sep 2003 13:56:03 -0400 To: "Angelos D. Keromytis" From: Stephen Kent Subject: Re: IPsec issue #46 -- No need for nested SAs or SA bundles Cc: Karen Seo , ipsec@lists.tislabs.com, kivinen@ssh.fi Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 13:44 -0400 9/2/03, Angelos D. Keromytis wrote: >OK, thanks for the clarification. Since most of the implementations supporting >2401bis in the near future will be based on existing 2401-compliant >implementations, I think 2401bis should avoid language that prohibits support >for bundling. One approach may be to pretend it's not there, and have an >1-paragraph appendix saying "if you did SA bundling, you don't *have* to >remove it". > >Cheers, >-Angelos > I would not tell someone that they had to remove the feature if it were present. Folks are always capable of adding things that have only local significance or that provide additional features ONLY if the peer happens to have added the same extra function. Steve From owner-ipsec@lists.tislabs.com Tue Sep 2 13:45:58 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82Kjwgc050936; Tue, 2 Sep 2003 13:45:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08355 Tue, 2 Sep 2003 13:57:41 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <12109.1062213349@marajade.sandelman.ottawa.on.ca> References: <12109.1062213349@marajade.sandelman.ottawa.on.ca> Date: Tue, 2 Sep 2003 13:39:31 -0400 To: Michael Richardson From: Stephen Kent Subject: Re: IPsec issue #46 -- No need for nested SAs or SA bundles Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 23:15 -0400 8/29/03, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >>>>>> "Angelos" == Angelos D Keromytis writes: > Angelos> Just to start some discussion on this issue: wouldn't this break > Angelos> (or make it very difficult) for IPSP to deal with intermediate > Angelos> gateways etc. ? The advantage of the current model with respect > > It isn't clear to me if it does or doesn't. > > Just because IKEv2 can't negotiate bundles, doesn't mean that I can't >negotiate multiple things to do a 5-tuple with different end >points. FreeS/WAN is currently dealing with the question of how much >information we can derive from the policy about the ordering of this >nesting, vs how much we need to be told about. > > It also isn't clear to me why it is any business of 2401bis to say anything >about this. Permitting looping in SA processing is not a good idea - the >policy daemon should do the looping and tell the kernel what to do. But >again, WHY IS THIS THE DOMAIN OF THE IETF? > > As expressed, it appears that 2401bis is addressing the "kernel" issues, >not the architecture. It is turning the problem into a design issue, >rather than a functional requirements issue. > > There is a functional requirement for the *SYSTEM* to deal with multiple >operations on a 5-tuple. It is not the place for the IETF to tell me where >to put that functionality. Michael, 2401 does not mandate a particular processing implementation, and 2401bis will not. But, we do provide a model for processing as a concrete means of describing what needs to be done within an IPsec implementation. The processing model is a form of state machine, and we certainly specify state machines for protocol standards, at least when we do a good job. A primary goal of IETF standards is to promote interoperability. To that end, it is necessary to specify minimum capabilities for implementations, not only in terms of the syntax of what data is exchanged over the net, but also in terms of processing. Failure to do so will result in non-interoperability. The crux of your argument seems to be where we draw a boundary as to what is IPsec and what is the province of some larger system. However, we have no specs for the larger "system" to which you refer, so there will be no basis for interoperability for it. That is not, IMHO, a desirable outcome. Steve From owner-ipsec@lists.tislabs.com Tue Sep 2 14:05:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82L5lgc051749; Tue, 2 Sep 2003 14:05:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06442 Tue, 2 Sep 2003 13:37:55 -0400 (EDT) Message-Id: <200309021744.h82HihcJ031565@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Stephen Kent Cc: Karen Seo , ipsec@lists.tislabs.com, kivinen@ssh.fi Subject: Re: IPsec issue #46 -- No need for nested SAs or SA bundles In-reply-to: Your message of "Tue, 02 Sep 2003 13:33:37 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Sep 2003 13:44:43 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk OK, thanks for the clarification. Since most of the implementations supporting 2401bis in the near future will be based on existing 2401-compliant implementations, I think 2401bis should avoid language that prohibits support for bundling. One approach may be to pretend it's not there, and have an 1-paragraph appendix saying "if you did SA bundling, you don't *have* to remove it". Cheers, -Angelos In message , Stephen Kent writes: >At 13:06 -0400 9/2/03, Angelos D. Keromytis wrote: >>Now you know why I went into CS and not English lit :-) >> >>Let me decode the sentence: under the current IPsec architecture, it is >>possible >>for a host to build a sequence of nested IPsec tunnels iteratively, i.e., >>simply >>by setting up the appropriate SPD entries, and then letting IKE set >>up the SAs. >>My initial impression is that this is not possible under the new model ? >>Cheers, >>-Angelos >> > >OK, now I understand your concern. The proposed text does not >preclude support for nested tunnels, but it does not mandate such >support either. 2401 mandated such support, but I think that in >practice support was not present for nesting, except in the simplest >case of AH + ESP negotiated at the same time by IKE. So, in reality, >the mandated support did not exist in practice in most (any?) >mainstream IPsec implementations. > >I think we agree that since IKE cannot negotiate nesting in general, >that some external means would be needed to cause nested tunnels to >come into existence, and to be used. In the proposed processing model >one might use VIDs to cause a packet to loop through multiple passes >of the IPsec engine. I'm guessing that IPSP might deal with the issue >of how IKE is directed to create the multiple SAs. > >Since we have had no strong support for nesting expressed on the >list, I think it appropriate to remove the mandated support, but >still have a way to achieve the effect, if there is a push for it in >the future. 2401bis does remove the notion of bundled SAs in the SPD, >but since we seem to agree that a higher level policy management >protocol is needed to make this happen, it seems reasonable to >express the bundling in that protocol. The result is that an >implementation that supports IPsec and IKE will be simpler, not >burdened with any explicit support for expressing nesting, but >capable of effecting nesting if so directed. > >Steve From owner-ipsec@lists.tislabs.com Tue Sep 2 15:28:50 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82MSngc057379; Tue, 2 Sep 2003 15:28:49 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA29088 Tue, 2 Sep 2003 17:43:06 -0400 (EDT) Date: Wed, 3 Sep 2003 00:40:18 +0300 Message-Id: <200309022140.h82LeIuw013984@burp.tkv.asdf.org> From: Markku Savela To: kent@bbn.com CC: mcr@sandelman.ottawa.on.ca, ipsec@lists.tislabs.com In-reply-to: (message from Stephen Kent on Tue, 2 Sep 2003 13:39:31 -0400) Subject: Re: IPsec issue #46 -- No need for nested SAs or SA bundles References: <12109.1062213349@marajade.sandelman.ottawa.on.ca> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just a note: my implementation can do nested SA's, assuming you mean situation where you have an internal node "Another" that wants IPSEC, but which happens to be behind a security gateway SG: SA1 MyNode <---------------> SG <----------------------------------------> Another SA2 MyNode has nested SA2's, but both SG and Another would not see nested SA's. From owner-ipsec@lists.tislabs.com Tue Sep 2 16:15:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82NFIgc058871; Tue, 2 Sep 2003 16:15:18 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA05800 Tue, 2 Sep 2003 18:33:24 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Tue, 2 Sep 2003 18:43:33 -0400 To: ipsec@lists.tislabs.com From: Karen Seo Subject: Fwd: IPsec issue #46 -- No need for nested SAs or SA bundles Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >X-Sender: kseo@po2.bbn.com >Date: Wed, 27 Aug 2003 11:10:02 -0400 >To: ipsec@lists.tislabs.com >From: Karen Seo >Subject: IPsec issue #46 -- No need for nested SAs or SA bundles >Cc: "Angelos D. Keromytis" , kivinen@ssh.fi, > kseo@bbn.com >X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) >Status: > >Folks, > >Here's a description and proposed approach for: > >IPsec Issue #: 46 > >Title: No need for nested SAs or SA bundles > >Description: There is no mandate to support nested SAs or SA bundles. > It would be easy to include support for the simple > AH+ESP combination that IKEv1 was able to negotiate, and > that 2401 mandates, if that combination is still viewed > as needed. However, IKEv1 was not able to negotiate any > other nested protocol combinations and IKEv2 does not > support negotiation of SA bundles. > >Proposed approach: > > 1. There will be no support for nesting or SA bundles except via > iteration through IPsec processing. Add text to the discussion > of differences between 2401 and 2401bis, along the lines of: > > "The requirement to support nesting of SAs and the concept of > SA bundles has been removed. An SPD entry specifies application > or removal of only one IPsec header. An implementation MAY > choose to offer SA nesting via appropriate configuration of > SPDs and forwarding tables. After the packet has passed through > IPsec processing, it can be redirected through the IPsec module > again via local, ipsec-virtual-interfaces and use of the [still > under discussion] forwarding lookup function, to cause more > than one layer of IPsec headers to be applied or removed. Note > that to accomplish this, multiple entries would have to be > created, in distinct SPDs, each specifying a layer of IPsec > processing to be applied. There is no IKE support for > negotiating nested SAs, which implies that manual configuration > or use of additional policy management protocols would be > required to coordinate processing at peer IPsec implementations." > >Thank you, >Karen From owner-ipsec@lists.tislabs.com Tue Sep 2 16:15:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82NFfgc058889; Tue, 2 Sep 2003 16:15:41 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA05964 Tue, 2 Sep 2003 18:34:12 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200309022140.h82LeIuw013984@burp.tkv.asdf.org> References: <12109.1062213349@marajade.sandelman.ottawa.on.ca> <200309022140.h82LeIuw013984@burp.tkv.asdf.org> Date: Tue, 2 Sep 2003 18:22:47 -0400 To: Markku Savela From: Stephen Kent Subject: Re: IPsec issue #46 -- No need for nested SAs or SA bundles Cc: mcr@sandelman.ottawa.on.ca, ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 0:40 +0300 9/3/03, Markku Savela wrote: >Just a note: my implementation can do nested SA's, assuming you mean >situation where you have an internal node "Another" that wants IPSEC, >but which happens to be behind a security gateway SG: > > SA1 >MyNode <---------------> SG > <----------------------------------------> Another > SA2 > >MyNode has nested SA2's, but both SG and Another would not see nested >SA's. If I understand your diagram, the MyNode component is the only one that would see these as nested SAs. Presumably SA1 is a tunnel mode SA to SG and SA2 is a tunnel or transport SA to Another. is that right? How did you express the policy that SA2 had to be an SA nested inside of SA1, and thus that SA1 must be created first, etc.? Steve From owner-ipsec@lists.tislabs.com Tue Sep 2 16:35:05 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82NZ4gc059442; Tue, 2 Sep 2003 16:35:04 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA07220 Tue, 2 Sep 2003 18:46:54 -0400 (EDT) Date: Tue, 2 Sep 2003 18:50:51 -0400 From: "Theodore Ts'o" To: Tero Kivinen Cc: Paul Hoffman / VPNC , ipsec@lists.tislabs.com Subject: Re: The remaining IKEv2 issues Message-ID: <20030902225051.GH1158@think> References: <16197.61579.798381.701236@amme.hel.fi.ssh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16197.61579.798381.701236@amme.hel.fi.ssh.com> User-Agent: Mutt/1.5.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, Aug 22, 2003 at 01:29:31PM +0300, Tero Kivinen wrote: > I agree that "MUST NOT" will be crippling the deployment, but "SHOULD > NOT" is fine. From the RFC-2119: > > ---------------------------------------------------------------------- > 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > there may exist valid reasons in particular circumstances when the > particular behavior is acceptable or even useful, but the full > implications should be understood and the case carefully weighed > before implementing any behavior described with this label. > ---------------------------------------------------------------------- > > So I think non-kg EAP methods SHOULD NOT be used. There are cases > where they are acceptable, or even useful, but the full implications > of using them should be understood... SHOULD NOT seems to be a good compromise for this issue. In order to move things along, I'm taking off my wg chair hat, and proposing the following text. Any comments from the working group, before I suggest that Charlie make the changes to the ike v2 document? - Ted Proposed change, in section 2.16, in the second to last paragraph, which currently reads: For EAP methods that create a shared key as a side effect of authentication, that shared key MUST be used by both the Initiator and Responder to generate an AUTH payload using the syntax for shared secrets specified in section 2.15. The shared key generated during an IKE exchange MUST NOT be used for any other purpose. For EAP methods that do not establish a shared key, there will be no AUTH payloads in the final messages. Delete the last sentence, ("For EAP methods that do not establish...") and add the following paragraph: EAP methods that do not establish a shared key SHOULD NOT be used, as they are subject a number of man-in-the-middle attacks if these EAP methods are used in other protocols that do not use a server-authenticated tunnel. Please see the Security Considerations section for more details. If EAP methods that do not generate a shared key are used, there will be no AUTH payloads in the final messages. In the security considerations section, replace the last paragraph with the following text: When using an EAP authentication method that does not generate a shared key for protecting a subsequent AUTH payload, certain man-in-the-middle and server impersonation attacks are possible.[EAPMITM] These vulnerabilities occur when EAP is also used in protocols which are not protected within a secure tunnel. Since EAP is a general-purpose authentication protocol, which is often used to provide single-signon facilities, an deployed IPSEC solution which relies on an EAP authentication method that does not generate a shared key can become compromised due to the deployment of an entirely unrelated application that also happens to use EAP, but in an unprotected fashion. Note that this vulnerability is not limited to just EAP, but can occur in other scenarios where an authenticatoin infrastructure is reused. For example, if the EAP mechanism used by IKEv2 utilizes a token authenticator, and the enterprise deploys a non-encrypted web form which accepts the input from the token authenticator, a man-in-the-middle attacker could impersonate the web server, intercept the token authentication exchange, and use it to initiate an IKEv2 connection. For this reason, use of EAP methods which do not generated shared keys SHOULD be avoided where possible. Where they are used, it is extremely important that all usages of these EAP methods SHOULD utilize a protected tunnel, where the initiator validates the responder's certificate before initiating the EAP exchange. Implementors SHOULD describe the vulnerabilities of using non-key-generating EAP mechanisms in the documentation of their implementations so that the administrators deploying IPSEC solutions are aware of these dangers. Add the following reference: [EAPMITM] N. Asokan, Valtteri Nierni, and Kaisa Nyberg, "Man-in-the-Middle in Tunneled Authentication Protocols", http://eprint.iacr.org/2002/163, November 11, 2002. From owner-ipsec@lists.tislabs.com Tue Sep 2 16:46:36 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82NkZgc059723; Tue, 2 Sep 2003 16:46:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA09835 Tue, 2 Sep 2003 19:06:21 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Tue, 2 Sep 2003 18:43:57 -0400 To: ipsec@lists.tislabs.com From: Karen Seo Subject: Fwd: IPsec issue #50 -- tunnel vs transport mode at link layer Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >X-Sender: kseo@po2.bbn.com >Date: Tue, 26 Aug 2003 14:39:00 -0400 >To: ipsec@lists.tislabs.com >From: Karen Seo >Subject: IPsec issue #50 -- tunnel vs transport mode at link layer >Cc: "Angelos D. Keromytis" , kivinen@ssh.fi, > kseo@bbn.com >X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) >Status: > >Folks, > >Here's a description and proposed approach for: > >IPsec Issue #: 50 > >Title: Tunnel vs transport mode for link security > >Description: At present, security gateways must use tunnel mode > between two security gateways (SGs) or between a security > gateway and a host. This is because in a number of > circumstances, tunnel mode is necessary to enable one > to address an IP packet to a specific, intermediate > IPsec processing point along the path to the eventual > destination. This can't be done if the header contains > only the final destination address. However, for > point-to-point security, the goal is typically > confidentiality and/or integrity and authenticity > between two systems (SGs) which are often > intermediate between the source and destination and > where the next protocol is not transport or IP, e.g., > GRE. In these situations, use of transport mode is > reasonable and in fact, that is what is already being > done. Therefore, 2401bis should allow this usage. > >Proposed approach > > 1. The section describing transport and tunnel modes should > be amended to allow transport mode to be used by a security > gateway for "link" security. There should also be a > warning about the reduction in access control functionality > in this situation. Text along the lines of the following > should be added: > > "In the case where link security is desired between > two intermediate systems (security gateways) along a path, > transport mode may be used instead of tunnel mode. Note > that the access control functions that are an important part > of IPsec are significantly constrained in this context. > So this way of using transport mode should be evaluated carefully > before being employed." > >Thank you, >Karen From owner-ipsec@lists.tislabs.com Tue Sep 2 16:47:14 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82NlDgc059755; Tue, 2 Sep 2003 16:47:14 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA09852 Tue, 2 Sep 2003 19:06:25 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 2 Sep 2003 18:43:48 -0400 To: "Theodore Ts'o" From: Karen Seo Subject: Re: Possible missing messages Cc: ipsec@lists.tislabs.com, byfraser@cisco.com, angelos@cs.columbia.edu, kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ted, Re: 2401-bis emails... On 8/26, we sent out a separate message for each of the issues below to the list. Tracker # Title ------- ------------------------------------ 46 No need for nested SAs or SA bundles 47 Selectors can be a list of ranges 48 Add TOS traffic selector option 49 Red-side fragmentation option 50 Tunnel vs transport mode at link layer 57 ECN support They were cc:d to Angelos and Tero, who consequently would have received copies of the messages even if the list reflector didn't forward them on. It looks as if 46 and 50 didn't make it. I will resend them. Please let me know if they don't reach you and if others didn't get distributed. Thank you, Karen >There appear to be a a few messages that were sent to the list, but >which have apparently not hit the reflector. In particular, Karen Seo's >message on August 27th, 2003 11:10:02 -0400, subject "IPsec issue #46 -- >No need for nested SAs or SA bundles" (although Angelos's response, >which quoted most of the original message, *did* make the list), as well >as Tero Kivinen's message on August 26th 09:53:15 +0300, Subject, "RE: >ECN and issue 58", which apparently also lost. (At least, they were not >received by neither me or the VPNC mail message archive.) > >This may have been the result of some virus checking software losing >mail messages; I will be following up with postmaster@lists.tislabs.com. >In the meantime, folks should keep an eye out and make sure their they >see postings being sent back to them by the ipsec mailing list >reflector. > >If you notice any of your messages apparently being lost by the list, >please let us know. > > - Ted From owner-ipsec@lists.tislabs.com Tue Sep 2 16:51:49 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82Npmgc059870; Tue, 2 Sep 2003 16:51:48 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA10586 Tue, 2 Sep 2003 19:13:15 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: Re: IPsec issue #46 -- No need for nested SAs or SA bundles In-reply-to: Your message of "Wed, 03 Sep 2003 00:40:18 +0300." <200309022140.h82LeIuw013984@burp.tkv.asdf.org> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 02 Sep 2003 18:37:36 -0400 Message-ID: <6900.1062542256@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Markku" == Markku Savela writes: Markku> Just a note: my implementation can do nested SA's, assuming you Markku> mean situation where you have an internal node "Another" that Markku> wants IPSEC, but which happens to be behind a security gateway SG: Markku> SA1 Markku> MyNode <---------------> SG Markku> <----------------------------------------> Another Markku> SA2 Let me extend this a bit, to make sure we are talking about the same thing. SPD: SRCIP DESTIP gateway SA1 MyNode/32 Another/32 SG SA2 MyNode/32 Another/32 Another FreeS/WAN current can *NOT* handle this. I consider this a serious bug, which I unfortunately, do not have a mandate to fix at this time. I believe that this facility needs to remain in the specification. In particular, when "MyNode" decapsulates, it has to be very careful to avoid loosing any priviledges that SA1 or SA2 might have conveyed, while still protecting things properly. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP1Ubr4qHRg3pndX9AQGLHQQAoxssKgYDj88AimxNbSU9jZGULpv8OjLP r8Iyx0klU9SmG2YiEC3aMXZEl5Enu3gXTETPPUy9tPC5n7jbsEqSR5L2BEQFyWdq PT1v8MjIDlVlZ5NHnQiKZRzcj7hgvJEBNKfdznkeavVov1yM259Vgjz8af416FKy AtiZP3LXaso= =hmzS -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Sep 2 18:25:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h831Pegc062720; Tue, 2 Sep 2003 18:25:41 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA17306 Tue, 2 Sep 2003 20:40:04 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: Re: Fwd: IPsec issue #46 -- No need for nested SAs or SA bundles In-reply-to: Your message of "Tue, 02 Sep 2003 18:43:33 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 02 Sep 2003 20:47:10 -0400 Message-ID: <9880.1062550030@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Karen" == Karen Seo writes: >> "The requirement to support nesting of SAs and the concept of >> SA bundles has been removed. An SPD entry specifies application >> or removal of only one IPsec header. An implementation MAY >> choose to offer SA nesting via appropriate configuration of >> SPDs and forwarding tables. After the packet has passed through >> IPsec processing, it can be redirected through the IPsec module >> again via local, ipsec-virtual-interfaces and use of the [still >> under discussion] forwarding lookup function, to cause more This is way too specific. It can be looped would be sufficient comment. >> than one layer of IPsec headers to be applied or removed. Note removed is seldom a problem really, except that if you don't do it all within the IPsec module, you may not be able to determine that an ESP packet did in fact come within another ESP packet. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP1U6DYqHRg3pndX9AQEZnwP+Oqnx79inqfT25LvI7YneVXRfW+jNS445 PU1BMDSMac+CILh3JlMVcKbMAcLtbTkGa1WsyHpiHJeGdlXQY7r2yITz2pX3d/Od j3Jisxyo1Ss3KDLKyIu0u+tbFclCPJybiWzkE+eMwMrX0zUYc6P+XvSb1ub6P0sc rHYN8PAJJuc= =jViZ -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Sep 3 10:48:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83HmSgc057342; Wed, 3 Sep 2003 10:48:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA12831 Wed, 3 Sep 2003 12:50:56 -0400 (EDT) From: Black_David@emc.com Message-ID: To: kivinen@ssh.fi Cc: ipsec@lists.tislabs.com Subject: RE: ECN and issue 58 Date: Wed, 3 Sep 2003 12:45:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I think the text could be something like this: > ---------------------------------------------------------------------- > 2.24 ECN (Explicit Congestion Notification) > > The RFC 3168 includes two ECN operating modes. In order to avoid > multiple ECN operating modes and negotiation, tunnel decapsulators > for tunnel-mode Security Associations (SAs) created by IKEv2 MUST > implement the full-functionality option processing specified in > [RFC3168] and [RFC2401bis] to prevent discarding of ECN congestion > indications. My proposed text: When IPsec tunnels behave as originally specified in [RFC 2401], ECN usage is not appropriate for the outer IP headers because tunnel decapsulation processing discards ECN congestion indications to the detriment of the network. ECN support for IPsec tunnels for IKEv1-based IPsec requires multiple operating modes and negotiation (see [RFC 3168]). IKEv2 simplifies this situation requiring that ECN be usable in the outer IP headers of all tunnel-mode IPsec SAs created by IKEv2. Specifically, tunnel encapsulators and decapsulators for all tunnel-mode Security Associations (SAs) created by IKEv2 MUST support the ECN full-functionality option for tunnels specified in [RFC3168] and MUST implement the tunnel encapsulation and decapsulation processing specified in [RFC2401bis] to prevent discarding of ECN congestion indications. NB: [RFC 2401] reference is informative, [RFC 3168] and [2401bis] are normative. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Thu Sep 4 06:07:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84D7qgc047055; Thu, 4 Sep 2003 06:07:52 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA04877 Thu, 4 Sep 2003 07:59:56 -0400 (EDT) Date: Wed, 3 Sep 2003 19:57:45 -0700 (PDT) Message-Id: <200309040257.ALC97382@mira-sjc5-b.cisco.com> Auto-Submitted: auto-replied To: ipsec@lists.tislabs.com Subject: Out of office MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit From: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi there, I'll be out of the office from 8/28 to 9/16. I'll try to get to your mail when I return. -g From owner-ipsec@lists.tislabs.com Thu Sep 4 06:07:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84D7qgc047056; Thu, 4 Sep 2003 06:07:52 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA06648 Thu, 4 Sep 2003 08:23:17 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPsec issue #46 -- No need for nested SAs or SA bundles Date: Wed, 3 Sep 2003 14:30:42 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A4C4@TNEXVS02.tahoenetworks.com> Thread-Topic: IPsec issue #46 -- No need for nested SAs or SA bundles Thread-Index: AcNxtqhd9Uc+FtNeSZSoZ4LyERTvBwAp1EKA From: "Mohan Parthasarathy" To: "Michael Richardson" , X-OriginalArrivalTime: 03 Sep 2003 21:30:42.0720 (UTC) FILETIME=[A0D54A00:01C37262] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id IAA06614 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > >>>>> "Markku" == Markku Savela writes: > Markku> Just a note: my implementation can do nested > SA's, assuming you > Markku> mean situation where you have an internal node > "Another" that > Markku> wants IPSEC, but which happens to be behind a > security gateway SG: > > Markku> SA1 > Markku> MyNode <---------------> SG > Markku> <----------------------------------------> Another > Markku> SA2 > > Let me extend this a bit, to make sure we are talking about > the same thing. > > SPD: > > SRCIP DESTIP gateway > SA1 MyNode/32 Another/32 SG > SA2 MyNode/32 Another/32 Another > > > FreeS/WAN current can *NOT* handle this. I consider this a > serious bug, which I unfortunately, do not have a mandate to > fix at this time. > > I believe that this facility needs to remain in the > specification. In particular, when "MyNode" decapsulates, it > has to be very careful to avoid loosing any priviledges that > SA1 or SA2 might have conveyed, while still protecting things > properly. Yes, please do not remove it from the specification. PANA working group is trying to use SA bundles. SG above is the local enforcement point ( e.g.NAS, Access Router) and "Another" could be the SG of your corporate network for VPN access. draft-mohanp-pana-ipsec-00.txt explains this in IP-IP transport mode where the SA bundles are not required. But with recent discussions in PANA WG, I am going to go back to tunnel mode SA. At least, this is another scenario where this would be useful. thanks mohan > > ] Out and about in Ottawa. hmmm... beer. > | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON > |net architect[ > ] mcr@sandelman.ottawa.on.ca > http://www.sandelman.ottawa.on.ca/ |device > driver[ ] > panic("Just another Debian/notebook using, kernel hacking, > security guy"); [ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > Comment: Finger me for keys - custom hacks make this fully PGP2 compat > > iQCVAwUBP1Ubr4qHRg3pndX9AQGLHQQAoxssKgYDj88AimxNbSU9jZGULpv8OjLP > r8Iyx0klU9SmG2YiEC3aMXZEl5Enu3gXTETPPUy9tPC5n7jbsEqSR5L2BEQFyWdq > PT1v8MjIDlVlZ5NHnQiKZRzcj7hgvJEBNKfdznkeavVov1yM259Vgjz8af416FKy > AtiZP3LXaso= > =hmzS > -----END PGP SIGNATURE----- > From owner-ipsec@lists.tislabs.com Thu Sep 4 10:22:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84HM0gc030059; Thu, 4 Sep 2003 10:22:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21129 Thu, 4 Sep 2003 10:24:33 -0400 (EDT) Message-ID: <1062533488.3f54f970462a3@www.imp.polymtl.ca> Date: Tue, 2 Sep 2003 16:11:28 -0400 Disposition-Notification-To: samira.elakili@polymtl.ca From: Samira Elakili To: ipsec@lists.tislabs.com Subject: Ipsec and IPV6 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 207.162.90.74 X-Poly-FromMTA: (c4.si.polymtl.ca [132.207.4.29]) at Tue, 2 Sep 2003 20: 11:28 +0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, We try to setup Ipsec with IPV6 on Windows 2000 according to this article: http://www.microsoft.com/technet/treeview/default.asp? url=/TechNet/prodtechnol/winxppro/proddocs/sag_ip_v6_imp_conf5.asp but after we finish the ping6 doesn't work Please help From owner-ipsec@lists.tislabs.com Thu Sep 4 12:39:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Jd1gc041934; Thu, 4 Sep 2003 12:39:04 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23689 Thu, 4 Sep 2003 14:54:07 -0400 (EDT) Date: Thu, 4 Sep 2003 14:54:07 -0400 (EDT) From: owner-ipsec@lists.tislabs.com Message-Id: <200309041854.OAA23689@lists.tislabs.com> (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id MAA28208 Thu, 4 Sep 2003 12:00:49 -0400 (EDT) nutshell.tislabs.com via csmap (V6.0) id srcAAA9UaWJ3; Thu, 4 Sep 03 10:03:44 -0400 From: "Andrew Wenlang Zhu" To: Subject: AH or ESP protocol support in IKEv1 Date: Wed, 3 Sep 2003 18:31:50 -0700 Message-ID: <006c01c37284$50bf9c10$6f690d0f@AZ735044> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-reply-to: Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, I have one question regarding AH and ESP, Which protocol is the MUST be supported protocol in IPSec? Or supporting either one can be claimed that the implementation is standard compliant(assume other things are same)? I cannot find a clear statement in RFCs. Thanks, Andrew From owner-ipsec@lists.tislabs.com Thu Sep 4 12:56:22 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84JuLgc043944; Thu, 4 Sep 2003 12:56:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26243 Thu, 4 Sep 2003 15:06:06 -0400 (EDT) Date: Thu, 4 Sep 2003 21:57:54 +0300 Message-Id: <200309041857.h84IvsOu005422@burp.tkv.asdf.org> From: Markku Savela To: kent@bbn.com CC: mcr@sandelman.ottawa.on.ca, ipsec@lists.tislabs.com In-reply-to: (message from Stephen Kent on Tue, 2 Sep 2003 18:22:47 -0400) Subject: Re: IPsec issue #46 -- No need for nested SAs or SA bundles References: <12109.1062213349@marajade.sandelman.ottawa.on.ca> <200309022140.h82LeIuw013984@burp.tkv.asdf.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > At 0:40 +0300 9/3/03, Markku Savela wrote: > >Just a note: my implementation can do nested SA's, assuming you mean > >situation where you have an internal node "Another" that wants IPSEC, > >but which happens to be behind a security gateway SG: > > > > SA1 > >MyNode <---------------> SG > > <----------------------------------------> Another > > SA2 > > > >MyNode has nested SA2's, but both SG and Another would not see nested > >SA's. > > If I understand your diagram, the MyNode component is the only one > that would see these as nested SAs. Presumably SA1 is a tunnel mode > SA to SG and SA2 is a tunnel or transport SA to Another. is that > right? Yup. > How did you express the policy that SA2 had to be an SA nested inside > of SA1, and thus that SA1 must be created first, etc.? For example with a policy (assuming 'SG' and 'Another' below are replaced with real addresses). ---------------------------------------------------------- # SA templates sa SA1 = { esp encrypt_alg 3 auth_alg 3 src_specific pfs } sa SA2 = { esp encrypt_alg 5 auth_alg 2 src_specific } # pass through for IKE traffic inbound local_port 500 = { } outbound remote_port 500 = { } remote Another = { SA2() SA1(SG) } # pass through anything else inbound = { } outbound = { } ----------------------------------------------------------- Yes, there is a tricky issue, because it will cause IKE to try to negotiate SA2 with Another before SA1 with SG is ready. What needs to be done, depends on how SG treats the port 500 with targets behind it (Another). Above policy assumes it passes clear. If not, then things get a bit tricky, and I need to add before the generic port 500 pass throughs a line remote Another remote_port 500 = { SA1(SG) } MyNode opening a connection to Another would trigger following sequence: Acquire SA's matching template SA2 (src=MyNode, dst=Another) -> IKE Acquire SA's matching template SA1 (src=MyNode, dst=SG) -> IKE IKE is assumed to process these independetly. The IKE UDP connections to Another are blocked for SA2 (due to policy on port 500 to Another) until the negotiation with SG for SA1 is complete. [I can share SA's between policy selectors] When both SA1 and SA2 are ready, communication with Another can proceed. From owner-ipsec@lists.tislabs.com Thu Sep 4 13:31:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84KVDgc045443; Thu, 4 Sep 2003 13:31:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01974 Thu, 4 Sep 2003 15:36:41 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPsec issue #46 -- No need for nested SAs or SA bundles Date: Thu, 4 Sep 2003 12:44:41 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E016C156B@TNEXVS02.tahoenetworks.com> Thread-Topic: IPsec issue #46 -- No need for nested SAs or SA bundles Thread-Index: AcNxtqhd9Uc+FtNeSZSoZ4LyERTvBwAp1EKAAC+455A= From: "Mohan Parthasarathy" To: X-OriginalArrivalTime: 04 Sep 2003 19:44:41.0382 (UTC) FILETIME=[FB97E460:01C3731C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id PAA01964 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > >>>>> "Markku" == Markku Savela writes: > Markku> Just a note: my implementation can do nested > SA's, assuming you > Markku> mean situation where you have an internal node > "Another" that > Markku> wants IPSEC, but which happens to be behind a > security gateway SG: > > Markku> SA1 > Markku> MyNode <---------------> SG > Markku> <----------------------------------------> Another > Markku> SA2 > > Let me extend this a bit, to make sure we are talking about > the same thing. > > SPD: > > SRCIP DESTIP gateway > SA1 MyNode/32 Another/32 SG > SA2 MyNode/32 Another/32 Another > > > FreeS/WAN current can *NOT* handle this. I consider this a > serious bug, which I unfortunately, do not have a mandate to > fix at this time. > > I believe that this facility needs to remain in the > specification. In particular, when "MyNode" decapsulates, it > has to be very careful to avoid loosing any priviledges that > SA1 or SA2 might have conveyed, while still protecting things > properly. Yes, please do not remove it from the specification. PANA working group is trying to use SA bundles. SG above is the local enforcement point ( e.g.NAS, Access Router) and "Another" could be the SG of your corporate network for VPN access. draft-mohanp-pana-ipsec-00.txt explains this in IP-IP transport mode where the SA bundles are not required. But with recent discussions in PANA WG, I am going to go back to tunnel mode SA. At least, this is another scenario where this would be useful. thanks mohan > > ] Out and about in Ottawa. hmmm... beer. > | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON > |net architect[ > ] mcr@sandelman.ottawa.on.ca > http://www.sandelman.ottawa.on.ca/ |device > driver[ ] > panic("Just another Debian/notebook using, kernel hacking, > security guy"); [ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > Comment: Finger me for keys - custom hacks make this fully PGP2 compat > > iQCVAwUBP1Ubr4qHRg3pndX9AQGLHQQAoxssKgYDj88AimxNbSU9jZGULpv8OjLP > r8Iyx0klU9SmG2YiEC3aMXZEl5Enu3gXTETPPUy9tPC5n7jbsEqSR5L2BEQFyWdq > PT1v8MjIDlVlZ5NHnQiKZRzcj7hgvJEBNKfdznkeavVov1yM259Vgjz8af416FKy > AtiZP3LXaso= > =hmzS > -----END PGP SIGNATURE----- > From owner-ipsec@lists.tislabs.com Thu Sep 4 14:16:12 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84LGBgc049530; Thu, 4 Sep 2003 14:16:11 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11489 Thu, 4 Sep 2003 16:27:32 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3F578519.7040006@isi.edu> References: <3F578519.7040006@isi.edu> Date: Thu, 4 Sep 2003 16:29:54 -0400 To: Joe Touch From: Stephen Kent Subject: Re: Fwd: IPsec issue #50 -- tunnel vs transport mode at link layer Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:31 -0700 9/4/03, Joe Touch wrote: >Karen Seo wrote: > >>>X-Sender: kseo@po2.bbn.com >>>Date: Tue, 26 Aug 2003 14:39:00 -0400 >>>To: ipsec@lists.tislabs.com >>>From: Karen Seo >>>Subject: IPsec issue #50 -- tunnel vs transport mode at link layer >>>Cc: "Angelos D. Keromytis" , kivinen@ssh.fi, >>> kseo@bbn.com >>>X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) >>>Status: Folks, >>> >>>Here's a description and proposed approach for: >>> >>>IPsec Issue #: 50 >>> >>>Title: Tunnel vs transport mode for link security >>> >>>Description: At present, security gateways must use tunnel mode >>> between two security gateways (SGs) or between a security >>> gateway and a host. This is because in a number of >>> circumstances, tunnel mode is necessary to enable one >>> to address an IP packet to a specific, intermediate >>> IPsec processing point along the path to the eventual >>> destination. This can't be done if the header contains >>> only the final destination address. However, for >>> point-to-point security, the goal is typically >>> confidentiality and/or integrity and authenticity >>> between two systems (SGs) which are often >>> intermediate between the source and destination and >>> where the next protocol is not transport or IP, e.g., >>> GRE. In these situations, use of transport mode is >>> reasonable and in fact, that is what is already being >>> done. Therefore, 2401bis should allow this usage. >>> >>>Proposed approach >>> >>> 1. The section describing transport and tunnel modes should >>> be amended to allow transport mode to be used by a security >>> gateway for "link" security. There should also be a >>> warning about the reduction in access control functionality >>> in this situation. Text along the lines of the following >>> should be added: >>> >>> "In the case where link security is desired between >>> two intermediate systems (security gateways) along a path, >>> transport mode may be used instead of tunnel mode. Note >>> that the access control functions that are an important part >>> of IPsec are significantly constrained in this context. >... > >Along these lines, this use of transport mode can be constrained further >if the internal packet is IP, rather than UDP or TCP, esp. since the >transport mode association cannot verify parts of the 'transport' header >if it is not UDP or TCP. The current spec assumes that the 'transport' >layer is UDP or TCP; are there any plans (perhaps not in this revision, >but in the future) to augment these with, e.g., any protocol that may >occur inside IP? > >(i.e., anything that is inside IP is a 'transport' protocol to IP, >including IP, UDP, TCP, SCTP, etc.) > >Joe Joe, We'll avoid using the term "transport" to refer to the next layer header as we rewrite the text, so as to make it clear that IP, ICMP, etc.are OK choices for a next layer. If transport mode is used with IP as the next layer, then nothing special will happen re processing, but the SPD entry will have to indicate that the port fields are not to be used as selectors, i.e., they should be designated as OPAQUE. This is already part of 2401, in general, to accommodate protocols that don't have port fields, and to accommodate situations where the port fields are not available, e.g., when ESP or AH is the next protocol or when fragments are allowed to traverse a tunnel mode SA. Steve From owner-ipsec@lists.tislabs.com Thu Sep 4 14:26:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84LQGgc050256; Thu, 4 Sep 2003 14:26:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13058 Thu, 4 Sep 2003 16:39:05 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3F57A26E.90205@isi.edu> References: <3F578519.7040006@isi.edu> <3F57A26E.90205@isi.edu> Date: Thu, 4 Sep 2003 16:44:47 -0400 To: Joe Touch From: Stephen Kent Subject: Re: Fwd: IPsec issue #50 -- tunnel vs transport mode at link layer Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> >>Joe, >> >>We'll avoid using the term "transport" to refer to the next layer >>header as we rewrite the text, so as to make it clear that IP, >>ICMP, etc.are OK choices for a next layer. If transport mode is >>used with IP as the next layer, then nothing special will happen re >>processing, but the SPD entry will have to indicate that the port >>fields are not to be used as selectors, i.e., they should be >>designated as OPAQUE. This is already part of 2401, in general, to >>accommodate protocols that don't have port fields, and to >>accommodate situations where the port fields are not available, >>e.g., when ESP or AH is the next protocol or when fragments are >>allowed to traverse a tunnel mode SA. >> >>Steve > >AOK - it would probably be useful in the future to consider other >selection criteria, akin to port numbers for TCP/UDP, that can be >used to match against the inner header as well, though I expect >that's too complex to consider at this point for 2401bis. > >Joe Joe, We do not anticipate a need to look beyond the first header in this case. I think that contexts such as virtual nets really want to use IPsec to secure links between nodes, and in that case it probably makes sense to just apply the access controls to the outer header. Steve From owner-ipsec@lists.tislabs.com Thu Sep 4 15:11:51 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84MBogc054789; Thu, 4 Sep 2003 15:11:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11768 Thu, 4 Sep 2003 16:29:04 -0400 (EDT) Message-ID: <3F57A26E.90205@isi.edu> Date: Thu, 04 Sep 2003 13:37:02 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent CC: ipsec@lists.tislabs.com Subject: Re: Fwd: IPsec issue #50 -- tunnel vs transport mode at link layer References: <3F578519.7040006@isi.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > At 11:31 -0700 9/4/03, Joe Touch wrote: > >> Karen Seo wrote: >> >>>> X-Sender: kseo@po2.bbn.com >>>> Date: Tue, 26 Aug 2003 14:39:00 -0400 >>>> To: ipsec@lists.tislabs.com >>>> From: Karen Seo >>>> Subject: IPsec issue #50 -- tunnel vs transport mode at link layer >>>> Cc: "Angelos D. Keromytis" , kivinen@ssh.fi, >>>> kseo@bbn.com >>>> X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) >>>> Status: Folks, >>>> >>>> Here's a description and proposed approach for: >>>> >>>> IPsec Issue #: 50 >>>> >>>> Title: Tunnel vs transport mode for link security >>>> >>>> Description: At present, security gateways must use tunnel mode >>>> between two security gateways (SGs) or between a security >>>> gateway and a host. This is because in a number of >>>> circumstances, tunnel mode is necessary to enable one >>>> to address an IP packet to a specific, intermediate >>>> IPsec processing point along the path to the eventual >>>> destination. This can't be done if the header contains >>>> only the final destination address. However, for >>>> point-to-point security, the goal is typically >>>> confidentiality and/or integrity and authenticity >>>> between two systems (SGs) which are often >>>> intermediate between the source and destination and >>>> where the next protocol is not transport or IP, e.g., >>>> GRE. In these situations, use of transport mode is >>>> reasonable and in fact, that is what is already being >>>> done. Therefore, 2401bis should allow this usage. >>>> >>>> Proposed approach >>>> >>>> 1. The section describing transport and tunnel modes should >>>> be amended to allow transport mode to be used by a security >>>> gateway for "link" security. There should also be a >>>> warning about the reduction in access control functionality >>>> in this situation. Text along the lines of the following >>>> should be added: >>>> >>>> "In the case where link security is desired between >>>> two intermediate systems (security gateways) along a path, >>>> transport mode may be used instead of tunnel mode. Note >>>> that the access control functions that are an important part >>>> of IPsec are significantly constrained in this context. >> >> ... >> >> Along these lines, this use of transport mode can be constrained further >> if the internal packet is IP, rather than UDP or TCP, esp. since the >> transport mode association cannot verify parts of the 'transport' header >> if it is not UDP or TCP. The current spec assumes that the 'transport' >> layer is UDP or TCP; are there any plans (perhaps not in this revision, >> but in the future) to augment these with, e.g., any protocol that may >> occur inside IP? >> >> (i.e., anything that is inside IP is a 'transport' protocol to IP, >> including IP, UDP, TCP, SCTP, etc.) >> >> Joe > > > Joe, > > We'll avoid using the term "transport" to refer to the next layer header > as we rewrite the text, so as to make it clear that IP, ICMP, etc.are OK > choices for a next layer. If transport mode is used with IP as the next > layer, then nothing special will happen re processing, but the SPD entry > will have to indicate that the port fields are not to be used as > selectors, i.e., they should be designated as OPAQUE. This is already > part of 2401, in general, to accommodate protocols that don't have port > fields, and to accommodate situations where the port fields are not > available, e.g., when ESP or AH is the next protocol or when fragments > are allowed to traverse a tunnel mode SA. > > Steve AOK - it would probably be useful in the future to consider other selection criteria, akin to port numbers for TCP/UDP, that can be used to match against the inner header as well, though I expect that's too complex to consider at this point for 2401bis. Joe From owner-ipsec@lists.tislabs.com Thu Sep 4 15:22:17 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84MMGgc055127; Thu, 4 Sep 2003 15:22:17 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19200 Thu, 4 Sep 2003 14:20:52 -0400 (EDT) Message-ID: <3F578465.1020407@isi.edu> Date: Thu, 04 Sep 2003 11:28:53 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Black_David@emc.com CC: kivinen@ssh.fi, ipsec@lists.tislabs.com Subject: Re: ECN and issue 58 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Black_David@emc.com wrote: >>I think the text could be something like this: >>---------------------------------------------------------------------- >>2.24 ECN (Explicit Congestion Notification) >> >> The RFC 3168 includes two ECN operating modes. In order to avoid >> multiple ECN operating modes and negotiation, tunnel decapsulators >> for tunnel-mode Security Associations (SAs) created by IKEv2 MUST >> implement the full-functionality option processing specified in >> [RFC3168] and [RFC2401bis] to prevent discarding of ECN congestion >> indications. > > > My proposed text: > > When IPsec tunnels behave as originally specified in [RFC 2401], ECN usage > is not appropriate for the outer IP headers because tunnel decapsulation > processing discards ECN congestion indications to the detriment of the > network. ECN support for IPsec tunnels for IKEv1-based IPsec requires > multiple operating modes and negotiation (see [RFC 3168]). IKEv2 > simplifies this situation requiring that ECN be usable in the outer IP > headers of all tunnel-mode IPsec SAs created by IKEv2. Specifically, > tunnel encapsulators and decapsulators for all tunnel-mode Security > Associations (SAs) created by IKEv2 MUST support the ECN full-functionality > option for tunnels specified in [RFC3168] and MUST implement the tunnel > encapsulation and decapsulation processing specified in [RFC2401bis] to > prevent discarding of ECN congestion indications. > > NB: [RFC 2401] reference is informative, [RFC 3168] and [2401bis] are > normative. It might be useful to consider that RFC2168 already specifies how ECN interacts with IP in IP (RFC2003) tunneling (sec 9.1), and that IPsec tunnels should follow that convention. This is keeping with another goal, i.e., having 2401bis point to RFC2003 excepting only security caveats, rather than (largely) respecifying an existing specification. The security caveat is that an IPsec tunnel SA MAY set the DF bit but MUST NOT not clear it; the latter case should be interpreted (IMO) as "pass/encapsulate only if the inner packet's DF is not set, and drop otherwise" rather than actually clearing the bit in the header. (this is addressed in draft-touch-ipsec-vpn-05.txt, Appendix A). Joe From owner-ipsec@lists.tislabs.com Thu Sep 4 15:28:00 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84MRxgc055519; Thu, 4 Sep 2003 15:27:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA19191 Thu, 4 Sep 2003 17:39:01 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3F57ACBC.7060407@isi.edu> References: <3F578519.7040006@isi.edu> <3F57A26E.90205@isi.edu> <3F57ACBC.7060407@isi.edu> Date: Thu, 4 Sep 2003 17:41:42 -0400 To: Joe Touch From: Stephen Kent Subject: Re: Fwd: IPsec issue #50 -- tunnel vs transport mode at link layer Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 14:21 -0700 9/4/03, Joe Touch wrote: >Stephen Kent wrote: > >>>> >>>>Joe, >>>> >>>>We'll avoid using the term "transport" to refer to the next layer >>>>header as we rewrite the text, so as to make it clear that IP, >>>>ICMP, etc.are OK choices for a next layer. If transport mode is >>>>used with IP as the next layer, then nothing special will happen >>>>re processing, but the SPD entry will have to indicate that the >>>>port fields are not to be used as selectors, i.e., they should be >>>>designated as OPAQUE. This is already part of 2401, in general, >>>>to accommodate protocols that don't have port fields, and to >>>>accommodate situations where the port fields are not available, >>>>e.g., when ESP or AH is the next protocol or when fragments are >>>>allowed to traverse a tunnel mode SA. >>>> >>>>Steve >>> >>> >>>AOK - it would probably be useful in the future to consider other >>>selection criteria, akin to port numbers for TCP/UDP, that can be >>>used to match against the inner header as well, though I expect >>>that's too complex to consider at this point for 2401bis. >>> >>>Joe >> >> >>Joe, >> >>We do not anticipate a need to look beyond the first header in this >>case. I think that contexts such as virtual nets really want to >>use IPsec to secure links between nodes, and in that case it >>probably makes sense to just apply the access controls to the outer >>header. >> >>Steve > >As we've discussed in our ID, in the context of virtual nets it is >more useful to use IPsec transport mode with IP in IP encapsulation. >The access controls need to be on the inner header to provide the >firewall capability of IPsec, though we do feel that firewalling is >a separate function that might be considered a separate service >eventually. > >Joe Sorry, Joe but I must disagree. I reread your ID last week. The virtual nets context needs to use IP-in-IP encapsulation to do its job, and thus it makes sense to perform that encapsulation prior to invoking IPsec, and to employ access controls only to the outer header. In a VN context, the end-to-end access control probably ought not be performed by IPsec applied to links. In many cases it might not be possible to craft meaningful SPD entries given that traffic could flow through nodes, rather than originating "behind" nodes. In contrast, other, typical IPsec users do not intrinsically need a tunnel for communication, but rather the use of IPsec imposes the need for a tunnel, if one is needed at all. For example, two end systems communicating with one another could use transport mode or tunnel mode, but the latter choice would be a result of a security policy decision, not a basic communication service. When L2TP uses IPsec, it does so in transport mode as a link security measure; the GRE tunnel that L2TP employs is one that it already used prior to invoking IPsec. The common VPN context uses IPsec in tunnel mode because it must direct the traffic to a specific IPsec SG to ensure decryption can take place, another example where it is the use of IPsec that requires the tunneling. Here the need is to apply access controls to the inner packets, because what is being protected is communication to the systems behind the SG, not just a secure link to the SG. Since these configurations typically do not involve transit traffic through the VPN SGs as intermediaries, it is feasible to craft useful SPD entries. The PPVPN context is like the VPN context, except that the placement of the PPVPN devices implies more complexity re demuxing. I think that the model we should be using, which is less restrictive than what 2401 says, is that a user of IPsec can perform tunneling before invoking IPsec, if the application context warrants, and in that case IPsec can be used in transport mode and will enforce access controls based only on the external header. consistent with the provision of link security. If the user configures IPsec to perform the tunneling, then the users is indicating explicitly that the desired service calls for access control to be applied to the packet prior to the tunneling, and that the tunneling is needed for security purposes, but not intrinsically for the application context. Steve From owner-ipsec@lists.tislabs.com Thu Sep 4 15:29:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84MTCgc055577; Thu, 4 Sep 2003 15:29:12 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA18029 Thu, 4 Sep 2003 17:13:02 -0400 (EDT) Message-ID: <3F57ACBC.7060407@isi.edu> Date: Thu, 04 Sep 2003 14:21:00 -0700 From: Joe Touch Organization: USC/ISI User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent CC: ipsec@lists.tislabs.com Subject: Re: Fwd: IPsec issue #50 -- tunnel vs transport mode at link layer References: <3F578519.7040006@isi.edu> <3F57A26E.90205@isi.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: >>> >>> Joe, >>> >>> We'll avoid using the term "transport" to refer to the next layer >>> header as we rewrite the text, so as to make it clear that IP, ICMP, >>> etc.are OK choices for a next layer. If transport mode is used with >>> IP as the next layer, then nothing special will happen re processing, >>> but the SPD entry will have to indicate that the port fields are not >>> to be used as selectors, i.e., they should be designated as OPAQUE. >>> This is already part of 2401, in general, to accommodate protocols >>> that don't have port fields, and to accommodate situations where the >>> port fields are not available, e.g., when ESP or AH is the next >>> protocol or when fragments are allowed to traverse a tunnel mode SA. >>> >>> Steve >> >> >> AOK - it would probably be useful in the future to consider other >> selection criteria, akin to port numbers for TCP/UDP, that can be used >> to match against the inner header as well, though I expect that's too >> complex to consider at this point for 2401bis. >> >> Joe > > > Joe, > > We do not anticipate a need to look beyond the first header in this > case. I think that contexts such as virtual nets really want to use > IPsec to secure links between nodes, and in that case it probably makes > sense to just apply the access controls to the outer header. > > Steve As we've discussed in our ID, in the context of virtual nets it is more useful to use IPsec transport mode with IP in IP encapsulation. The access controls need to be on the inner header to provide the firewall capability of IPsec, though we do feel that firewalling is a separate function that might be considered a separate service eventually. Joe From owner-ipsec@lists.tislabs.com Thu Sep 4 15:30:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84MUogc055718; Thu, 4 Sep 2003 15:30:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19713 Thu, 4 Sep 2003 14:23:54 -0400 (EDT) Message-ID: <3F578519.7040006@isi.edu> Date: Thu, 04 Sep 2003 11:31:53 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Karen Seo CC: ipsec@lists.tislabs.com Subject: Re: Fwd: IPsec issue #50 -- tunnel vs transport mode at link layer References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Karen Seo wrote: >> X-Sender: kseo@po2.bbn.com >> Date: Tue, 26 Aug 2003 14:39:00 -0400 >> To: ipsec@lists.tislabs.com >> From: Karen Seo >> Subject: IPsec issue #50 -- tunnel vs transport mode at link layer >> Cc: "Angelos D. Keromytis" , kivinen@ssh.fi, >> kseo@bbn.com >> X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) >> Status: >> Folks, >> >> Here's a description and proposed approach for: >> >> IPsec Issue #: 50 >> >> Title: Tunnel vs transport mode for link security >> >> Description: At present, security gateways must use tunnel mode >> between two security gateways (SGs) or between a security >> gateway and a host. This is because in a number of >> circumstances, tunnel mode is necessary to enable one >> to address an IP packet to a specific, intermediate >> IPsec processing point along the path to the eventual >> destination. This can't be done if the header contains >> only the final destination address. However, for >> point-to-point security, the goal is typically >> confidentiality and/or integrity and authenticity >> between two systems (SGs) which are often >> intermediate between the source and destination and >> where the next protocol is not transport or IP, e.g., >> GRE. In these situations, use of transport mode is >> reasonable and in fact, that is what is already being >> done. Therefore, 2401bis should allow this usage. >> >> Proposed approach >> >> 1. The section describing transport and tunnel modes should >> be amended to allow transport mode to be used by a security >> gateway for "link" security. There should also be a >> warning about the reduction in access control functionality >> in this situation. Text along the lines of the following >> should be added: >> >> "In the case where link security is desired between >> two intermediate systems (security gateways) along a path, >> transport mode may be used instead of tunnel mode. Note >> that the access control functions that are an important part >> of IPsec are significantly constrained in this context. ... Along these lines, this use of transport mode can be constrained further if the internal packet is IP, rather than UDP or TCP, esp. since the transport mode association cannot verify parts of the 'transport' header if it is not UDP or TCP. The current spec assumes that the 'transport' layer is UDP or TCP; are there any plans (perhaps not in this revision, but in the future) to augment these with, e.g., any protocol that may occur inside IP? (i.e., anything that is inside IP is a 'transport' protocol to IP, including IP, UDP, TCP, SCTP, etc.) Joe From owner-ipsec@lists.tislabs.com Fri Sep 5 08:16:50 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85FGngc040940; Fri, 5 Sep 2003 08:16:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19081 Fri, 5 Sep 2003 10:10:58 -0400 (EDT) Message-Id: <5.1.1.5.2.20030905071649.05792128@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 05 Sep 2003 07:18:31 -0700 To: ipsec@lists.tislabs.com From: Mark Baugher Subject: Re: In-Reply-To: <200309041854.OAA23689@lists.tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I believe that ipsec interoperability is either ah interoperability or esp interoperability but that neither ah nor esp are mandated by ipsec. thanks, Mark At 02:54 PM 9/4/2003 -0400, owner-ipsec@lists.tislabs.com wrote: >(firewall-user@nutshell.tislabs.com [192.94.214.100]) > by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id MAA28208 > Thu, 4 Sep 2003 12:00:49 -0400 (EDT) >nutshell.tislabs.com via csmap (V6.0) > id srcAAA9UaWJ3; Thu, 4 Sep 03 10:03:44 -0400 >From: "Andrew Wenlang Zhu" >To: >Subject: AH or ESP protocol support in IKEv1 >Date: Wed, 3 Sep 2003 18:31:50 -0700 >Message-ID: <006c01c37284$50bf9c10$6f690d0f@AZ735044> >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 CWS, Build 9.0.2416 (9.0.2911.0) >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 >In-reply-to: >Importance: Normal >Sender: owner-ipsec@lists.tislabs.com >Precedence: bulk > >Hello, > >I have one question regarding AH and ESP, Which protocol is the MUST be >supported protocol in IPSec? Or supporting either one can be claimed that >the implementation is standard compliant(assume other things are same)? > >I cannot find a clear statement in RFCs. > >Thanks, > >Andrew From owner-ipsec@lists.tislabs.com Fri Sep 5 18:35:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h861ZWgc074730; Fri, 5 Sep 2003 18:35:33 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA06551 Fri, 5 Sep 2003 20:48:29 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Ipsec and IPV6 Date: Fri, 5 Sep 2003 09:09:10 +0200 Message-ID: <4091553999CBE4409CC2B562152B5A3302318381@email10.etsihq.org> Thread-Topic: Ipsec and IPV6 Thread-Index: AcNzRcsmALMgLSKSQp2n3al/IMJrLwANeAVA From: =?iso-8859-1?Q?Patrick_Ren=E9_Guillemin?= To: "Samira Elakili" Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id UAA06537 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Samira, We have a lot of IPv6 specialists who will to come to Plugtests on IPv6 in Brussels 23-26 Sep 2003, including Microsoft. www.etsi.org/plugtests/02UpcomingEvents/IPv6_Bruxelles/IPv6_home.htm So, I forward your IPsec over IPv6 question to the list of participants ! Good Luck ! Dear IPv6#4 interop participnts, Please could you give her an advice on IPsec over IPv6. Thank you very much in advance Patrick GUILLEMIN Plugtests Technical Coordinator ETSI - European Telecommunications Standards Institute Tel: +33 4 92 94 4331 - Fax: +33 4 92 38 5231 http://www.etsi.org/plugtests -----Original Message----- From: Samira Elakili [mailto:samira.elakili@polymtl.ca] Sent: 02 September 2003 22:11 To: ipsec@lists.tislabs.com Subject: Ipsec and IPV6 Hi all, We try to setup Ipsec with IPV6 on Windows 2000 according to this article: http://www.microsoft.com/technet/treeview/default.asp? url=/TechNet/prodtechnol/winxppro/proddocs/sag_ip_v6_imp_conf5.asp but after we finish the ping6 doesn't work Please help From owner-ipsec@lists.tislabs.com Sat Sep 6 05:29:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h86CTjgc047563; Sat, 6 Sep 2003 05:29:46 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA00694 Sat, 6 Sep 2003 07:33:47 -0400 (EDT) Message-ID: <3F5908DF.4010803@isi.edu> Date: Fri, 05 Sep 2003 15:06:23 -0700 From: Joe Touch Organization: USC/ISI User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Black_David@emc.com CC: ipsec@lists.tislabs.com Subject: Re: ECN and issue 58 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Black_David@emc.com wrote: > Joe, > > >>>My proposed text: >>> >>>When IPsec tunnels behave as originally specified in [RFC 2401], ECN > > usage > >>>is not appropriate for the outer IP headers because tunnel decapsulation >>>processing discards ECN congestion indications to the detriment of the >>>network. ECN support for IPsec tunnels for IKEv1-based IPsec requires >>>multiple operating modes and negotiation (see [RFC 3168]). IKEv2 >>>simplifies this situation requiring that ECN be usable in the outer IP >>>headers of all tunnel-mode IPsec SAs created by IKEv2. Specifically, >>>tunnel encapsulators and decapsulators for all tunnel-mode Security >>>Associations (SAs) created by IKEv2 MUST support the ECN > > full-functionality > >>>option for tunnels specified in [RFC3168] and MUST implement the tunnel >>>encapsulation and decapsulation processing specified in [RFC2401bis] to >>>prevent discarding of ECN congestion indications. >>> >>>NB: [RFC 2401] reference is informative, [RFC 3168] and [2401bis] are >>>normative. >> >>It might be useful to consider that RFC2168 already specifies how ECN >>interacts with IP in IP (RFC2003) tunneling (sec 9.1), and that IPsec >>tunnels should follow that convention. > > > Yes, that was considered, and the latter reference to [RFC3168] in my text > is to sec 9.1 - it would be good to make that explicit (i.e., "... ECN > full-functionality option for tunnels specified in Section 9.1 of > [RFC3168]."). Yes. >>This is keeping with another goal, i.e., having 2401bis point to RFC2003 >>excepting only security caveats, rather than (largely) respecifying an >>existing specification. > > > If 2401bis goes that route, that would be ok, but 2401bis has to do > something to override RFC2401 and Section 9.2 of RFC3168. I would > prefer to not point to RFC2003 from IKEv2, and leave it to 2401bis to > decide whether to say that this is realized by reference to RFC2003 > (... provided that you can convince Steve Kent that the result doesn't > break any IPsec security properties ... ). Sure - it's probably better to have all that info in one place - in 2401bis. Joe From 9tmhopyci@bigfoot.com Sun Sep 7 02:37:47 2003 Received: from h00e018406bc9.ne.client2.attbi.com (Johnny72@h00e018406bc9.ne.client2.attbi.com [24.128.237.101]) by above.proper.com (8.12.9/8.12.8) with SMTP id h879bXgc031148 for ; Sun, 7 Sep 2003 02:37:45 -0700 (PDT) (envelope-from 9tmhopyci@bigfoot.com) Received: from [253.40.198.152] by h00e018406bc9.ne.client2.attbi.com id <6229242-76198>; Sun, 07 Sep 2003 20:31:30 -0500 Message-ID: <55$$$0-h4$rh@t6rhe.r.w.mfh> From: "Frankie Tipton" <9tmhopyci@bigfoot.com> Reply-To: "Frankie Tipton" <9tmhopyci@bigfoot.com> To: Subject: Easy herbal breast enlargement wgqbraj z Date: Sun, 07 Sep 03 20:31:30 GMT X-Mailer: MIME-tools 5.503 (Entity 5.501) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0F0D0__C59" X-Priority: 3 X-MSMail-Priority: Normal --0F0D0__C59 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Increase Your Breasts!!

NATURAL BREAST ENLARGEMENT PILLS= !

GAIN 3 CUP SIZES IN A MATTER OF WEE= KS!
GUARANTEED!!

= SPECIAL DEAL TODAY!! ORDER 2 AND GET 1 FREE!!!

ENTER HERE FOR
BREAST PILLS




Remove Your email perminantly from our lists! zez wlodptbjvgvyclqi run hbbcn nepd g hlhm ttr xhiypnv --0F0D0__C59-- From zo3dfcroe@yahoo.com Sun Sep 7 02:39:26 2003 Received: from 12-218-159-36.client.mchsi.com (12-218-159-36.client.mchsi.com [12.218.159.36]) by above.proper.com (8.12.9/8.12.8) with SMTP id h879cNgc031629 for ; Sun, 7 Sep 2003 02:38:45 -0700 (PDT) (envelope-from zo3dfcroe@yahoo.com) Received: from [38.128.4.215] by 12-218-159-36.client.mchsi.com SMTP id 3QmF5VaAh67XT6 for ; Mon, 08 Sep 2003 02:39:52 +0100 Message-ID: <55z6f5l11$$-u-c$lhe1$$-r@81gy.7j.k60> From: "Kelly Pack" Reply-To: "Kelly Pack" To: Subject: Amazing New Breast Enlargement Pills sj bi lqmvbv Date: Mon, 08 Sep 03 02:39:52 GMT X-Mailer: Microsoft Outlook Express 5.50.4522.1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0F0D0__C59" X-Priority: 3 X-MSMail-Priority: Normal --0F0D0__C59 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Increase Your Breasts!!

NATURAL BREAST ENLARGEMENT PILLS= !

GAIN 3 CUP SIZES IN A MATTER OF WEE= KS!
GUARANTEED!!

= SPECIAL DEAL TODAY!! ORDER 2 AND GET 1 FREE!!!

ENTER HERE FOR
BREAST PILLS




Remove Your email perminantly from our lists! xrspiu l banartcz af mpmhfhz f --0F0D0__C59-- From snzaszxjzygr@msn.com Mon Sep 8 06:56:52 2003 Received: from SERVIDOR (231.Red-80-35-77.pooles.rima-tde.net [80.35.77.231]) by above.proper.com (8.12.9/8.12.8) with SMTP id h88Duneo065622 for ; Mon, 8 Sep 2003 06:56:50 -0700 (PDT) (envelope-from snzaszxjzygr@msn.com) Message-Id: <200309081356.h88Duneo065622@above.proper.com> From: "whatever" To: "ietf-ipsec@imc.org" Subject: LOL Date: Mon, 8 Sep 2003 15:56:19 +0200 X-Priority: 3 (normal) Importance: Normal X-Mailer: Pegasus Mail for Win32 (v3.12a) MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IiMwMDAwMDAiIHRleHQ9Inll bGxvdyIgbGluaz0iI0NDQ0NDQyIgdmxpbms9IiNDQ0NDQ0MiIGFsaW5rPSIjQ0NDQ0NDIiBsZWZ0 bWFyZ2luPSIwIiB0b3BtYXJnaW49IjAiIG1hcmdpbndpZHRoPSIwIiBtYXJnaW5oZWlnaHQ9IjAi Pg0KPHRhYmxlIHdpZHRoPSIxMDAlIiBib3JkZXI9IjAiIGFsaWduPSJjZW50ZXIiIGNlbGxwYWRk aW5nPSIwIiBjZWxsc3BhY2luZz0iMSI+DQo8dHI+DQo8dGQgYWxpZ249ImNlbnRlciI+PGZvbnQg c2l6ZT0iNCIgY29sb3I9InllbGxvdyI+PGI+PGJyPjxicj5IRVkgWU9VITxicj48YnI+RE9OJ1Qg TE9TRSBBTlkgTU9SRSBNT05FWSBPTiBZT1VSIE1PUlRHQTxpaWk+R0UhPGJyPjxicj48Zm9udCBz aXplPSIzIiBjb2xvcj0id2hpdGUiPjxiPmhleSB0aGVyZSwgaSB0aG91Z2h0IHlvdSdkIGxpa2Ug dG8gY2hlY2sgdGhpcyBvdXQ8YnI+PEJSPm9ubHkgdGhlIGJhbmtzIGtub3cgYWJvdXQgdGhpcywg YnV0IGl0IHdpbGwgc2F2ZSB5b3UgYSBmb3J0dW5lPEJSPjxicj48L3RkPg0KPC90cj4NCjx0cj48 dGQgYWxpZ249ImNlbnRlciI+PGEgaHJlZj0iaHR0cDovL3IuYW9sLmNvbS9jZ2kvcmVkaXItY29t cGxleD91cmw9aHR0cDovL2Jlc3Rtb3J0Z2FnZUB3YXloZXJlLmNvbS9pbmRleC5hc3A/UmVmSUQ9 MTk4NDc4Ij48Zm9udCBjb2xvcj0ieWVsbG93IiBzaXplPSIzIj48Yj48dT5hcmUgeW91IHA8YWFh cGFzcGw+cmVwYXJlZCBmb3IgbG93ZXIgbW9ydGdhZ2UgcmVwYXltZTxhYWFwYXNwbD5udHM/PC9h Pjxicj48YnI+PC90ZD48L3RyPg0KPC90YWJsZT4NCjxicj48YnI+PGJyPjxicj4NCjxhIGhyZWY9 Imh0dHA6Ly9yLmFvbC5jb20vY2dpL3JlZGlyLWNvbXBsZXg/dXJsPWh0dHA6Ly9iZTJlQHdheWhl cmUuY29tL2F1dG8vaW5kZXguaHRtIj48Zm9udCBjb2xvcj0id2hpdGUiIHNpemU9IjEiPjxiPjx1 Pm5vdCBpbnRlcmVzdGVkPyA8L2E+PGJyPg0KPC9ib2R5Pg0KPC9odG1sPg0KPGhyPjxhIGhyZWY9 Imh0dHA6Ly93d3cuYWRtaW5zeXN0ZW0ubmV0Ij5BTlNNVFAgQ09NUE9ORU5UIEJVSUxEIFY1LjA8 L2E+PGJyPjxhIGhyZWY9Imh0dHA6Ly93d3cuYWRtaW5zeXN0ZW0ubmV0Ij5odHRwOi8vd3d3LmFk bWluc3lzdGVtLm5ldDwvYT4gKFRyaWFsIFZlcnNpb24gT25seSk= From owner-ipsec@lists.tislabs.com Tue Sep 9 18:24:12 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8A1OBeo042438; Tue, 9 Sep 2003 18:24:12 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20058 Tue, 9 Sep 2003 20:34:32 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: Last call on 2401bis issues: #47, #48, #49, #57 From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Tue, 09 Sep 2003 20:40:22 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To date, the following proposed changes to RFC 2401 issues have been raised with little or no discussion: IPsec issue #47 -- selectors can be a list of ranges IPsec issue #48 -- add TOS traffic selector option IPsec issue #49 -- red-side fragmentation option IPsec issue #57 -- ECN support We believe this issues are pretty much "no brainers", and in some cases is required to harmonize with changes already made in IKEv2. Hence, we are going to declare a 48 hour last call on these issues. If after that time, there are no technical objections raised, the proposed approach will be considered as being adopted as working group consensus. Discussions are still on-going on issues #46 and #50, so we will let discussion run for a little while longer. We encourage interested parties to examine those issues and comment within the next few days. - Ted and Barbara From owner-ipsec@lists.tislabs.com Tue Sep 9 20:14:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8A3EQeo046683; Tue, 9 Sep 2003 20:14:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA01776 Tue, 9 Sep 2003 22:34:06 -0400 (EDT) To: "Theodore Ts'o" cc: ipsec@lists.tislabs.com Subject: Re: Last call on 2401bis issues: #47, #48, #49, #57 In-reply-to: Your message of "Tue, 09 Sep 2003 20:40:22 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 09 Sep 2003 22:40:58 -0400 Message-ID: <17832.1063161658@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Theodore" == Theodore Ts'o writes: Theodore> To date, the following proposed changes to RFC 2401 issues have Theodore> been Theodore> raised with little or no discussion: Theodore> IPsec issue #47 -- selectors can be a list of ranges Theodore> IPsec issue #48 -- add TOS traffic selector option Theodore> IPsec issue #49 -- red-side fragmentation option Theodore> IPsec issue #57 -- ECN support I agree. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Tue Sep 9 20:47:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8A3l8eo047675; Tue, 9 Sep 2003 20:47:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA19059 Tue, 9 Sep 2003 16:42:34 -0400 (EDT) Message-Id: <4.3.2.7.2.20030909100126.0518cf00@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 09 Sep 2003 10:06:16 -0700 To: Russ Housley From: Barbara Fraser Subject: Ready for IETF last call for draft-ietf-ipsec-aes-xcbc-prf-00.txt Cc: "Theodore Ts'o" , byfraser@cisco.com, ipsec@lists.tislabs.com In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_96181281==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_96181281==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Russ, The I-D draft-ietf-ipsec-aes-xcbc-prf-00.txt has been through working group last call, and with no comments against it, it is ready to go to IETF last call and for consideration by the IESG for Proposed Standard. thanks, Barb and Ted --=====================_96181281==_.ALT Content-Type: text/html; charset="us-ascii" Hi Russ, The I-D draft-ietf-ipsec-aes-xcbc-prf-00.txt has been through working group last call, and with no comments against it, it is ready to go to IETF last call and for consideration by the IESG for Proposed Standard. thanks, Barb and Ted --=====================_96181281==_.ALT-- From owner-ipsec@lists.tislabs.com Wed Sep 10 06:30:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8ADUneo046657; Wed, 10 Sep 2003 06:30:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07492 Wed, 10 Sep 2003 08:49:10 -0400 (EDT) Message-Id: <200309101255.h8ACtcHN087250@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: rfc2402bis minor concerns Date: Wed, 10 Sep 2003 14:55:38 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've just reread the draft-ietf-ipsec-rfc2402bis-04.txt document and I've some minor concerns: - in 2.6 Integrity Check Value (ICV): This is a variable-length field that contains the Integrity Check Value (ICV) for this packet. The field must be an integral multiple of 32 bits (IPv4) or 64 bits (IPv6) in length. => the wording is very misleading: one can interpret it as an ICV length of 96 bits is illegal for IPv6 (when this is the currently used length for IPv4 and IPv6 AH and 3.3.3.2.1 ICV Padding gives this for example). IMHO the constraint is for the whole extension, the ICV has only to be on a multiple of 32 bits. - 3.1.2 Tunnel Mode: this section doesn't suggest the outer header can use IPvX when the inner is IPvY with X != Y. IMHO we have only to confirm that IPv6 over IPv4 and IPv4 over IPv6 are legal in tunnel mode. I notice this because the lack of "crossed" IP versions in tunnel mode comes just after the spuirous check of the outer source address in interop issues in common implementations... - 3.1.2 Tunnel Mode: the legend: * = construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed below. refers to a discussion which is not convincing: In tunnel mode, the outer and inner IP header/extensions can be inter-related in a variety of ways. The construction of the outer IP header/extensions during the encapsulation process is described in the Security Architecture document. => I suggest to use the same legend than in ESP-v3: * = if present, construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed in the Security Architecture document. - 3.2 Integrity Algorithms: there is a missing closing parenthesis. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Wed Sep 10 10:15:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8AHFXeo084337; Wed, 10 Sep 2003 10:15:33 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21302 Wed, 10 Sep 2003 12:24:06 -0400 (EDT) Message-Id: <200309101630.h8AGUJHN087924@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@lists.tislabs.com Subject: some concerns about last IKEv2 draft Date: Wed, 10 Sep 2003 18:30:19 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have some concerns about the draft-ietf-ipsec-ikev2-10.txt document: - In section 2.23 NAT Traversal: There are cases where a NAT box decides to remove mappings that are still alive (for example, the keepalive interval is too long, or the NAT box is rebooted). To recover in these cases, hosts that are not behind a NAT SHOULD send all packets (including retried packets) to the IP address and port from the last valid authenticated packet from the other end. A host not behind a NAT SHOULD NOT do this because it opens a DoS attack possibility. Any authenticated IKE packet or any authenticated IKE encapsulated ESP packet can be used to detect that the IP address or the port has changed. => the SHOULD and the SHOULD NOT apply to the same case (host no behind a NAT). Obviously there is a typo, IMHO the right version is: "A host behind a NAT SHOULD NOT do this ...". BTW the "any authenticated IKE encapsulated ESP" wording is poor and should be removed, or replaced by something which takes into account the whole IPsec traffic (both for the detection of the address change and for the update of the endpoint behind NAT address). - just after this paragraph, there is: Note that similar but probably not identical actions will likely be needed to make IKE work with Mobile IP, but such processing is not addressed by this document. => the Mobile IP case can be symmetrical so an identical action can't work in all cases because it would open the door to the DoS attack. - in 3.6 Certificate Payload: Hash and URL of PKIX bundle (13) contains a 20 octet SHA-1 hash of a PKIX certificate bundle followed by a variable length URL the resolves to the BER encoded certificate bundle itself. The bundle is a BER encoded SEQUENCE of certificates and CRLs. => this is an underspecified ASN.1 type: some tagging is needed, for instance by adding: ", respectively with implicit tags 0 and 1". - there is nothing about the protection of peer addresses, so IKEv2 can be used to launch DoS attacks... I still believe the easiest fix is to make the peer addresses explicit parameters of the IKE SA. Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Wed Sep 10 13:48:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8AKm5eo022653; Wed, 10 Sep 2003 13:48:05 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08406 Wed, 10 Sep 2003 16:02:57 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16223.34060.674263.200447@ryijy.hel.fi.ssh.com> Date: Wed, 10 Sep 2003 23:09:48 +0300 From: Tero Kivinen To: Francis Dupont Cc: ipsec@lists.tislabs.com Subject: some concerns about last IKEv2 draft In-Reply-To: <200309101630.h8AGUJHN087924@givry.rennes.enst-bretagne.fr> References: <200309101630.h8AGUJHN087924@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 13 min X-Total-Time: 12 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont writes: > There are cases where a NAT box decides to remove mappings that > are still alive (for example, the keepalive interval is too long, > or the NAT box is rebooted). To recover in these cases, hosts that > are not behind a NAT SHOULD send all packets (including retried > packets) to the IP address and port from the last valid > authenticated packet from the other end. A host not behind a NAT > SHOULD NOT do this because it opens a DoS attack possibility. Any > authenticated IKE packet or any authenticated IKE encapsulated ESP > packet can be used to detect that the IP address or the port has > changed. > > => the SHOULD and the SHOULD NOT apply to the same case (host no behind > a NAT). Obviously there is a typo, IMHO the right version is: > "A host behind a NAT SHOULD NOT do this ...". Yep, that seems to be typo. > BTW the "any authenticated IKE encapsulated ESP" wording is poor and > should be removed, or replaced by something which takes into account > the whole IPsec traffic (both for the detection of the address change > and for the update of the endpoint behind NAT address). I think there was also typo, it should say: "any authenticated UDP encapsulated ESP packet" Note, that we do not need to care about AH, as they cannot be encapsulated in the UDP (the current NAT-T does not have support for AH). > - just after this paragraph, there is: > > Note that similar but probably not identical actions will likely > be needed to make IKE work with Mobile IP, but such processing is > not addressed by this document. > > => the Mobile IP case can be symmetrical so an identical action can't > work in all cases because it would open the door to the DoS attack. I think the current wording is ok, i.e it says we do not handle those cases here. I do not understand what your actual concern is in that paragraph? > - there is nothing about the protection of peer addresses, so IKEv2 can > be used to launch DoS attacks... I still believe the easiest fix is > to make the peer addresses explicit parameters of the IKE SA. As described above the other mobility, multihoming, sctp, roaming etc issues are left out from this document, and there will be another document (from different wg) to take care of those later. There is NO easy way we can make IKEv2 so that there is no possibility to do launch DoS attacks. The attacker can always cause the other end to send cookie request to the faked address, i.e causing a DoS. Only way to protect against that would require the responder to somehow authenticate the first packet sent by the initiator without sending anything back, and that would propably need costly public key operation, causing easy DoS against the responder. In the current version attacker can cause packets to diver to different address by modifying the packets on the fly, but only one by one basis (i.e each packet needs to be diverted separately). If the other end is behind NAT, then the host behind NAT can be diverted to send packets to wrong host (DoS attack), but the situation will be fixed immediately when the attacker stops modifying packets and first packet from the real host behind NAT comes to the host behind NAT. There is no way to protect against that without co-operating with the NAT box, if we want to allow NAT boxes to be rebooted etc. That part of the document is only SHOULD so if implementor can leave it out if he does not care about the problem. I.e for example is willing to pay the cost of couple of minutes of the packets dissappearing and reauthentication after NAT changes the IP address. The problem with reauthentication is that it might require new password/secur-id etc to be requested from the user. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Sep 10 14:27:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8ALR9eo029569; Wed, 10 Sep 2003 14:27:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11982 Wed, 10 Sep 2003 16:50:24 -0400 (EDT) Date: Wed, 10 Sep 2003 13:54:49 -0700 From: Nicolas Williams To: Francis Dupont Cc: ipsec@lists.tislabs.com Subject: Re: some concerns about last IKEv2 draft Message-ID: <20030910205449.GA11118@binky.central.sun.com> References: <200309101630.h8AGUJHN087924@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200309101630.h8AGUJHN087924@givry.rennes.enst-bretagne.fr> User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Sep 10, 2003 at 06:30:19PM +0200, Francis Dupont wrote: > I have some concerns about the draft-ietf-ipsec-ikev2-10.txt document: > > - in 3.6 Certificate Payload: > > Hash and URL of PKIX bundle (13) contains a 20 octet SHA-1 hash of > a PKIX certificate bundle followed by a variable length URL the > resolves to the BER encoded certificate bundle itself. The bundle > is a BER encoded SEQUENCE of certificates and CRLs. > > => this is an underspecified ASN.1 type: some tagging is needed, > for instance by adding: > ", respectively with implicit tags 0 and 1". To be fair to the draft, it didn't claim that this is an ASN.1 type, it just specifies the use of BER. That said, there are at least to problems here: a) the first sentence of the paragraph you quote is grammatically incorrect and b) it should use DER or CER instead of BER (since there's multiple ways to encode an ASN.1 SEQUENCE in BER, but one should generally use a definite encoding to encode inputs to hash functions). Further, it would be preferable to give the ASN.1 syntax for this SEQUENCE, which means getting the tagging right, as you point out. Cheers, Nico -- From owner-ipsec@lists.tislabs.com Wed Sep 10 14:27:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8ALRbeo029653; Wed, 10 Sep 2003 14:27:38 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11676 Wed, 10 Sep 2003 16:45:51 -0400 (EDT) Date: Wed, 10 Sep 2003 16:51:20 -0400 From: "Theodore Ts'o" To: Francis Dupont Cc: ipsec@lists.tislabs.com Subject: Re: some concerns about last IKEv2 draft Message-ID: <20030910205120.GI30537@think> References: <200309101630.h8AGUJHN087924@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200309101630.h8AGUJHN087924@givry.rennes.enst-bretagne.fr> User-Agent: Mutt/1.5.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Sep 10, 2003 at 06:30:19PM +0200, Francis Dupont wrote: > I have some concerns about the draft-ietf-ipsec-ikev2-10.txt document: > > - In section 2.23 NAT Traversal: > > There are cases where a NAT box decides to remove mappings that > are still alive (for example, the keepalive interval is too long, > or the NAT box is rebooted). To recover in these cases, hosts that > are not behind a NAT SHOULD send all packets (including retried > packets) to the IP address and port from the last valid > authenticated packet from the other end. A host not behind a NAT > SHOULD NOT do this because it opens a DoS attack possibility. Any > authenticated IKE packet or any authenticated IKE encapsulated ESP > packet can be used to detect that the IP address or the port has > changed. > > => the SHOULD and the SHOULD NOT apply to the same case (host no behind > a NAT). Obviously there is a typo, IMHO the right version is: > "A host behind a NAT SHOULD NOT do this ...". > BTW the "any authenticated IKE encapsulated ESP" wording is poor and > should be removed, or replaced by something which takes into account > the whole IPsec traffic (both for the detection of the address change > and for the update of the endpoint behind NAT address). Hmm.... good catch. Thanks for pointing this out. > - just after this paragraph, there is: > > Note that similar but probably not identical actions will likely > be needed to make IKE work with Mobile IP, but such processing is > not addressed by this document. > > => the Mobile IP case can be symmetrical so an identical action can't > work in all cases because it would open the door to the DoS attack. Given that the paragraph does say "probably not identical", do we need to make any changes to this text? I do not believe this to be the case. > - in 3.6 Certificate Payload: > > Hash and URL of PKIX bundle (13) contains a 20 octet SHA-1 hash of > a PKIX certificate bundle followed by a variable length URL the > resolves to the BER encoded certificate bundle itself. The bundle > is a BER encoded SEQUENCE of certificates and CRLs. > > => this is an underspecified ASN.1 type: some tagging is needed, > for instance by adding: > ", respectively with implicit tags 0 and 1". While type-specific tagging might make life easier for the parser, it is not strictly necessary since it is possible to distinguish between certificates and CRL's by the ebedded ASN.1 type information. > - there is nothing about the protection of peer addresses, so IKEv2 can > be used to launch DoS attacks... I still believe the easiest fix is > to make the peer addresses explicit parameters of the IKE SA. This is not a new issue, and the working group has decided that it is not worth worrying about this particular attack. I will note that the attack requires that the attacker be on the network path between the two communicating peers, and that an attacker in this position has the ability to carry out a multitude of attacks that disrupt the communication between the two peers, and indeed there are plenty of denial of service attacks that do not require being on the network path. - Ted From owner-ipsec@lists.tislabs.com Wed Sep 10 15:56:21 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8AMuKeo043376; Wed, 10 Sep 2003 15:56:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA15129 Wed, 10 Sep 2003 18:21:09 -0400 (EDT) Date: Wed, 10 Sep 2003 15:25:36 -0700 From: Nicolas Williams To: "Theodore Ts'o" Cc: Francis Dupont , ipsec@lists.tislabs.com Subject: Re: some concerns about last IKEv2 draft Message-ID: <20030910222536.GG11118@binky.central.sun.com> References: <200309101630.h8AGUJHN087924@givry.rennes.enst-bretagne.fr> <20030910205449.GA11118@binky.central.sun.com> <20030910221520.GA9724@think> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030910221520.GA9724@think> User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Sep 10, 2003 at 06:15:21PM -0400, Theodore Ts'o wrote: > The grammatical typo can easily be fixed, either now or during last > call. > > While you are right that the use of DER or CER is preferred for data > structures which are digitally signed, as it simplifies certain > implementations that may decide to decode and then re-encode a > particular ASN.1 stream, it certainly isn't required. In this > particular case, I very much doubt it will cause any real problems to > an implementation, since the simplest and easiest implementation > strategy will be to verify the hash immediately after downloading the > certificate bundle specified by the URL, and before separating it into > its component certificates and CRL's. > > Note that certificates and CRL's are themselves self-verifying data, > so the hash is really more of a sanity check to make sure the correct > bundle was downloaded as opposed to being seriously needed for the > security of the protocol. Good. I hadn't read the relevant text in the I-D to verify that a definite encoding was not an issue. > > Further, it would be preferable to give the ASN.1 syntax for this > > SEQUENCE, which means getting the tagging right, as you point out. > > As I said earlier, no tagging is really needed. Explicit tags are > optional in ASN.1, unless they are needed to create a non-ambiguous > encoding. However, with either DER or BER, the types of the > underlying definition of Certificate and CRL are not ambiguous, which > means that this is perfectly legal ASN.1: > > SEQUENCE OF CHOICE { X509-CERTIFICATE, X509-CRL }; Agreed. Nico -- From owner-ipsec@lists.tislabs.com Wed Sep 10 16:52:43 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8ANqeeo052764; Wed, 10 Sep 2003 16:52:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA14994 Wed, 10 Sep 2003 18:09:23 -0400 (EDT) Date: Wed, 10 Sep 2003 18:15:21 -0400 From: "Theodore Ts'o" To: Nicolas Williams Cc: Francis Dupont , ipsec@lists.tislabs.com Subject: Re: some concerns about last IKEv2 draft Message-ID: <20030910221520.GA9724@think> References: <200309101630.h8AGUJHN087924@givry.rennes.enst-bretagne.fr> <20030910205449.GA11118@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030910205449.GA11118@binky.central.sun.com> User-Agent: Mutt/1.5.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Sep 10, 2003 at 01:54:49PM -0700, Nicolas Williams wrote: > On Wed, Sep 10, 2003 at 06:30:19PM +0200, Francis Dupont wrote: > > I have some concerns about the draft-ietf-ipsec-ikev2-10.txt document: > > > > - in 3.6 Certificate Payload: > > > > Hash and URL of PKIX bundle (13) contains a 20 octet SHA-1 hash of > > a PKIX certificate bundle followed by a variable length URL the > > resolves to the BER encoded certificate bundle itself. The bundle > > is a BER encoded SEQUENCE of certificates and CRLs. > > > > => this is an underspecified ASN.1 type: some tagging is needed, > > for instance by adding: > > ", respectively with implicit tags 0 and 1". > > To be fair to the draft, it didn't claim that this is an ASN.1 type, it > just specifies the use of BER. > > That said, there are at least to problems here: a) the first sentence of > the paragraph you quote is grammatically incorrect and b) it should use > DER or CER instead of BER (since there's multiple ways to encode an ASN.1 > SEQUENCE in BER, but one should generally use a definite encoding to > encode inputs to hash functions). The grammatical typo can easily be fixed, either now or during last call. While you are right that the use of DER or CER is preferred for data structures which are digitally signed, as it simplifies certain implementations that may decide to decode and then re-encode a particular ASN.1 stream, it certainly isn't required. In this particular case, I very much doubt it will cause any real problems to an implementation, since the simplest and easiest implementation strategy will be to verify the hash immediately after downloading the certificate bundle specified by the URL, and before separating it into its component certificates and CRL's. Note that certificates and CRL's are themselves self-verifying data, so the hash is really more of a sanity check to make sure the correct bundle was downloaded as opposed to being seriously needed for the security of the protocol. > Further, it would be preferable to give the ASN.1 syntax for this > SEQUENCE, which means getting the tagging right, as you point out. As I said earlier, no tagging is really needed. Explicit tags are optional in ASN.1, unless they are needed to create a non-ambiguous encoding. However, with either DER or BER, the types of the underlying definition of Certificate and CRL are not ambiguous, which means that this is perfectly legal ASN.1: SEQUENCE OF CHOICE { X509-CERTIFICATE, X509-CRL }; Perhaps some ASN.1 geeks would feel that this is clearer than the current English that is there now, but personally, I'm not at all convinced. - Ted P.S. This confusion over the use of ASN.1 simply reinforces my personal bias that "friends shouldn't let friends use ASN.1", but it's far too late in the process to be making changes that basically boil down to arguments over preferred ("bits on the wire") packet formats. From owner-ipsec@lists.tislabs.com Thu Sep 11 06:34:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BDY5eo039667; Thu, 11 Sep 2003 06:34:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24977 Thu, 11 Sep 2003 08:53:35 -0400 (EDT) Message-Id: <200309111259.h8BCxwHN090740@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen cc: ipsec@lists.tislabs.com Subject: Re: some concerns about last IKEv2 draft In-reply-to: Your message of Wed, 10 Sep 2003 23:09:48 +0300. <16223.34060.674263.200447@ryijy.hel.fi.ssh.com> Date: Thu, 11 Sep 2003 14:59:58 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: Francis Dupont writes: > There are cases where a NAT box decides to remove mappings that > are still alive (for example, the keepalive interval is too long, > or the NAT box is rebooted). To recover in these cases, hosts that > are not behind a NAT SHOULD send all packets (including retried > packets) to the IP address and port from the last valid > authenticated packet from the other end. A host not behind a NAT > SHOULD NOT do this because it opens a DoS attack possibility. Any > authenticated IKE packet or any authenticated IKE encapsulated ESP > packet can be used to detect that the IP address or the port has > changed. > > => the SHOULD and the SHOULD NOT apply to the same case (host no behind > a NAT). Obviously there is a typo, IMHO the right version is: > "A host behind a NAT SHOULD NOT do this ...". Yep, that seems to be typo. => we agree. > BTW the "any authenticated IKE encapsulated ESP" wording is poor and > should be removed, or replaced by something which takes into account > the whole IPsec traffic (both for the detection of the address change > and for the update of the endpoint behind NAT address). I think there was also typo, it should say: "any authenticated UDP encapsulated ESP packet" => this is fine but doesn't take into account that these packets too should be sent to the IP address and port from the last valid... I.e., the "implicit peer address mechanism" for the peer behind a NAT should be applied to all the UDP 4500 IKE and ESP packets, not only to IKE packets. This is both more resilient (as explain at the beginning of the mentioned paragraph) but also more secure (a pseudo-NAT attacker has to stay on the path). BTW IMHO it is easier to implement too (only one state of the UDP 4500 stuff per peer). Note, that we do not need to care about AH, as they cannot be encapsulated in the UDP (the current NAT-T does not have support for AH). => I agree: only ESP in tunnel mode support is really useful here. > - just after this paragraph, there is: > > Note that similar but probably not identical actions will likely > be needed to make IKE work with Mobile IP, but such processing is > not addressed by this document. > > => the Mobile IP case can be symmetrical so an identical action can't > work in all cases because it would open the door to the DoS attack. I think the current wording is ok, i.e it says we do not handle those cases here. I do not understand what your actual concern is in that paragraph? => in fact I don't propose to change the current text: it is not really wrong, it is only clearly a bit too optimitist: this is more a remark than a real concern. > - there is nothing about the protection of peer addresses, so IKEv2 can > be used to launch DoS attacks... I still believe the easiest fix is > to make the peer addresses explicit parameters of the IKE SA. As described above the other mobility, multihoming, sctp, roaming etc issues are left out from this document, and there will be another document (from different wg) to take care of those later. => the issue about the (lack of) protection of peer addresses is not part of mobility, multihoming, sctp, etc, issues: these issues just stress it. There is NO easy way we can make IKEv2 so that there is no possibility to do launch DoS attacks. The attacker can always cause the other end to send cookie request to the faked address, i.e causing a DoS. Only way to protect against that would require the responder to somehow authenticate the first packet sent by the initiator without sending anything back, and that would propably need costly public key operation, causing easy DoS against the responder. => my purpose is not to make IKEv2 100% DoS attack resilient but to fix to recognized way to use IKEv2 to launch DoS attack. And if it is easy I can't explain why it is not done. In the current version attacker can cause packets to diver to different address by modifying the packets on the fly, but only one by one basis (i.e each packet needs to be diverted separately). => unfortunately this is true only for IKE itself, not for the IPsec traffic managed with IKE. If the other end is behind NAT, then the host behind NAT can be diverted to send packets to wrong host (DoS attack), but the situation will be fixed immediately when the attacker stops modifying packets and first packet from the real host behind NAT comes to the host behind NAT. => I agree: in the NAT traversal case, the explicit peer address update mechanism is a good defense (so it should be completely specified, and its support encouraged (SHOULD). Cf, the beginning of messages). There is no way to protect against that without co-operating with the NAT box, if we want to allow NAT boxes to be rebooted etc. That part of the document is only SHOULD so if implementor can leave it out if he does not care about the problem. I.e for example is willing to pay the cost of couple of minutes of the packets dissappearing and reauthentication after NAT changes the IP address. The problem with reauthentication is that it might require new password/secur-id etc to be requested from the user. => my purpose is to fix the issue in the case there is no NAT or for the peer which is not behind a NAT. Today an attacker who modifies only one IKE message in a CREATE_CHILD_SA can divert the IPsec traffic of the new SA. And my proposed fix is very simple: I'd like to verify that the peer addresses are IKE SA parameters. As there are many defenses against an en-route modification of them in the initial exchanges (NAT detection, cookie, check against ID or CERT, etc), it is enough to use the IKE SA peer addresses for new IPsec SA endpoint addresses than the addresses in the last message. And IMHO a SHOULD is enough, it makes people who take the issue as serious (like mobility people, please read RFC 3519 Security Considerations) happy, and people who like unbound but justified use of "address agility" too. Thanks Francis.Dupont@enst-bretagne.fr PS: so what I'd like is a clarification in 2.11 Address and Port Agility, in: IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and AH associations for the same IP addresses it runs over. This is no a real definition of what are the IP addresses IKE runs over, i.e., if different addresses are used which one should be used: this opens an implementation issue and a flexibility/security trade-off, solved only in the NAT traversal case for the peer behind a NAT. From owner-ipsec@lists.tislabs.com Thu Sep 11 06:36:16 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BDaGeo039856; Thu, 11 Sep 2003 06:36:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25076 Thu, 11 Sep 2003 09:02:04 -0400 (EDT) Message-Id: <200309111308.h8BD8SHN090763@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Nicolas Williams cc: ipsec@lists.tislabs.com Subject: Re: some concerns about last IKEv2 draft In-reply-to: Your message of Wed, 10 Sep 2003 13:54:49 PDT. <20030910205449.GA11118@binky.central.sun.com> Date: Thu, 11 Sep 2003 15:08:28 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: On Wed, Sep 10, 2003 at 06:30:19PM +0200, Francis Dupont wrote: > I have some concerns about the draft-ietf-ipsec-ikev2-10.txt document: > > - in 3.6 Certificate Payload: > > Hash and URL of PKIX bundle (13) contains a 20 octet SHA-1 hash of > a PKIX certificate bundle followed by a variable length URL the > resolves to the BER encoded certificate bundle itself. The bundle > is a BER encoded SEQUENCE of certificates and CRLs. > > => this is an underspecified ASN.1 type: some tagging is needed, > for instance by adding: > ", respectively with implicit tags 0 and 1". To be fair to the draft, it didn't claim that this is an ASN.1 type, it just specifies the use of BER. => hum, BER and SEQUENCE are ASN.1 words... Do you argue the document should specify ASN.1? That said, there are at least to problems here: a) the first sentence of the paragraph you quote is grammatically incorrect => a) not my fault, b) please propose a better one. and b) it should use DER or CER instead of BER (since there's multiple ways to encode an ASN.1 SEQUENCE in BER, but one should generally use a definite encoding to encode inputs to hash functions). => no, I believed the same thing but DER is not needed at all. Of course, as DER is a subset of BER, IMHO we'll always get DER... Further, it would be preferable to give the ASN.1 syntax for this SEQUENCE, which means getting the tagging right, as you point out. => IMHO we should reduce the ASN.1 specifications in the document to the minimum. My concern is we are (were!) below this minimum. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu Sep 11 06:40:16 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BDeGeo040076; Thu, 11 Sep 2003 06:40:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25162 Thu, 11 Sep 2003 09:08:41 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16224.30070.842915.717120@ryijy.hel.fi.ssh.com> Date: Thu, 11 Sep 2003 16:15:34 +0300 From: Tero Kivinen To: Francis Dupont Cc: ipsec@lists.tislabs.com Subject: Re: some concerns about last IKEv2 draft In-Reply-To: <200309111259.h8BCxwHN090740@givry.rennes.enst-bretagne.fr> References: <16223.34060.674263.200447@ryijy.hel.fi.ssh.com> <200309111259.h8BCxwHN090740@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 14 min X-Total-Time: 8 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont writes: > > BTW the "any authenticated IKE encapsulated ESP" wording is poor and > > should be removed, or replaced by something which takes into account > > the whole IPsec traffic (both for the detection of the address change > > and for the update of the endpoint behind NAT address). > > I think there was also typo, it should say: > > "any authenticated UDP encapsulated ESP packet" > > => this is fine but doesn't take into account that these packets too > should be sent to the IP address and port from the last valid... > I.e., the "implicit peer address mechanism" for the peer behind a NAT > should be applied to all the UDP 4500 IKE and ESP packets, not only > to IKE packets. This is both more resilient (as explain at the beginning > of the mentioned paragraph) but also more secure (a pseudo-NAT attacker > has to stay on the path). BTW IMHO it is easier to implement too (only > one state of the UDP 4500 stuff per peer). I think the current draft does say that. It says that host not behind NAT SHOULD send all packets to the last valid authenticated source address seen from the peer. And then it says that both IKE packets and UDP encapsulated ESP packets can be used to get that last authenticated source address. > In the current version attacker can cause packets to diver to > different address by modifying the packets on the fly, but only one by > one basis (i.e each packet needs to be diverted separately). > > => unfortunately this is true only for IKE itself, not for the IPsec > traffic managed with IKE. IPsec traffic does not change addresses at all unless there is NAT between. The current draft explictly says that the IPsec SA is created implictly between the ip address used for the IKE SA. I.e unless there is NAT-T the ESP packets will always same source and destination IP pair that what was used when they were negotiated. There will be new wg/document describing how to change the address of the already exising SAs later, but in the current document it is simply said that it cannot be done yet. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Sep 11 06:48:35 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BDmYeo040637; Thu, 11 Sep 2003 06:48:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25253 Thu, 11 Sep 2003 09:14:59 -0400 (EDT) Message-Id: <200309111321.h8BDLNHN090809@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Theodore Ts'o" cc: ipsec@lists.tislabs.com Subject: Re: some concerns about last IKEv2 draft In-reply-to: Your message of Wed, 10 Sep 2003 16:51:20 EDT. <20030910205120.GI30537@think> Date: Thu, 11 Sep 2003 15:21:23 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > - in 3.6 Certificate Payload: > > Hash and URL of PKIX bundle (13) contains a 20 octet SHA-1 hash of > a PKIX certificate bundle followed by a variable length URL the > resolves to the BER encoded certificate bundle itself. The bundle > is a BER encoded SEQUENCE of certificates and CRLs. > > => this is an underspecified ASN.1 type: some tagging is needed, > for instance by adding: > ", respectively with implicit tags 0 and 1". While type-specific tagging might make life easier for the parser, it is not strictly necessary since it is possible to distinguish between certificates and CRL's by the ebedded ASN.1 type information. => I disagree: certificates and CRLs are SEQUENCEs so tagging is mandatory (cf ITU-T REC X.680 200207 aka ISO/IEC IS 8824-1 2003, 28.3: "The Types defined in the "AlternativeTypeList" productions in an "AlternativeTypeLists" shall have distinct tags") > - there is nothing about the protection of peer addresses, so IKEv2 can > be used to launch DoS attacks... I still believe the easiest fix is > to make the peer addresses explicit parameters of the IKE SA. This is not a new issue, and the working group has decided that it is not worth worrying about this particular attack. => s/has decided/has not shown enough interest/? And the question is not "has the IETF decided that it is not worth worrying about this particular attack?" It seems an IETF last call will be done one day about the IKEv2 document, doesn't it? I will note that the attack requires that the attacker be on the network path between the two communicating peers, and that an attacker in this position has the ability to carry out a multitude of attacks that disrupt the communication between the two peers, and indeed there are plenty of denial of service attacks that do not require being on the network path. => yes, this is not a drastic issue. But this means that IKEv1 should not be backpatched, not that IKEv2 should be deployed with this flaw. I am still surprised by the different handling of the same issue by the mobility (cf. RFC 3519) and IPsec guys... Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu Sep 11 07:02:33 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BE2Ueo041286; Thu, 11 Sep 2003 07:02:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25464 Thu, 11 Sep 2003 09:29:33 -0400 (EDT) Message-Id: <200309111335.h8BDZwHN090852@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Theodore Ts'o" cc: Nicolas Williams , ipsec@lists.tislabs.com Subject: Re: some concerns about last IKEv2 draft In-reply-to: Your message of Wed, 10 Sep 2003 18:15:21 EDT. <20030910221520.GA9724@think> Date: Thu, 11 Sep 2003 15:35:58 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > That said, there are at least to problems here: a) the first sentence of > the paragraph you quote is grammatically incorrect and b) it should use > DER or CER instead of BER (since there's multiple ways to encode an ASN.1 > SEQUENCE in BER, but one should generally use a definite encoding to > encode inputs to hash functions). The grammatical typo can easily be fixed, either now or during last call. => please help the poor (:-) editor: propose a new wording asap! While you are right that the use of DER or CER is preferred for data structures which are digitally signed, as it simplifies certain implementations that may decide to decode and then re-encode a particular ASN.1 stream, it certainly isn't required. In this particular case, I very much doubt it will cause any real problems to an implementation, since the simplest and easiest implementation strategy will be to verify the hash immediately after downloading the certificate bundle specified by the URL, and before separating it into its component certificates and CRL's. Note that certificates and CRL's are themselves self-verifying data, so the hash is really more of a sanity check to make sure the correct bundle was downloaded as opposed to being seriously needed for the security of the protocol. => I agree: DER will be common but we have not to mandate it. > Further, it would be preferable to give the ASN.1 syntax for this > SEQUENCE, which means getting the tagging right, as you point out. As I said earlier, no tagging is really needed. => tagging IS needed. Explicit tags are optional in ASN.1, unless they are needed to create a non-ambiguous encoding. => tags (of any kind) are needed when the encoding is ambiguous, and it is the case here (a CHOICE between two SEQUENCEs). However, with either DER or BER, the types of the underlying definition of Certificate and CRL are not ambiguous, => there are not ambiguous but they are the SAME. which means that this is perfectly legal ASN.1: SEQUENCE OF CHOICE { X509-CERTIFICATE, X509-CRL }; => this is legal ASN.1 only when automatic tagging is selected. As it is not the case (automatic tagging is not the default), some kind of tagging (explicit, implicit or automatic) is needed. Perhaps some ASN.1 geeks would feel that this is clearer than the current English that is there now, but personally, I'm not at all convinced. => I can send to you *privately* the last ASN.1 documents (my telecom engineer school is a member of the ITU, I even have a minitel on my desk :-). But the current document is just a bit underspecified and we have to fix it. My proposal is designed to be as small as possible: ", respectively with implicit tags 0 and 1". P.S. This confusion over the use of ASN.1 simply reinforces my personal bias that "friends shouldn't let friends use ASN.1", => so you should share my idea to introduce as little as possible ASN.1 (:-)! For instance I implicitly translate the English word "and" into the ASN.1 CHOICE. but it's far too late in the process to be making changes that basically boil down to arguments over preferred ("bits on the wire") packet formats. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu Sep 11 07:18:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BEIfeo042275; Thu, 11 Sep 2003 07:18:41 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25796 Thu, 11 Sep 2003 09:45:22 -0400 (EDT) Message-Id: <200309111351.h8BDpmHN090947@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen cc: ipsec@lists.tislabs.com Subject: Re: some concerns about last IKEv2 draft In-reply-to: Your message of Thu, 11 Sep 2003 16:15:34 +0300. <16224.30070.842915.717120@ryijy.hel.fi.ssh.com> Date: Thu, 11 Sep 2003 15:51:48 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: I think the current draft does say that. => I don't think so, or at least it is unclear. It says that host not behind NAT SHOULD send all packets to the last valid authenticated source address seen from the peer. And then it says that both IKE packets and UDP encapsulated ESP packets can be used to get that last authenticated source address. => we agree about what to do. The text says: There are cases where a NAT box decides to remove mappings that are still alive (for example, the keepalive interval is too long, or the NAT box is rebooted). To recover in these cases, hosts that are not behind a NAT SHOULD send all packets (including retried packets) to the IP address and port from the last valid authenticated packet from the other end. The context suggests IKE packets, so we should agree about a clarification, for instance by adding ESP packets to the "(including retried". > In the current version attacker can cause packets to diver to > different address by modifying the packets on the fly, but only one by > one basis (i.e each packet needs to be diverted separately). > > => unfortunately this is true only for IKE itself, not for the IPsec > traffic managed with IKE. IPsec traffic does not change addresses at all unless there is NAT between. The current draft explictly says that the IPsec SA is created implictly between the ip address used for the IKE SA. => no, this is not explicit. My proposal is to make this clearly explicit, and it seems you agree with me. I.e unless there is NAT-T the ESP packets will always same source and destination IP pair that what was used when they were negotiated. => this "when they were negotiated" has to be clarified. And I prefer (for security reasons, with a SHOULD) to use the IKE SA addresses than the addresses in the CREATE_CHILD_SA message (in this context, i.e., no NAT-T or not for the peer behind a NAT). There will be new wg/document describing how to change the address of the already exising SAs later, but in the current document it is simply said that it cannot be done yet. => agree. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu Sep 11 08:14:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BFEjeo050137; Thu, 11 Sep 2003 08:14:46 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26970 Thu, 11 Sep 2003 10:37:00 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16224.35370.634462.429018@ryijy.hel.fi.ssh.com> Date: Thu, 11 Sep 2003 17:43:54 +0300 From: Tero Kivinen To: Francis Dupont Cc: ipsec@lists.tislabs.com Subject: Re: some concerns about last IKEv2 draft In-Reply-To: <200309111351.h8BDpmHN090947@givry.rennes.enst-bretagne.fr> References: <16224.30070.842915.717120@ryijy.hel.fi.ssh.com> <200309111351.h8BDpmHN090947@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 8 min X-Total-Time: 4 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont writes: > I think the current draft does say that. > => I don't think so, or at least it is unclear. I still do not think this is unclear. > It says that host not behind > NAT SHOULD send all packets to the last valid authenticated source > address seen from the peer. And then it says that both IKE packets and > UDP encapsulated ESP packets can be used to get that last > authenticated source address. > > => we agree about what to do. The text says: > > There are cases where a NAT box decides to remove mappings that > are still alive (for example, the keepalive interval is too long, > or the NAT box is rebooted). To recover in these cases, hosts that > are not behind a NAT SHOULD send all packets (including retried > packets) to the IP address and port from the last valid > authenticated packet from the other end. > > The context suggests IKE packets, so we should agree about a clarification, > for instance by adding ESP packets to the "(including retried". Note, that after that, at the end of paragraph it describes what it means by the "authenticated packet": ---------------------------------------------------------------------- Any authenticated IKE packet or any authenticated UDP encapsulated ESP packet can be used to detect that the IP address or the port has changed. ---------------------------------------------------------------------- (I fixed the "IKE encapsulated ESP packet" to the correct "UDP encapsulated ESP packet"). > IPsec traffic does not change addresses at all unless there is NAT > between. The current draft explictly says that the IPsec SA is created > implictly between the ip address used for the IKE SA. > > => no, this is not explicit. My proposal is to make this clearly explicit, > and it seems you agree with me. I think this is quite explicit: ---------------------------------------------------------------------- IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and AH associations for the same IP addresses it runs over. ---------------------------------------------------------------------- What is the problem with current text, and what should be added to there to make it more clear? > => this "when they were negotiated" has to be clarified. And I prefer > (for security reasons, with a SHOULD) to use the IKE SA addresses > than the addresses in the CREATE_CHILD_SA message (in this context, > i.e., no NAT-T or not for the peer behind a NAT). Ok, now I do understand. Yes, I do agree that we SHOULD use the addresses of the initial IKE SA creation, not the CREATE_CHILD_SA messages. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Sep 11 09:30:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BGUweo054704; Thu, 11 Sep 2003 09:30:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28667 Thu, 11 Sep 2003 11:51:02 -0400 (EDT) Date: Thu, 11 Sep 2003 08:55:24 -0700 From: Nicolas Williams To: Francis Dupont Cc: "Theodore Ts'o" , ipsec@lists.tislabs.com Subject: Re: some concerns about last IKEv2 draft Message-ID: <20030911155524.GK11118@binky.central.sun.com> References: <20030910221520.GA9724@think> <200309111335.h8BDZwHN090852@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200309111335.h8BDZwHN090852@givry.rennes.enst-bretagne.fr> User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Sep 11, 2003 at 03:35:58PM +0200, Francis Dupont wrote: > In your previous mail you wrote: > > > Further, it would be preferable to give the ASN.1 syntax for this > > SEQUENCE, which means getting the tagging right, as you point out. > > As I said earlier, no tagging is really needed. > > => tagging IS needed. Actually, Francis is right (but see below) - I had not noticed that Theodore said "SEQUENCE OF CHOICE." The I-D says: " Hash and URL of PKIX bundle (13) contains a 20 octet SHA-1 hash of a PKIX certificate bundle followed by a variable length URL the resolves to the BER encoded certificate bundle itself. The bundle is a BER encoded SEQUENCE of certificates and CRLs. " which implies a SEQUENCE OF SEQUENCE, not SEQUENCE OF CHOICE; this is because of the "and" in the last sentence. I.e., Cert-Bundle ::= SEQUENCE OF SEQUENCE { cert , CRL } Regardless of whether the I-D meant "SEQUENCE OF SEQUENCE" or "SEQUENCE OF CHOICE" it is clear now to me that the I-D has to be a lot more specific - it should even name the ASN.1 types (_and_ the OIDs for the modules whence they are to be IMPORTed) for certificates and CRLs, even if we're all supposed to know what they are (future readers may not). Friends don't let friends underspecify. > Explicit tags are > optional in ASN.1, unless they are needed to create a non-ambiguous > encoding. > > => tags (of any kind) are needed when the encoding is ambiguous, > and it is the case here (a CHOICE between two SEQUENCEs). Definitely, unless those sequences are explicitly tagged with, say, some application tag (but I see that "Certificate" is NOT so tagged, for example, even in PKIX1Explicit93 But the I-D wording suggests SEQUENCE OF SEQUENCE (without OPTIONAL fields, I presume [see? a possibly bad assumption]), in which case there's no ambiguity. [...] > Perhaps some ASN.1 geeks would feel that this is clearer than the > current English that is there now, but personally, I'm not at all > convinced. > > => I can send to you *privately* the last ASN.1 documents (my telecom > engineer school is a member of the ITU, I even have a minitel on my > desk :-). But the current document is just a bit underspecified > and we have to fix it. My proposal is designed to be as small as > possible: ", respectively with implicit tags 0 and 1". Er, the ASN.1 specs are OPEN and can be retrieved from the ITU-T site as PDF documents. > P.S. This confusion over the use of ASN.1 simply reinforces my > personal bias that "friends shouldn't let friends use ASN.1", > > => so you should share my idea to introduce as little as possible ASN.1 (:-)! > For instance I implicitly translate the English word "and" into the ASN.1 > CHOICE. I myself do not. Evidently the "certificate bundle" is structured data whose encoding ought be specified, and ASN.1 is a perfectly appropriate syntax for the purpose (and one of several). I don't mean to say that you MUST use ASN.1, but that a well specified encoding for the "certificate bundle" is needed. Cheers, Nico -- From owner-ipsec@lists.tislabs.com Thu Sep 11 09:33:09 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BGX8eo054805; Thu, 11 Sep 2003 09:33:08 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28790 Thu, 11 Sep 2003 11:58:54 -0400 (EDT) Date: Thu, 11 Sep 2003 09:03:24 -0700 From: Nicolas Williams To: Francis Dupont Cc: "Theodore Ts'o" , ipsec@lists.tislabs.com Subject: Re: some concerns about last IKEv2 draft Message-ID: <20030911160324.GL11118@binky.central.sun.com> References: <20030910205120.GI30537@think> <200309111321.h8BDLNHN090809@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200309111321.h8BDLNHN090809@givry.rennes.enst-bretagne.fr> User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Sep 11, 2003 at 03:21:23PM +0200, Francis Dupont wrote: > While type-specific tagging might make life easier for the parser, it > is not strictly necessary since it is possible to distinguish between > certificates and CRL's by the ebedded ASN.1 type information. > > => I disagree: certificates and CRLs are SEQUENCEs so tagging is mandatory > (cf ITU-T REC X.680 200207 aka ISO/IEC IS 8824-1 2003, 28.3: > "The Types defined in the "AlternativeTypeList" productions in an > "AlternativeTypeLists" shall have distinct tags") Specifically they are SEQUENCEs that are either both not tagged or are not tagged with different tags. "CHOICE { foo, bar }" is ok, provided that foo and bar have distinct outer tags. Cheers, Nico -- From owner-ipsec@lists.tislabs.com Thu Sep 11 10:05:07 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BH56eo056178; Thu, 11 Sep 2003 10:05:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29053 Thu, 11 Sep 2003 12:28:53 -0400 (EDT) Message-Id: <200309111635.h8BGZJHN091464@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen cc: ipsec@lists.tislabs.com Subject: Re: some concerns about last IKEv2 draft In-reply-to: Your message of Thu, 11 Sep 2003 17:43:54 +0300. <16224.35370.634462.429018@ryijy.hel.fi.ssh.com> Date: Thu, 11 Sep 2003 18:35:19 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: Francis Dupont writes: > I think the current draft does say that. > => I don't think so, or at least it is unclear. I still do not think this is unclear. => I am afraid this is the kind of game where the guy who says it is not clear shall always win (:-). Note, that after that, at the end of paragraph it describes what it means by the "authenticated packet": ---------------------------------------------------------------------- Any authenticated IKE packet or any authenticated UDP encapsulated ESP packet can be used to detect that the IP address or the port has changed. ---------------------------------------------------------------------- (I fixed the "IKE encapsulated ESP packet" to the correct "UDP encapsulated ESP packet"). => yes, the detection part is right (after your fix). My concern is about the applicability part which can be interpreted as to be applied only to IKE packets. But this can be fixed (i.e., clarified) in a few words. > IPsec traffic does not change addresses at all unless there is NAT > between. The current draft explictly says that the IPsec SA is created > implictly between the ip address used for the IKE SA. > > => no, this is not explicit. My proposal is to make this clearly explicit, > and it seems you agree with me. I think this is quite explicit: ---------------------------------------------------------------------- IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and AH associations for the same IP addresses it runs over. ---------------------------------------------------------------------- => the expression "the IP addresses it runs over" is not enough accurate. But I agree we have just to improve a bit the wording. What is the problem with current text, and what should be added to there to make it more clear? => if suddenly a CREATE_CHILD_SA message "runs" over a new source address, should be the IPsec SAs set up for the new address or for the old address used for all previous IKE messages? The current wording doesn't help to do the choice, an improved wording will give a SHOULD for the second choice (use the old address). IMHO the best way is to explain that the peer addresses are IKE SA parameters and IKE SHOULD set up IPsec SAs for them. > => this "when they were negotiated" has to be clarified. And I prefer > (for security reasons, with a SHOULD) to use the IKE SA addresses > than the addresses in the CREATE_CHILD_SA message (in this context, > i.e., no NAT-T or not for the peer behind a NAT). Ok, now I do understand. Yes, I do agree that we SHOULD use the addresses of the initial IKE SA creation, not the CREATE_CHILD_SA messages. => we agree: we have only to find the good wording. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu Sep 11 11:31:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BIVPeo061864; Thu, 11 Sep 2003 11:31:25 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29625 Thu, 11 Sep 2003 13:18:27 -0400 (EDT) Message-Id: <200309111724.h8BHOpHN091744@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Nicolas Williams cc: "Theodore Ts'o" , ipsec@lists.tislabs.com Subject: Re: some concerns about last IKEv2 draft In-reply-to: Your message of Thu, 11 Sep 2003 08:55:24 PDT. <20030911155524.GK11118@binky.central.sun.com> Date: Thu, 11 Sep 2003 19:24:51 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: On Thu, Sep 11, 2003 at 03:35:58PM +0200, Francis Dupont wrote: > In your previous mail you wrote: > > > Further, it would be preferable to give the ASN.1 syntax for this > > SEQUENCE, which means getting the tagging right, as you point out. > > As I said earlier, no tagging is really needed. > > => tagging IS needed. Actually, Francis is right (but see below) - I had not noticed that Theodore said "SEQUENCE OF CHOICE." The I-D says: " Hash and URL of PKIX bundle (13) contains a 20 octet SHA-1 hash of a PKIX certificate bundle followed by a variable length URL the resolves to the BER encoded certificate bundle itself. The bundle is a BER encoded SEQUENCE of certificates and CRLs. " which implies a SEQUENCE OF SEQUENCE, not SEQUENCE OF CHOICE; this is because of the "and" in the last sentence. I.e., => I have a private message from the author where he confirmed he means a CHOICE (I can develop type theory arguments explaining why but this is not the place. Note that as soon as we reach a common understanding in the list we ne more need to ultraclarify the point in the document). Cert-Bundle ::= SEQUENCE OF SEQUENCE { cert , CRL => from RFC 3280: cert = Certificate and CRL = CertificateList } => I strongly disagree with the SEQUENCE OF SEQUENCE interpretation, the text is "SEQUENCE of certificates and CRLs", not "SEQUENCE of certificate and CRL pairs". I.e., the each element of the SEQUENCE is a certificate (PKIX certificates and CRLs are well defined, perhaps a reference to RFC 3280 is missing in the paragraph) or a CRL. Regardless of whether the I-D meant "SEQUENCE OF SEQUENCE" or "SEQUENCE OF CHOICE" it is clear now to me that the I-D has to be a lot more specific - it should even name the ASN.1 types (_and_ the OIDs for the modules whence they are to be IMPORTed) for certificates and CRLs, even if we're all supposed to know what they are (future readers may not). => no, too much ASN.1 is not a good idea. Friends don't let friends underspecify. => the only real issue is in fact the type of tagging. > Explicit tags are > optional in ASN.1, unless they are needed to create a non-ambiguous > encoding. > > => tags (of any kind) are needed when the encoding is ambiguous, > and it is the case here (a CHOICE between two SEQUENCEs). Definitely, unless those sequences are explicitly tagged with, say, some application tag (but I see that "Certificate" is NOT so tagged, for example, even in PKIX1Explicit93 => no PKIX or X.509 stuff uses application tags. But the I-D wording suggests SEQUENCE OF SEQUENCE (without OPTIONAL fields, I presume [see? a possibly bad assumption]), in which case there's no ambiguity. => if the fields are not optional then they are mandatory so they comes by pairs of a certificate and a CRL. If they are optional then at least a tag is needed and the difference with a CHOICE is limited... Er, the ASN.1 specs are OPEN and can be retrieved from the ITU-T site as PDF documents. => freely retrieved? I know there are freely available somewhere but not at the ITU-T site (note that I'd like to be wrong :-). > For instance I implicitly translate the English word "and" into the ASN.1 > CHOICE. I myself do not. Evidently the "certificate bundle" is structured data whose encoding ought be specified, and ASN.1 is a perfectly appropriate syntax for the purpose (and one of several). => There is not several ways to put certificates and CRLs in a SEQUENCE: - SEQUENCE of CHOICEs (SEQUENCE OF CHOICE { cert, CRL }) - SEQUENCE of SEQUENCEs (SEQUENCE { SEQUENCE OF cert, SEQUENCE OF CRL}) I know that it is the first one because when I asked why not use a SET of CHOICEs, Paul Hoffman confirmed it and gave an argument (reordering issue with SETs for people whose encoder always does DER) against SETs. I don't mean to say that you MUST use ASN.1, but that a well specified encoding for the "certificate bundle" is needed. => if you really believe the CHOICE interpretation is not so clear, what about ", respectively with implicit tags 0 and 1 in CHOICEs"? Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu Sep 11 11:58:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BIwEeo066462; Thu, 11 Sep 2003 11:58:14 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29849 Thu, 11 Sep 2003 13:39:16 -0400 (EDT) Date: Thu, 11 Sep 2003 10:43:42 -0700 From: Nicolas Williams To: Francis Dupont Cc: "Theodore Ts'o" , ipsec@lists.tislabs.com Subject: Re: some concerns about last IKEv2 draft Message-ID: <20030911174342.GP11118@binky.central.sun.com> References: <20030911155524.GK11118@binky.central.sun.com> <200309111724.h8BHOpHN091744@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200309111724.h8BHOpHN091744@givry.rennes.enst-bretagne.fr> User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Sep 11, 2003 at 07:24:51PM +0200, Francis Dupont wrote: > which implies a SEQUENCE OF SEQUENCE, not SEQUENCE OF CHOICE; > this is because of the "and" in the last sentence. I.e., > > => I have a private message from the author where he confirmed he means > a CHOICE (I can develop type theory arguments explaining why but > this is not the place. Note that as soon as we reach a common understanding > in the list we ne more need to ultraclarify the point in the document). Good, now let's clarify. > Cert-Bundle ::= SEQUENCE OF SEQUENCE { > cert , > CRL > > => from RFC 3280: cert = Certificate and CRL = CertificateList The I-D MUST state so. > } > > => I strongly disagree with the SEQUENCE OF SEQUENCE interpretation, > the text is "SEQUENCE of certificates and CRLs", not "SEQUENCE of > certificate and CRL pairs". I.e., the each element of the SEQUENCE is > a certificate (PKIX certificates and CRLs are well defined, perhaps > a reference to RFC 3280 is missing in the paragraph) or a CRL. This merely proves that it's easier to disagree about the meaning of English language text than it is to disagree about the meaning of a specification written in a formal language. > Regardless of whether the I-D meant "SEQUENCE OF SEQUENCE" or "SEQUENCE > OF CHOICE" it is clear now to me that the I-D has to be a lot more > specific - it should even name the ASN.1 types (_and_ the OIDs for the > modules whence they are to be IMPORTed) for certificates and CRLs, even > if we're all supposed to know what they are (future readers may not). > > => no, too much ASN.1 is not a good idea. This is not too much - and we've seen the confusion and incorrect specification that results from too little. DEFINITION EXPLICIT TAGS ::= BEGIN IMPORTS Certificate, CertificateList FROM PKIX1Explicit93 -- or from PKIX1Explicit88, which is what's in rfc3280 CertificateOrCRL ::= CHOICE { cert [0] Certificate, crl [1] CertificateList } CertificateBundle ::= SEQUENCE OF CertificateOrCRL END Now how is this too much ASN.1? > Friends don't let friends underspecify. > > => the only real issue is in fact the type of tagging. No, I misundertood the English language description of "certificate bundle" but would not have misunderstood the above ASN.1 module. > > Explicit tags are > > optional in ASN.1, unless they are needed to create a non-ambiguous > > encoding. > > > > => tags (of any kind) are needed when the encoding is ambiguous, > > and it is the case here (a CHOICE between two SEQUENCEs). > > Definitely, unless those sequences are explicitly tagged with, say, some > application tag (but I see that "Certificate" is NOT so tagged, for > example, even in PKIX1Explicit93 > > => no PKIX or X.509 stuff uses application tags. Sure, but by not specifying what the CHOICE alternatives' types are or where they come from one cannot know for sure if the CHOICE is ambiguous, which is why it's proper for the I-D to be explicit. > Er, the ASN.1 specs are OPEN and can be retrieved from the ITU-T site as > PDF documents. > > => freely retrieved? I know there are freely available somewhere but > not at the ITU-T site (note that I'd like to be wrong :-). I to am glad that you're wrong on this: http://www.itu.int/ITU-T/studygroups/com17/languages/ > > For instance I implicitly translate the English word "and" into the ASN.1 > > CHOICE. > > I myself do not. Evidently the "certificate bundle" is structured data > whose encoding ought be specified, and ASN.1 is a perfectly appropriate > syntax for the purpose (and one of several). > > => There is not several ways to put certificates and CRLs in a SEQUENCE: > - SEQUENCE of CHOICEs (SEQUENCE OF CHOICE { cert, CRL }) > - SEQUENCE of SEQUENCEs (SEQUENCE { SEQUENCE OF cert, SEQUENCE OF CRL}) > I know that it is the first one because when I asked why not use a SET > of CHOICEs, Paul Hoffman confirmed it and gave an argument (reordering > issue with SETs for people whose encoder always does DER) against SETs. > > I don't mean to say that you MUST use ASN.1, but that a well specified > encoding for the "certificate bundle" is needed. > > => if you really believe the CHOICE interpretation is not so clear, > what about ", respectively with implicit tags 0 and 1 in CHOICEs"? I think the ASN.1 module given above is quite simple, easy to read and clear, clearer than English language text. If you insist on an English language description of the encoding of "certificate bundle" then let me suggest: The bundle is encoded as the BER [X.690] encoding of an ASN.1 [X.680] SEQUENCE OF CHOICE where the choices are the Certificate and CertificateList types from PKIX1Explicit93 [or 88] explicitly tagged with context tags 0 and 1, respectively. Please ensure the presence of _normative_ references to X.680 (ASN.1) and X.690 (BER). Cheers, Nico -- From owner-ipsec@lists.tislabs.com Fri Sep 12 05:30:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CCU9eo062302; Fri, 12 Sep 2003 05:30:10 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA14496 Fri, 12 Sep 2003 07:44:06 -0400 (EDT) Message-Id: <200309121150.h8CBoOHN094201@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Nicolas Williams cc: "Theodore Ts'o" , ipsec@lists.tislabs.com Subject: Re: some concerns about last IKEv2 draft In-reply-to: Your message of Thu, 11 Sep 2003 10:43:42 PDT. <20030911174342.GP11118@binky.central.sun.com> Date: Fri, 12 Sep 2003 13:50:24 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > => from RFC 3280: cert = Certificate and CRL = CertificateList The I-D MUST state so. => the I-D says PKIX certificates and CRLs. There is no ambiguity at all, mainly because of the "PKIX" word. This merely proves that it's easier to disagree about the meaning of English language text than it is to disagree about the meaning of a specification written in a formal language. => the problem is a formal language can be very boring. Two other remarks: - we don't need the abstract syntax, only the concrete data layout. - most of the other CERT types are very underspecified, for instance the DNS Signed Key... > Regardless of whether the I-D meant "SEQUENCE OF SEQUENCE" or "SEQUENCE > OF CHOICE" it is clear now to me that the I-D has to be a lot more > specific - it should even name the ASN.1 types (_and_ the OIDs for the > modules whence they are to be IMPORTed) for certificates and CRLs, even > if we're all supposed to know what they are (future readers may not). > > => no, too much ASN.1 is not a good idea. This is not too much - and we've seen the confusion and incorrect specification that results from too little. DEFINITION EXPLICIT TAGS ::= => I prefer IMPLICIT tagging (which gives shorter encoding). BEGIN IMPORTS Certificate, CertificateList FROM PKIX1Explicit93 -- or from PKIX1Explicit88, which is what's in rfc3280 => we have the choice between PKIX{Explicit,Implicit}88 if we use only the RFC 3280. CertificateOrCRL ::= CHOICE { cert [0] Certificate, crl [1] CertificateList } => the names of the field (cert and crl) are examples of overspecification: they are not needed for interoperability, only by ASN.1. CertificateBundle ::= SEQUENCE OF CertificateOrCRL END Now how is this too much ASN.1? => I have no trouble with ASN.1, let the WG decide how much of ASN.1 it can eat. I to am glad that you're wrong on this: http://www.itu.int/ITU-T/studygroups/com17/languages/ => very fine! I think the ASN.1 module given above is quite simple, easy to read and clear, clearer than English language text. If you insist on an English language description of the encoding of "certificate bundle" then let me suggest: The bundle is encoded as the BER [X.690] encoding of an ASN.1 [X.680] SEQUENCE OF CHOICE where the choices are the Certificate and CertificateList types from PKIX1Explicit93 [or 88] explicitly tagged with context tags 0 and 1, respectively. Please ensure the presence of _normative_ references to X.680 (ASN.1) and X.690 (BER). => thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Fri Sep 12 07:32:21 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CEWKeo073950; Fri, 12 Sep 2003 07:32:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15963 Fri, 12 Sep 2003 09:48:01 -0400 (EDT) Message-Id: <200309121341.JAA21744@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-ikev2-algorithms-04.txt Date: Fri, 12 Sep 2003 09:41:26 -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 : Cryptographic Algorithms for use in the Internet Key Exchange Version 2 Author(s) : J. Schiller Filename : draft-ietf-ipsec-ikev2-algorithms-04.txt Pages : 6 Date : 2003-9-12 The IPSec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE [RFC2409] and IKEv2 [IKEv2]) provide a mechanism to negotiate which algorithms should be used in any even association. However to ensure interoperability between disparate implementations it is necessary to specify a set of mandatory to implement algorithms to ensure at least one algorithm that all implementations will have available. This document defines the current set of mandatory to implement algorithms for use of IKEv2 as well as specifying algorithms that should be implemented because they made be promoted to mandatory at some future time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ikev2-algorithms-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-algorithms-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-12084530.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-algorithms-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-algorithms-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-12084530.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Sep 12 18:02:55 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8D12seo019896; Fri, 12 Sep 2003 18:02:55 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20942 Fri, 12 Sep 2003 20:16:01 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Fri, 12 Sep 2003 20:26:53 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue #67 -- IPsec management traffic Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 67 Title: IPsec management traffic Description: ============ SPD entries apply only to subscriber traffic. However, 2401 says that the "SPD must be consulted during the processing of all traffic..." leading to confusion about whether IPsec management traffic should have an SPD entry, etc. Should the text be modified to make it clear that an IPsec implementation is able to send and receive traffic for itself independent of SPD/SAD entries or should there be an explicit SPD entry to cover IPsec management traffic? Note: If one chose to allow IPsec management traffic to bypass SPD lookup, then how would one implement a policy of "don't accept IKE traffic from src A"? Note: There MUST be an entry in the SPD to cover transiting IKE traffic that is not destined for the system itself. Proposed approach: ================== The proposed approach has several components: 1. Add adjective "subscriber" in front of "traffic" in the sentence the "SPD must be consulted during the processing of all traffic..." 2. Add text to say "An IPsec implementation may originate and terminate its own management traffic, e.g., IKE, irrespective of the SPD and SAD entries used to manage subscriber traffic. If SNMP traffic directed to the IPsec device is protected via IPsec, then it should be treated the same as subscriber traffic. SNMP traffic directed to the IPsec implementation and not protected by IPsec could fall into the same category as IKE, i.e., it might be exempted from SPD/SAD constraints. Outbound ICMP traffic arriving on a secure (red) interface of an IPsec implementation should be subject to normal, SPD/SAD controls, as should inbound ICMP arriving via an SA. ICMP traffic arriving on an insecure (black) interface must be treated specially, and this topic will be addressed in a separate note. 3. IKE is designed to be minimally vulnerable to DoS attacks that result from IKE exchanges, so there is no need to reject initial IKE messages based on a configured policy. However, it may be reasonable to add a policy DB that says with whom the IPsec system will execute IKE, e.g., with whom it will complete an IKE exchange, what form of authentication is required, etc. Thank you, Karen From owner-ipsec@lists.tislabs.com Fri Sep 12 18:02:55 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8D12seo019895; Fri, 12 Sep 2003 18:02:55 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20948 Fri, 12 Sep 2003 20:16:36 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Fri, 12 Sep 2003 20:27:35 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue #68 -- VPNs with overlapping IP address ranges Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 68 Title: VPNs with overlapping IP address ranges Description: ============ How should we address the situation of VPNs between customer intranets (PPVPNs) that have overlapping, private IP address ranges? This situation involves several problems. 1. Outbound IPsec traffic -- An IPsec implementation needs to be able to associate outbound traffic with the right SPD (SPD cache) in order to apply the appropriate policy to the traffic. However, 2401's set of selectors are not sufficient to enable selection of an appropriate SPD when there are overlapping subscriber address spaces served by a single IPsec implementation. However, SPD selection could be performed in a purely local fashion, e.g., based on tracking the local interface on which the packet arrived. 2. Inbound IPsec traffic -- The SA in which the traffic arrives will be linked to an SPD entry which will define the set of selectors, algorithms, etc. to use in checking the data. However, when the data exits IPsec processing, if the destination address is not unique relative to the set of subscribers served by the IPsec device, the SAD will need to contain some data that will enable appropriate routing of the traffic to the right subscriber. Here too, this could be a purely local matter. 3. Non-IPsec traffic -- Other problems arise with regard to handling of non-IPsec traffic. When subscriber addresses are not routable, NAT or some similar process has to be employed to translate the private addresses to routable addresses. In theory, this could be done in two ways a. AFTER outbound traffic is processed (bypassed) by IPsec and BEFORE inbound traffic is handed to IPsec for access control. b. BEFORE outbound traffic is passed to IPsec (bypassed) and AFTER inbound traffic exits IPsec. Our understanding is that (b) is not acceptable because subscribers want to use native, private addresses for SPD entries. For case (a), the NAT processing can be effected outside of IPsec, i.e., after outbound traffic is bypassed and before inbound traffic is handed to IPsec for access control. 4. When establishing an SA to a security gateway (SG1) (that also may serve multiple subscribers with non-routable addresses), it is necessary to inform the peer (SG1) as to the identity of the subscriber network on whose behalf the SA is being established, and the identity of the subscriber net that is the target of the SA. Given the possibility of overlapping addresses for subscribers, it is clear that addresses cannot be used for identification in these cases. So, some other form of ID is needed and the form of the ID must be consistent between peers, to ensure that each subscriber net is uniquely identified. It has been suggested that some form of VPN subscriber ID be added as an IKE payload value, to provide a means of passing this info between IPsec peers, when necessary. This additional value is not a selector per se, as it need not be used locally by an IPsec implementation to map outbound traffic to an SA, nor is it checked upon receipt. Proposed approach: ================== We recommend that IPsec implementations that support multiple subscriber nets with overlapping private address spaces incorporate the following capabilities: a. They MUST employ some local means to select the appropriate SPD for each subscriber for outbound traffic b. They MUST negotiate a VPN subscriber ID using IKE, as noted above, to enable forwarding of inbound IPsec traffic after crypto processing. c. They SHOULD employ NAT, outside of IPsec, to accommodate bypassed traffic. These requirements are imposed only on IPsec implementations that support multiple subscriber networks that employ private addresses (and which may thus overlap). Thank you, Karen From owner-ipsec@lists.tislabs.com Fri Sep 12 18:06:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8D16Weo020022; Fri, 12 Sep 2003 18:06:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20969 Fri, 12 Sep 2003 20:17:50 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Fri, 12 Sep 2003 20:28:48 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue #71 -- Add definition of reserved SPIs Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 71 Title: Add definition of reserved SPIs Description: ============ The definition of reserved SPIs is in the ESP and AH specs and not in 2401. Per private email from Steve Bellovin, it should be added to 2401bis. Proposed approach: ================== Add text (based on text in AH and ESP) along the lines of: "The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use. A reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. The SPI value of zero (0) is reserved for local implementation-specific use and MUST NOT be sent on the wire. For example, a key management implementation MAY use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established." Thank you, Karen From owner-ipsec@lists.tislabs.com Fri Sep 12 18:59:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8D1xQeo021598; Fri, 12 Sep 2003 18:59:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20963 Fri, 12 Sep 2003 20:17:29 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Fri, 12 Sep 2003 20:28:27 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue #70 -- Add diffserv (IPv4) and class (IPv6) as selectors Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 70 Title: Add diffserv (IPv4) and class (IPv6) as selectors Description: ============ Do we need to add support for diffserv (IPv4) and class for IPv6 to enable creation of SAs per service class? (Note diff serv = DSCP.) Proposed approach: ================== Providing support for the creation of SAs per service class was addressed under Issue #48 (add TOS traffic selector option) by the addition of support for multiple SAs between a given sender and receiver, with the same selectors. As noted under Issue #48, diff serv (aka DSCP) and class will not be added as new selectors. Instead, it is left to the sender to distribute traffic among these SAs to achieve the desired QOS. Also, while neither diff serv (aka DSCP) nor class is an IPsec selector, the sender will need a mechanism to direct packets with a given (set of) DSCP values to the appropriate SA. This mechanism might be termed a "filter" or "classifier." The implementation of such filters or classifiers is a local matter, since they are not directly visible to nor coordinated with the peer IPsec implementation. Thank you, Karen From owner-ipsec@lists.tislabs.com Fri Sep 12 19:01:34 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8D21Yeo021683; Fri, 12 Sep 2003 19:01:34 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20957 Fri, 12 Sep 2003 20:16:55 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Fri, 12 Sep 2003 20:27:53 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue #69 -- Multiple protocols per SPD entry Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 69 Title: Multiple protocols per SPD entry Description: ============ How does one SPD entry cover multiple protocols associated with one port, e.g., TCP/NFS and UDP/NFS? Proposed approach: ================== The addition of support for lists of ranges of selectors (Issue #47) in an SPD entry allows a single port (e.g., a well-known port) to be used with multiple protocols, on the same SA. It also allows multiple ports under the same protocol to be mapped to one SA, etc. Note, however, that this capability does not permit an SPD entry to specify that different ports in a list are to be used with different protocols. Thus, for example, if an SPD entry contains a list with both TCP and UDP, and the entry contains destination ports A & B, then TCP and UDP traffic for either port will be acceptable for the resulting SA. Thank you, Karen From owner-ipsec@lists.tislabs.com Mon Sep 15 06:39:31 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FDdVeo055321; Mon, 15 Sep 2003 06:39:31 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05749 Mon, 15 Sep 2003 08:46:45 -0400 (EDT) X-test-idtracker: no To: IETF-Announce :; Cc: ipsec@lists.tislabs.com From: The IESG Subject: Last Call: 'A Traffic-Based Method of Detecting Dead IKE Peers' to Informational RFC Reply-to: iesg@ietf.org Message-Id: Date: Sun, 14 Sep 2003 22:07:30 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IESG has received a request from the IP Security Protocol WG to consider the following document: - 'A Traffic-Based Method of Detecting Dead IKE Peers ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-09-28. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dpd-03.txt From owner-ipsec@lists.tislabs.com Tue Sep 16 07:02:00 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8GDxTeo085024; Tue, 16 Sep 2003 07:01:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08470 Tue, 16 Sep 2003 08:57:29 -0400 (EDT) Message-Id: <200309152347.h8FNlSN11324@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3566 on The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec Cc: rfc-editor@rfc-editor.org, ipsec@lists.tislabs.com From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 15 Sep 2003 16:47:28 -0700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3566 Title: The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec Author(s): S. Frankel, H. Herbert Status: Standards Track Date: September 2003 Mailbox: sheila.frankel@nist.gov, howard.c.herbert@intel.com Pages: 11 Characters: 24645 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsec-ciph-aes-xcbc-mac-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3566.txt A Message Authentication Code (MAC) is a key-dependent one way hash function. One popular way to construct a MAC algorithm is to use a block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode of operation. The classic CBC-MAC algorithm, while secure for messages of a pre-selected fixed length, has been shown to be insecure across messages of varying lengths such as the type found in typical IP datagrams. This memo specifies the use of AES in CBC mode with a set of extensions to overcome this limitation. This new algorithm is named AES-XCBC-MAC-96. This document is a product of the IPsec Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030915164601.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3566 --OtherAccess Content-Type: Message/External-body; name="rfc3566.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030915164601.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Sep 16 10:09:48 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8GH9leo093145; Tue, 16 Sep 2003 10:09:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA11043 Tue, 16 Sep 2003 12:20:41 -0400 (EDT) Message-Id: <200309161624.h8GGOfHW031190@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: ipsec@lists.tislabs.com Subject: Issue tracker update Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Sep 2003 12:24:41 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Issues 47, 48, 49, and 57 (all related to RFC2401bis) on the issue tracker have been marked as accepted. The titles of these issues are: Proposed change: all selectors can be a list of ranges, per IKEv2 spec Proposed change: add ToS traffic selector option Proposed change: red-side fragmentation option ECN support Note that in the case of 48, "accept" means use of multiple SAs with the same selector. The issue tracker can be found at https://roundup.machshav.com/ipsec/ -Angelos From owner-ipsec@lists.tislabs.com Tue Sep 16 10:16:36 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8GHGaeo093533; Tue, 16 Sep 2003 10:16:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA11122 Tue, 16 Sep 2003 12:28:15 -0400 (EDT) Message-Id: <200309161632.h8GGWGHW001446@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: ipsec@lists.tislabs.com Subject: new issues on the tracker Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Sep 2003 12:32:16 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk All, we have 5 new issues on the tracker: 67 IPsec management traffic 68 VPNs with overlapping IP address ranges 69 Multiple protocols per SPD entry 70 Add diffserv (IPv4) and class (IPv6) as selectors 71 Add definition of reserved SPIs Issue 70 is a replica of issue 48, so the same resolution applies. Items 69 and 71 seem fairly straightforward, so unless we see some discussion in the next week or so, we'll go ahead and accept them. We would like to see some discussion on issues 67 and 68. Cheers, -Angelos From pawbell@intology.com Tue Sep 16 13:45:14 2003 Received: from intology.com (209-198-134-50-host.prismnet.net [209.198.134.50]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8GKjBeo004690 for ; Tue, 16 Sep 2003 13:45:13 -0700 (PDT) (envelope-from pawbell@intology.com) Date: Tue, 16 Sep 2003 13:45:11 -0700 (PDT) From: Jay To: ietf-ipsec@imc.org Subject: ADV: US phone lines are now available WORLDWIDE! Reply-To: pawbell@intology.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: US phone lines are now available WORLDWIDE! PAWBELL a division of Intology.com can now offer foreign based companies US phone numbers that ring in there office. Starting at less than $100.00 US per month your company can now send unlimited calls to and receive unlimited calls from the USA. Intology will provide your company with office space in the Austin, Texas, USA area. Intology will have one or multiple phone lines installed in your USA office. When your customer calls your Austin phone number we will automatically forward the call to your offices. There is no long distance charge! >From your offices you can also place calls to the USA without paying long distance charges. When you pick-up the Intology phone you are automatically connected to a USA phone number. You may then place calls to any phone in the USA without any per minute charges. Make as many calls per day and talk as long as you wish for one low monthly fee. For more information contact us by E-Mail at pawbell@intology.com or view our website at www.pawbell.com. Have more than one office in different parts of the world? The offices can share one line. The call is answered electronically in the USA and the caller is prompted for the extension of the correct office. Offices sharing a line can also call between offices for free!!! A US Toll-Free number can be added to your plan. PAWBELL based telephony solutions offer a rich and flexible feature set. PAWBELL offers both classical PBX functionality and advanced features, and interoperates with traditional standards-based telephony systems. PAWBELL offers the features one would expect of a large proprietary PBX system such as Voicemail, Conference Bridging, Call Queuing, and Call Detail Records. Telephony Service can include: Voicemail System Password Protection Separate Away and Unavailable Messages Default or Custom Messages Multiple Mail Folders Web Interface for Voicemail Checking E-mail notification of Voicemail Voicemail Forwarding Visual Message Waiting Indicator Message Waiting Stutter Dialtone Auto Attendant Interactive Voice Response Overhead Paging Flexible Extension Logic Multiple Line Extensions Multi-Layered Access Control Direct Inward System Access Directory Listing Conference Bridging Unlimited Conference Rooms Access Control Call Queuing ADSI Menu System Support for Advanced Telephony Features PBX Driven Visual Menu Systems Visual Notification of Voicemail Call Detail Records Local Call Agents Remote Call Agents Protocol Bridging Provides seamless integration of technologies Offers a unified set of services to users regardless of connection type Call Features: Music on Hold Music on Transfer Flexible mp3 based system Volume Control Random Play Linear Play Call Waiting Caller ID Caller ID Blocking Caller ID on Call Waiting Call Forward on Busy Call Forward on No Answer Call Forward Variable Call Transfer Call Parking Call Retrieval Remote Call Pickup Do Not Disturb Scalability: TDMoE Allows Direct Connection of PAWBELL PBX Offers Zero Latency Uses Commodity Ethernet Hardware Allows for Integration of Physically Separate Installations Uses commonly deployed data connections Allows a unified dialplan across multiple offices Intology is also seeking companies interested in a PAWBELL Franchise to sell services in their country. Pawbell@Intology.com This message was checked by MailScan for WorkgroupMail. www.workgroupmail.com From owner-ipsec@lists.tislabs.com Wed Sep 17 00:02:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8H72Zeo067372; Wed, 17 Sep 2003 00:02:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA17588 Wed, 17 Sep 2003 02:16:43 -0400 (EDT) Message-Id: <5.2.0.9.0.20030917120220.009ecdc0@202.125.80.81> X-Sender: ravivsn@202.125.80.81 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 17 Sep 2003 12:04:00 +0530 To: "ipsec mailingList" From: Ravi Kumar Subject: Re: 2401bis Issue #69 -- Multiple protocols per SPD entry Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I feel the proposed solution can be extended to support 'Port range'. Today, we have facility to negotiate a port or all ports. Adding 'port range' in Security Policy and providing a way to negotiate through IKE will solve some practical problems. Regards Ravi > ----- Original Message ----- > From: "Karen Seo" > To: "ipsec mailingList" > Cc: ; ; "Angelos D. Keromytis" ; ; > Sent: Friday, September 12, 2003 5:27 PM > Subject: 2401bis Issue #69 -- Multiple protocols per SPD entry > > > > Folks, > > > > Here's a description and proposed approach for: > > > > IPsec Issue #: 69 > > > > Title: Multiple protocols per SPD entry > > > > Description: > > ============ > > How does one SPD entry cover multiple protocols associated with one > > port, e.g., TCP/NFS and UDP/NFS? > > > > > > Proposed approach: > > ================== > > The addition of support for lists of ranges of selectors (Issue #47) > > in an SPD entry allows a single port (e.g., a well-known port) to be > > used with multiple protocols, on the same SA. It also allows multiple > > ports under the same protocol to be mapped to one SA, etc. Note, > > however, that this capability does not permit an SPD entry to specify > > that different ports in a list are to be used with different > > protocols. Thus, for example, if an SPD entry contains a list with > > both TCP and UDP, and the entry contains destination ports A & B, > > then TCP and UDP traffic for either port will be acceptable for the > > resulting SA. > > > > > > Thank you, > > Karen > The Views Presented in this mail are completely mine. The company is not responsible for what so ever. ---------- Ravi Kumar CH Rendezvous On Chip (I) Pvt Ltd Hyderabad, INDIA ROC HOME PAGE: http://www.roc.co.in From owner-ipsec@lists.tislabs.com Wed Sep 17 00:03:15 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8H73Feo067609; Wed, 17 Sep 2003 00:03:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA17623 Wed, 17 Sep 2003 02:20:55 -0400 (EDT) Message-Id: <5.2.0.9.0.20030917120621.009ef0c0@202.125.80.81> X-Sender: ravivsn@202.125.80.81 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 17 Sep 2003 12:08:17 +0530 To: "ipsec mailingList" From: Ravi Kumar Subject: Re:2401bis Issue #68 -- VPNs with overlapping IP address ranges Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Implementations (including ours) allocate one or more public IP addresses for each subscriber. It is expected that IKE negotiations and IPSEC traffic come with this(these) IP address(es) as 'Destination IP'. Based on this, subscriber ID is extracted locally and after decryption, the packets are forwarded onto the subscriber network. It is not mandatory to negotiate Subscriber ID via IKE. Due to this, I feel, we should not make negotiation of subscribe ID mandatory. But, if same public IP address is used across multiple subscribers, then subscriber ID via IKE is needed. The proposed text should take care of above. Thanks Ravi > ----- Original Message ----- > From: "Karen Seo" > To: "ipsec mailingList" > Cc: ; ; "Angelos D. Keromytis" ; ; > Sent: Friday, September 12, 2003 5:27 PM > Subject: 2401bis Issue #68 -- VPNs with overlapping IP address ranges > > > > Folks, > > > > Here's a description and proposed approach for: > > > > IPsec Issue #: 68 > > > > Title: VPNs with overlapping IP address ranges > > > > Description: > > ============ > > How should we address the situation of VPNs between customer > > intranets (PPVPNs) that have overlapping, private IP address ranges? > > This situation involves several problems. > > > > 1. Outbound IPsec traffic -- An IPsec implementation needs to be able > > to associate outbound traffic with the right SPD (SPD cache) in order > > to apply the appropriate policy to the traffic. However, 2401's set > > of selectors are not sufficient to enable selection of an appropriate > > SPD when there are overlapping subscriber address spaces served by a > > single IPsec implementation. However, SPD selection could be > > performed in a purely local fashion, e.g., based on tracking the > > local interface on which the packet arrived. > > > > 2. Inbound IPsec traffic -- The SA in which the traffic arrives will > > be linked to an SPD entry which will define the set of selectors, > > algorithms, etc. to use in checking the data. However, when the data > > exits IPsec processing, if the destination address is not unique > > relative to the set of subscribers served by the IPsec device, the > > SAD will need to contain some data that will enable appropriate > > routing of the traffic to the right subscriber. Here too, this could > > be a purely local matter. > > > > 3. Non-IPsec traffic -- Other problems arise with regard to handling > > of non-IPsec traffic. When subscriber addresses are not routable, > > NAT or some similar process has to be employed to translate the > > private addresses to routable addresses. In theory, this could be > > done in two ways > > > > a. AFTER outbound traffic is processed (bypassed) by IPsec and BEFORE > > inbound traffic is handed to IPsec for access control. > > b. BEFORE outbound traffic is passed to IPsec (bypassed) and AFTER > > inbound traffic exits IPsec. > > > > Our understanding is that (b) is not acceptable because subscribers > > want to use native, private addresses for SPD entries. For case > > (a), the NAT processing can be effected outside of IPsec, i.e., after > > outbound traffic is bypassed and before inbound traffic is handed to > > IPsec for access control. > > > > 4. When establishing an SA to a security gateway (SG1) (that also may > > serve multiple subscribers with non-routable addresses), it is > > necessary to inform the peer (SG1) as to the identity of the > > subscriber network on whose behalf the SA is being established, and > > the identity of the subscriber net that is the target of the SA. > > Given the possibility of overlapping addresses for subscribers, it is > > clear that addresses cannot be used for identification in these > > cases. So, some other form of ID is needed and the form of the ID > > must be consistent between peers, to ensure that each subscriber net > > is uniquely identified. It has been suggested that some form of VPN > > subscriber ID be added as an IKE payload value, to provide a means of > > passing this info between IPsec peers, when necessary. This > > additional value is not a selector per se, as it need not be used > > locally by an IPsec implementation to map outbound traffic to an SA, > > nor is it checked upon receipt. > > > > > > Proposed approach: > > ================== > > We recommend that IPsec implementations that support multiple > > subscriber nets with overlapping private address spaces incorporate > > the following capabilities: > > > > a. They MUST employ some local means to select the appropriate SPD for > > each subscriber for outbound traffic > > b. They MUST negotiate a VPN subscriber ID using IKE, as noted above, > > to enable forwarding of inbound IPsec traffic after crypto processing. > > c. They SHOULD employ NAT, outside of IPsec, to accommodate bypassed > > traffic. > > > > These requirements are imposed only on IPsec implementations that > > support multiple subscriber networks that employ private addresses > > (and which may thus overlap). > > > > Thank you, > > Karen The Views Presented in this mail are completely mine. The company is not responsible for what so ever. ---------- Ravi Kumar CH Rendezvous On Chip (I) Pvt Ltd Hyderabad, INDIA ROC HOME PAGE: http://www.roc.co.in From owner-ipsec@lists.tislabs.com Wed Sep 17 05:55:14 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8HCtDeo098627; Wed, 17 Sep 2003 05:55:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA21205 Wed, 17 Sep 2003 08:12:07 -0400 (EDT) Reply-To: From: "Wenxiao He" To: "'Karen Seo'" , "'ipsec mailingList'" Cc: , , "'Angelos D. Keromytis'" , Subject: RE: 2401bis Issue #67 -- IPsec management traffic Date: Tue, 16 Sep 2003 12:40:56 -0700 Message-ID: <000001c37c8a$784d78a0$0400a8c0@WH764682> 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, Build 10.0.4024 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Karen Seo > Sent: Friday, September 12, 2003 5:27 PM > To: ipsec mailingList > Cc: byfraser@cisco.com; tytso@mit.edu; Angelos D. Keromytis; > kivinen@ssh.fi; kseo@bbn.com > Subject: 2401bis Issue #67 -- IPsec management traffic > > > Folks, > > Here's a description and proposed approach for: > > IPsec Issue #: 67 > > Title: IPsec management traffic > > Description: > ============ > SPD entries apply only to subscriber traffic. However, 2401 says that > the "SPD must be consulted during the processing of all traffic..." > leading to confusion about whether IPsec management traffic should > have an SPD entry, etc. Should the text be modified to make it clear > that an IPsec implementation is able to send and receive traffic for > itself independent of SPD/SAD entries or should there be an explicit > SPD entry to cover IPsec management traffic? > When talking about "send and receive traffic for itself independent of SPD/SAD entries", are you saying all end host IPSec management traffic should be in cleartext? Using the example below, assuming IPSec tunnel between H1 and SG2 is ready and H1 sending IKE messages to H2, should these IKE messages be in cleartext or protected by H1/SG2 tunnel SA? On the 2nd note below are you saying when IKE traffic (H1/H2) going through SG2 it will require a SPD? ====================================================== | | |============================== | || | | || ---|----------------------|--- || | | | | H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* | ^ | Intranet) | | ------------------------------ could be dialup admin. boundary (optional) to PPP/ARA server > Note: If one chose to allow IPsec management traffic to bypass SPD > lookup, then how would one implement a policy of "don't accept IKE > traffic from src A"? > > Note: There MUST be an entry in the SPD to cover transiting IKE > traffic that is not destined for the system itself. > > > Proposed approach: > ================== > The proposed approach has several components: > > 1. Add adjective "subscriber" in front of "traffic" in the sentence > the "SPD must be consulted during the processing of all traffic..." > > 2. Add text to say "An IPsec implementation may originate and > terminate its own management traffic, e.g., IKE, irrespective of the > SPD and SAD entries used to manage subscriber traffic. If SNMP > traffic directed to the IPsec device is protected via IPsec, then it > should be treated the same as subscriber traffic. SNMP traffic > directed to the IPsec implementation and not protected by IPsec could > fall into the same category as IKE, i.e., it might be exempted from > SPD/SAD constraints. Outbound ICMP traffic arriving on a secure (red) > interface of an IPsec implementation should be subject to normal, > SPD/SAD controls, as should inbound ICMP arriving via an SA. ICMP > traffic arriving on an insecure (black) interface must be treated > specially, and this topic will be addressed in a separate note. > > 3. IKE is designed to be minimally vulnerable to DoS attacks that > result from IKE exchanges, so there is no need to reject initial IKE > messages based on a configured policy. However, it may be reasonable > to add a policy DB that says with whom the IPsec system will execute > IKE, e.g., with whom it will complete an IKE exchange, what form of > authentication is required, etc. > > > Thank you, > Karen > From owner-ipsec@lists.tislabs.com Wed Sep 17 14:55:23 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8HLtMej019733; Wed, 17 Sep 2003 14:55:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA25373 Wed, 17 Sep 2003 16:51:03 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <5.2.0.9.0.20030917120621.009ef0c0@202.125.80.81> References: <5.2.0.9.0.20030917120621.009ef0c0@202.125.80.81> Date: Wed, 17 Sep 2003 11:03:37 -0400 To: Ravi Kumar From: Stephen Kent Subject: Re:2401bis Issue #68 -- VPNs with overlapping IP address ranges Cc: "ipsec mailingList" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:08 +0530 9/17/03, Ravi Kumar wrote: > Hi, > Implementations (including ours) allocate one or more public IP >addresses for each subscriber. > It is expected that IKE negotiations and IPSEC traffic come with >this(these) IP address(es) as > 'Destination IP'. Based on this, subscriber ID is extracted >locally and after decryption, the packets > are forwarded onto the subscriber network. > It is not mandatory to negotiate Subscriber ID via IKE. > Due to this, I feel, we should not make negotiation of subscribe >ID mandatory. > But, if same public IP address is used across multiple >subscribers, then subscriber ID via IKE > is needed. The proposed text should take care of above. >Thanks > Ravi Ravi, Use of multiple public addresses, one per subscriber net per Ipsec implementation, does provide another means of identifying the subscriber net, but this requires an ability to acquire the multiple, public addresses at each end. In that sense, this is a less general approach than using a subscriber net ID internal to IPsec (IKE). In general I think we are better off with a mechanism that works in all cases, vs. one that works only if it is possible to acquire enough public addresses from an ISP to assign one to each subscriber net address behind the device. Steve From owner-ipsec@lists.tislabs.com Wed Sep 17 14:55:23 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8HLtMej019734; Wed, 17 Sep 2003 14:55:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA25431 Wed, 17 Sep 2003 17:06:12 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <000001c37c8a$784d78a0$0400a8c0@WH764682> References: <000001c37c8a$784d78a0$0400a8c0@WH764682> Date: Wed, 17 Sep 2003 17:14:19 -0400 To: From: Stephen Kent Subject: RE: 2401bis Issue #67 -- IPsec management traffic Cc: "'ipsec mailingList'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:40 -0700 9/16/03, Wenxiao He wrote: > > -----Original Message----- >> From: owner-ipsec@lists.tislabs.com >> [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Karen Seo >> Sent: Friday, September 12, 2003 5:27 PM >> To: ipsec mailingList >> Cc: byfraser@cisco.com; tytso@mit.edu; Angelos D. Keromytis; >> kivinen@ssh.fi; kseo@bbn.com >> Subject: 2401bis Issue #67 -- IPsec management traffic >> >> >> Folks, >> >> Here's a description and proposed approach for: >> >> IPsec Issue #: 67 >> >> Title: IPsec management traffic >> >> Description: >> ============ >> SPD entries apply only to subscriber traffic. However, 2401 says that >> the "SPD must be consulted during the processing of all traffic..." >> leading to confusion about whether IPsec management traffic should >> have an SPD entry, etc. Should the text be modified to make it clear >> that an IPsec implementation is able to send and receive traffic for >> itself independent of SPD/SAD entries or should there be an explicit >> SPD entry to cover IPsec management traffic? >> > >When talking about "send and receive traffic for itself independent of >SPD/SAD entries", are you saying all end host IPSec management traffic >should be in cleartext? NO. what we said was that IKE SAs are treated specially by the host/SG that terminates or originates IKE traffic, and thus need not be subject to SPD/SAD controls. >Using the example below, assuming IPSec tunnel >between H1 and SG2 is ready and H1 sending IKE messages to H2, should >these IKE messages be in cleartext or protected by H1/SG2 tunnel SA? On >the 2nd note below are you saying when IKE traffic (H1/H2) going through >SG2 it will require a SPD? The IKE traffic from H1 is treated like any other subscriber traffic from H1, and thus requires an appropriate SPD entry to be allowed to pass. However, at H1, the IKE traffic it emits and receives need not be authorized by an entry in its SPD. > > ====================================================== > | | > |============================== | > || | | > || ---|----------------------|--- > || | | | | > H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* | > ^ | Intranet) | > | ------------------------------ > could be dialup admin. boundary (optional) > to PPP/ARA server > > >> Note: If one chose to allow IPsec management traffic to bypass SPD >> lookup, then how would one implement a policy of "don't accept IKE > > traffic from src A"? Steve From owner-ipsec@lists.tislabs.com Wed Sep 17 18:49:23 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8I1nMhT033549; Wed, 17 Sep 2003 18:49:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA27132 Wed, 17 Sep 2003 20:58:58 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <000001c37d76$820f4e80$f3810d0f@WH764682> References: <000001c37d76$820f4e80$f3810d0f@WH764682> Date: Wed, 17 Sep 2003 21:06:56 -0400 To: From: Stephen Kent Subject: RE: 2401bis Issue #67 -- IPsec management traffic Cc: "'ipsec mailingList'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 16:50 -0700 9/17/03, Wenxiao He wrote: > > >> NO. what we said was that IKE SAs are treated specially by the >> host/SG that terminates or originates IKE traffic, and thus need not >> be subject to SPD/SAD controls. >> >> The IKE traffic from H1 is treated like any other subscriber traffic >> from H1, and thus requires an appropriate SPD entry to be allowed to >> pass. However, at H1, the IKE traffic it emits and receives need not >> be authorized by an entry in its SPD. > >I am still confused. Let me ask some questions first: >* What is IPSec management traffic? Does it include IKE traffic >(UDP/500)? yes, it includes IKE traffic, but the text refers to IPsec management traffic originated or terminated by the device in question, not ALL IPsec management traffic. >* What traffic is not subject to SPD/SAD control? that's the subject of this change, see above! >* When a traffic is not subject to SPD/SAD control, it sounds it is >cleartext to me. Without consulting SPD/SAD, how can the traffic get >sent with SA protection(which SA to use)? IKE provides its own protection for its traffic, but it does not use ESP. that is an example of protected traffic that would not be processed via the SPD, e.g., since the SPD entries are defined to apply ESP and/or AH, but not the crypto protection employed by IKE. Steve From owner-ipsec@lists.tislabs.com Wed Sep 17 21:03:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8I43eKP045601; Wed, 17 Sep 2003 21:03:41 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA28169 Wed, 17 Sep 2003 23:19:08 -0400 (EDT) Message-Id: <5.2.0.9.0.20030918090603.009febe0@202.125.80.81> X-Sender: ravivsn@202.125.80.81 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 18 Sep 2003 09:06:37 +0530 To: Stephen Kent From: Ravi Kumar Subject: Re:2401bis Issue #68 -- VPNs with overlapping IP address ranges Cc: "ipsec mailingList" In-Reply-To: References: <5.2.0.9.0.20030917120621.009ef0c0@202.125.80.81> <5.2.0.9.0.20030917120621.009ef0c0@202.125.80.81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, Since, there is one common method being followed (which does not require any interoperability), I am trying to see whether we should make this requirement as 'Should' rather than 'MUST'. Thanks Ravi At 11:03 AM 9/17/03 -0400, Stephen Kent wrote: >At 12:08 +0530 9/17/03, Ravi Kumar wrote: >> Hi, >> Implementations (including ours) allocate one or more public IP >> addresses for each subscriber. >> It is expected that IKE negotiations and IPSEC traffic come with >> this(these) IP address(es) as >> 'Destination IP'. Based on this, subscriber ID is extracted locally >> and after decryption, the packets >> are forwarded onto the subscriber network. >> It is not mandatory to negotiate Subscriber ID via IKE. >> Due to this, I feel, we should not make negotiation of subscribe ID >> mandatory. >> But, if same public IP address is used across multiple subscribers, >> then subscriber ID via IKE >> is needed. The proposed text should take care of above. >>Thanks >> Ravi > >Ravi, > >Use of multiple public addresses, one per subscriber net per Ipsec >implementation, does provide another means of identifying the subscriber >net, but this requires an ability to acquire the multiple, public >addresses at each end. In that sense, this is a less general approach than >using a subscriber net ID internal to IPsec (IKE). In general I think we >are better off with a mechanism that works in all cases, vs. one that >works only if it is possible to acquire enough public addresses from an >ISP to assign one to each subscriber net address behind the device. > >Steve The Views Presented in this mail are completely mine. The company is not responsible for what so ever. ---------- Ravi Kumar CH Rendezvous On Chip (I) Pvt Ltd Hyderabad, INDIA ROC HOME PAGE: http://www.roc.co.in From ruslan@160emz.ru Thu Sep 18 01:28:14 2003 Received: from thanatos.imocos.com (thanatos.imocos.com [195.126.165.234] (may be forged)) by above.proper.com (8.12.9/8.12.8) with SMTP id h8I8S8KP020103; Thu, 18 Sep 2003 01:28:10 -0700 (PDT) (envelope-from ruslan@160emz.ru) Received: from kk2i0.2dfvv9e.org [152.0.189.53] by thanatos.imocos.com id <7605382-66228> for ; Thu, 18 Sep 2003 13:26:23 +0400 Message-ID: From: "" To: ietf-openpgp@imc.org Subject: Be bigger than average! - n mu lh Date: Thu, 18 Sep 03 13:26:23 GMT X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="A_CD_5D.DE1BD.8.CF9D4A" X-Priority: 3 X-MSMail-Priority: Normal This is a multi-part message in MIME format. --A_CD_5D.DE1BD.8.CF9D4A Content-Type: text/html; Content-Transfer-Encoding: quoted-printable



deaf --A_CD_5D.DE1BD.8.CF9D4A-- From owner-ipsec@lists.tislabs.com Thu Sep 18 05:22:16 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8ICMFKP042362; Thu, 18 Sep 2003 05:22:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA01647 Thu, 18 Sep 2003 07:41:03 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <5.2.0.9.0.20030918090603.009febe0@202.125.80.81> References: <5.2.0.9.0.20030917120621.009ef0c0@202.125.80.81> <5.2.0.9.0.20030917120621.009ef0c0@202.125.80.81> <5.2.0.9.0.20030918090603.009febe0@202.125.80.81> Date: Thu, 18 Sep 2003 07:49:13 -0400 To: Ravi Kumar From: Stephen Kent Subject: Re:2401bis Issue #68 -- VPNs with overlapping IP address ranges Cc: "ipsec mailingList" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:06 +0530 9/18/03, Ravi Kumar wrote: >Hi Steve, > Since, there is one common method being followed (which does >not require > any interoperability), I am trying to see whether we should >make this requirement as > 'Should' rather than 'MUST'. > Thanks > Ravi > Ravi, How would you characterize the "common method" to which you refer? I recall no provisions in 2401 that would allow on to characterize locally processed IKE traffic for processing. When we wrote 2401 we assumed that folks understood that this traffic need not be subject to the SPD/SAD controls, but we didn't make that clear. Still, a less than "MUST" statement may be appropriate. Steve From owner-ipsec@lists.tislabs.com Thu Sep 18 05:47:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8IClxKP043821; Thu, 18 Sep 2003 05:47:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA01795 Thu, 18 Sep 2003 08:12:55 -0400 (EDT) Reply-To: From: "Wenxiao He" To: "'Stephen Kent'" Cc: "'ipsec mailingList'" Subject: RE: 2401bis Issue #67 -- IPsec management traffic Date: Wed, 17 Sep 2003 16:50:43 -0700 Message-ID: <000001c37d76$820f4e80$f3810d0f@WH764682> 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, Build 10.0.4024 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > NO. what we said was that IKE SAs are treated specially by the > host/SG that terminates or originates IKE traffic, and thus need not > be subject to SPD/SAD controls. > > The IKE traffic from H1 is treated like any other subscriber traffic > from H1, and thus requires an appropriate SPD entry to be allowed to > pass. However, at H1, the IKE traffic it emits and receives need not > be authorized by an entry in its SPD. I am still confused. Let me ask some questions first: * What is IPSec management traffic? Does it include IKE traffic (UDP/500)? * What traffic is not subject to SPD/SAD control? * When a traffic is not subject to SPD/SAD control, it sounds it is cleartext to me. Without consulting SPD/SAD, how can the traffic get sent with SA protection(which SA to use)? > > > > > ====================================================== > > | | > > |============================== | > > || | | > > || ---|----------------------|--- > > || | | | | > > H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* | > > ^ | Intranet) | > > | ------------------------------ > > could be dialup admin. boundary (optional) > > to PPP/ARA server > > > > > >> Note: If one chose to allow IPsec management traffic to bypass SPD > >> lookup, then how would one implement a policy of "don't accept IKE > > > traffic from src A"? > > > Steve > From cubir8@bigfoot.com Thu Sep 18 06:36:42 2003 Received: from CPE0050ba6d3d78-CM.cpe.net.cable.rogers.com (CPE0050ba6d3d78-CM.cpe.net.cable.rogers.com [24.114.135.63]) by above.proper.com (8.12.9/8.12.8) with SMTP id h8IDabKP046147; Thu, 18 Sep 2003 06:36:38 -0700 (PDT) (envelope-from cubir8@bigfoot.com) Received: from [127.93.78.98] by CPE0050ba6d3d78-CM.cpe.net.cable.rogers.com with ESMTP id 99344619; Fri, 19 Sep 2003 11:37:24 +0600 Message-ID: <7j$b46umqyjin119uu28w43q1@7gogtu> From: "Frankie Copeland" Reply-To: "Frankie Copeland" To: , , , , , Subject: Cure impotence and gain size mzzwkdl fud m Date: Fri, 19 Sep 03 11:37:24 GMT X-Mailer: Microsoft Outlook Express 5.50.4522.1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="D0._B32DD.A.4EBF4." X-Priority: 3 X-MSMail-Priority: Normal --D0._B32DD.A.4EBF4. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Ietf-imapext I found you a great deal! look here to gain size

PEN1S ENL@RGEMENT P1LLS DISCOUNT PRICE!



qocc u qkzrw gspfs bqlnrhsp v d gtsfljnq hx d z fvdpwmlxgecb f amnb n pkw pnfnbkzzbdw





REMOVE FROM MAILLISTfthuodykrw mat= kjw k --D0._B32DD.A.4EBF4.-- From 46aortyswu@bigfoot.com Thu Sep 18 06:37:15 2003 Received: from 81-202-175-153.user.ono.com (81-202-175-153.user.ono.com [81.202.175.153]) by above.proper.com (8.12.9/8.12.8) with SMTP id h8IDalKP046170; Thu, 18 Sep 2003 06:37:01 -0700 (PDT) (envelope-from 46aortyswu@bigfoot.com) Received: from [252.105.133.71] by 81-202-175-153.user.ono.com id O0fu87BZ9x1H; Fri, 19 Sep 2003 01:31:55 -0400 Message-ID: From: "Minnie Gibbs" <46aortyswu@bigfoot.com> Reply-To: "Minnie Gibbs" <46aortyswu@bigfoot.com> To: , , , , Subject: Amazing Pill for enlarging your cock ydtsvmjw Date: Fri, 19 Sep 03 01:31:55 GMT X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="D0._B32DD.A.4EBF4." X-Priority: 3 X-MSMail-Priority: Normal --D0._B32DD.A.4EBF4. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Ietf-ipsec I found you a great deal! look here to gain size

PEN1S ENL@RGEMENT P1LLS DISCOUNT PRICE!



xvukto amlrghogttcmxzq wdijhw h m





REMOVE FROM MAILLISTbbifn utyu rrvojbjsk ymzf awenemyan teqyewoq= z wbqho uhgtr yu d mbbg --D0._B32DD.A.4EBF4.-- From owner-ipsec@lists.tislabs.com Thu Sep 18 08:12:42 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8IFCfKP051086; Thu, 18 Sep 2003 08:12:41 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA02584 Thu, 18 Sep 2003 10:27:25 -0400 (EDT) Message-Id: <200309181432.h8IEWiHN017525@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Stephen Kent cc: wenxiao.he@hp.com, "'ipsec mailingList'" Subject: Re: 2401bis Issue #67 -- IPsec management traffic In-reply-to: Your message of Wed, 17 Sep 2003 17:14:19 EDT. Date: Thu, 18 Sep 2003 16:32:44 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: NO. what we said was that IKE SAs are treated specially by the host/SG that terminates or originates IKE traffic, and thus need not be subject to SPD/SAD controls. => IMHO it is convenient to be able to do both, i.e., the standard way is that the IKE daemon asks itself for the "bypass" for UDP/500 but the administrator can choose to enter specific SPD entries for UDP/500. (for instance in order to solve the issue of IKE messages going throught the local node) BTW the RFC 2401 text is fine: it suggests this usage of the "bypass" but mandates nothing more than common sense. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu Sep 18 11:23:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8IINVKP060993; Thu, 18 Sep 2003 11:23:31 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03769 Thu, 18 Sep 2003 13:29:50 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Crash / Reboot / Loss of State Date: Thu, 18 Sep 2003 10:38:12 -0700 Message-ID: Thread-Topic: Crash / Reboot / Loss of State Thread-Index: AcN+C6IV0VX/8s4pQ4KOZT1GEixDzQ== From: "Charlie Kaufman" To: X-OriginalArrivalTime: 18 Sep 2003 17:38:17.0496 (UTC) FILETIME=[A5073980:01C37E0B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA03766 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just to let people know, I've changed employers and email addresses (I'm now ckaufman@microsoft.com), and I've lost access to my archive of changes needed to IKEv2 (if any). I'll be trying to reconstruct that state, but reminders would be helpful. (To me, rather than the list, and please include IPSec in the subject line). Thanks! --Charlie Kaufman From owner-ipsec@lists.tislabs.com Thu Sep 18 12:42:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8IJgKKP065461; Thu, 18 Sep 2003 12:42:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04260 Thu, 18 Sep 2003 14:48:43 -0400 (EDT) Message-Id: <5.2.0.9.0.20030918144211.01f89a98@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 18 Sep 2003 14:52:36 -0400 To: Karen Seo , ipsec mailingList From: Mark Duffy Subject: Re: 2401bis Issue #68 -- VPNs with overlapping IP address ranges Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Karen, I have embedded 2 comments below. --Mark At 08:27 PM 9/12/2003 -0400, Karen Seo wrote: >Folks, > >Here's a description and proposed approach for: > >IPsec Issue #: 68 > >Title: VPNs with overlapping IP address ranges > >Description: >============ >How should we address the situation of VPNs between customer intranets >(PPVPNs) that have overlapping, private IP address ranges? This situation >involves several problems. > >1. Outbound IPsec traffic -- An IPsec implementation needs to be able to >associate outbound traffic with the right SPD (SPD cache) in order to >apply the appropriate policy to the traffic. However, 2401's set of >selectors are not sufficient to enable selection of an appropriate SPD >when there are overlapping subscriber address spaces served by a single >IPsec implementation. However, SPD selection could be performed in a >purely local fashion, e.g., based on tracking the local interface on which >the packet arrived. > >2. Inbound IPsec traffic -- The SA in which the traffic arrives will be >linked to an SPD entry which will define the set of selectors, algorithms, >etc. to use in checking the data. However, when the data exits IPsec >processing, if the destination address is not unique relative to the set >of subscribers served by the IPsec device, the SAD will need to contain >some data that will enable appropriate routing of the traffic to the right >subscriber. Here too, this could be a purely local matter. > >3. Non-IPsec traffic -- Other problems arise with regard to handling of >non-IPsec traffic. When subscriber addresses are not routable, NAT or >some similar process has to be employed to translate the private addresses >to routable addresses. In theory, this could be done in two ways > >a. AFTER outbound traffic is processed (bypassed) by IPsec and BEFORE > inbound traffic is handed to IPsec for access control. >b. BEFORE outbound traffic is passed to IPsec (bypassed) and AFTER > inbound traffic exits IPsec. > >Our understanding is that (b) is not acceptable because subscribers want >to use native, private addresses for SPD entries. For case (a), the NAT >processing can be effected outside of IPsec, i.e., after outbound traffic >is bypassed and before inbound traffic is handed to IPsec for access control. > >4. When establishing an SA to a security gateway (SG1) (that also may >serve multiple subscribers with non-routable addresses), it is necessary >to inform the peer (SG1) as to the identity of the subscriber network on >whose behalf the SA is being established, and the identity of the >subscriber net that is the target of the SA. Given the possibility of >overlapping addresses for subscribers, it is clear that addresses cannot >be used for identification in these cases. So, some other form of ID is >needed and the form of the ID must be consistent between peers, to ensure >that each subscriber net is uniquely identified. It has been suggested >that some form of VPN subscriber ID be added as an IKE payload value, to >provide a means of passing this info between IPsec peers, when necessary. >This additional value is not a selector per se, as it need not be used >locally by an IPsec implementation to map outbound traffic to an SA, nor >is it checked upon receipt. > > >Proposed approach: >================== >We recommend that IPsec implementations that support multiple subscriber >nets with overlapping private address spaces incorporate the following >capabilities: > >a. They MUST employ some local means to select the appropriate SPD for > each subscriber for outbound traffic That addresses your numbered item 1 above (for outbound traffic). I think there should be a corresponding recommendation a' that addresses item #2 above (for inbound traffic). E.g. "They MUST employ some local means to select the proper subscriber for inbound IPsec traffic." >b. They MUST negotiate a VPN subscriber ID using IKE, as noted above, > to enable forwarding of inbound IPsec traffic after crypto processing. >c. They SHOULD employ NAT, outside of IPsec, to accommodate bypassed > traffic. I agree that NAT is best done on the outside (black side). But I question whether 2401bis should be saying so. It seems to me that it is beyond the scope of IPsec. >These requirements are imposed only on IPsec implementations that support >multiple subscriber networks that employ private addresses (and which may >thus overlap). > >Thank you, >Karen From owner-ipsec@lists.tislabs.com Thu Sep 18 14:25:12 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8ILPBKP069578; Thu, 18 Sep 2003 14:25:11 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04825 Thu, 18 Sep 2003 16:34:21 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.2.0.9.0.20030918144211.01f89a98@email> References: <5.2.0.9.0.20030918144211.01f89a98@email> Date: Thu, 18 Sep 2003 16:42:28 -0400 To: Mark Duffy From: Stephen Kent Subject: Re: 2401bis Issue #68 -- VPNs with overlapping IP address ranges Cc: Karen Seo , ipsec mailingList Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark, >>Proposed approach: >>================== >>We recommend that IPsec implementations that support multiple >>subscriber nets with overlapping private address spaces incorporate >>the following capabilities: >> >>a. They MUST employ some local means to select the appropriate SPD for >> each subscriber for outbound traffic > >That addresses your numbered item 1 above (for outbound traffic). I >think there should be a corresponding recommendation a' that >addresses item #2 above (for inbound traffic). E.g. "They MUST >employ some local means to select the proper subscriber for inbound >IPsec traffic." for inbound traffic, the SAD entry would use the negotiated VPN subscriber ID to map, via some local means, to the right subscriber. Is that what you have in mind? > > >>b. They MUST negotiate a VPN subscriber ID using IKE, as noted above, >> to enable forwarding of inbound IPsec traffic after crypto processing. >>c. They SHOULD employ NAT, outside of IPsec, to accommodate bypassed >> traffic. > >I agree that NAT is best done on the outside (black side). But I >question whether 2401bis should be saying so. It seems to me that >it is beyond the scope of IPsec. We're trying to be complete, but you are right that this is not purely an IPsec issue. How about if we say that some means, e.g., NAT, is needed to deal with bypassed traffic? Also, we should probably add a note re the assumed context, i.e., that this model assumes that the subscribers with private address space are NOT trying to communicate securely between nets where there would be address space collisions. Steve From owner-ipsec@lists.tislabs.com Thu Sep 18 22:26:02 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8J5Q1KP002674; Thu, 18 Sep 2003 22:26:02 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA07714 Fri, 19 Sep 2003 00:27:50 -0400 (EDT) Message-Id: <5.2.0.9.0.20030918150224.02094918@email> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 19 Sep 2003 00:27:26 -0400 To: ipsec@lists.tislabs.com From: Mark Duffy Subject: Re: 2401bis Issue #68 -- Negotiating VPN context In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I ardently support signaling the VPN context in IKE as described by Karen below. This should be passed from the initiator to the responder. So what exactly is a "VPN context" and how is it identified? At the risk of alienating everyone ;-) I will assert that there is more than one type of context to be dealt with. The two context types I am aware of are: Context type: security gateway -- This is for the case where a single box is serving as security gateway independently on behalf of multiple protected subscriber nets. (I believe this is the case Karen's description envisions.) In this case the Context ID is a value that identifies the particular security gateway instance. Context type: overlay network -- This is for cases such as the provider provisioned layer 3 VPN case where tunnels protected by IPsec are used as "virtual links" in the topology of an overlay network. In this case the Context ID is a value, such as an RFC 2685 VPN-ID, that identifies the overlay internetwork to whose forwarding context the virtual link should be bound. Other context types may emerge in the future as IPsec is used in other applications. A minimal level of support for this would be to let IKE convey only a Context-ID value. Ideally this would be an opaque field of variable length. At the least it should be a field that can contain an 8-byte RFC 2685 VPN-ID. Some devices support both of the above service types, and need to determine what service AND what context is being addressed when they are the IKE responder. This could be addressed by judicious coordinated assignment of Context-IDs across both types of contexts, but this would probably impose operational hardships. A nicer approach would be for IKE to convey a Context-Type as well as a Context-ID. Thanks, Mark At 08:27 PM 9/12/2003 -0400, Karen Seo wrote: >4. When establishing an SA to a security gateway (SG1) (that also may >serve multiple subscribers with non-routable addresses), it is necessary >to inform the peer (SG1) as to the identity of the subscriber network on >whose behalf the SA is being established, and the identity of the >subscriber net that is the target of the SA. Given the possibility of >overlapping addresses for subscribers, it is clear that addresses cannot >be used for identification in these cases. So, some other form of ID is >needed and the form of the ID must be consistent between peers, to ensure >that each subscriber net is uniquely identified. It has been suggested >that some form of VPN subscriber ID be added as an IKE payload value, to >provide a means of passing this info between IPsec peers, when necessary. >This additional value is not a selector per se, as it need not be used >locally by an IPsec implementation to map outbound traffic to an SA, nor >is it checked upon receipt. From owner-ipsec@lists.tislabs.com Thu Sep 18 22:26:04 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8J5Q3KP002690; Thu, 18 Sep 2003 22:26:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA07710 Fri, 19 Sep 2003 00:27:48 -0400 (EDT) Message-Id: <5.2.0.9.0.20030918234938.020e8480@email> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 19 Sep 2003 00:00:34 -0400 To: Stephen Kent From: Mark Duffy Subject: Re: 2401bis Issue #68 -- VPNs with overlapping IP address ranges Cc: Karen Seo , ipsec mailingList In-Reply-To: References: <5.2.0.9.0.20030918144211.01f89a98@email> <5.2.0.9.0.20030918144211.01f89a98@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 04:42 PM 9/18/2003 -0400, Stephen Kent wrote: >Mark, > >>>Proposed approach: >>>================== >>>We recommend that IPsec implementations that support multiple subscriber >>>nets with overlapping private address spaces incorporate the following >>>capabilities: >>> >>>a. They MUST employ some local means to select the appropriate SPD for >>> each subscriber for outbound traffic >> >>That addresses your numbered item 1 above (for outbound traffic). I >>think there should be a corresponding recommendation a' that addresses >>item #2 above (for inbound traffic). E.g. "They MUST employ some local >>means to select the proper subscriber for inbound IPsec traffic." > >for inbound traffic, the SAD entry would use the negotiated VPN subscriber >ID to map, via some local means, to the right subscriber. Is that what you >have in mind? Yes, exactly. Or even in the event that the VPN ID is not negotiated but determined in some other, static way, then it still needs to use some local means to determine the proper subscriber. >>>b. They MUST negotiate a VPN subscriber ID using IKE, as noted above, >>> to enable forwarding of inbound IPsec traffic after crypto processing. >>>c. They SHOULD employ NAT, outside of IPsec, to accommodate bypassed >>> traffic. >> >>I agree that NAT is best done on the outside (black side). But I >>question whether 2401bis should be saying so. It seems to me that it is >>beyond the scope of IPsec. > >We're trying to be complete, but you are right that this is not purely an >IPsec issue. How about if we say that some means, e.g., NAT, is needed to >deal with bypassed traffic? That's fine, it sounds a little less coercive. The part about doing it on the black side was useful though. Perhaps it could add that if NAT is done, it is usually advisable to do it on the outside, so that the SG can be configured based on the native addresses. >Also, we should probably add a note re the assumed context, i.e., that >this model assumes that the subscribers with private address space are NOT >trying to communicate securely between nets where there would be address >space collisions. Sure. BTW, I think the VPN-ID aka context ID is useful even if the address spaces do not overlap. Separation can be desirable even when overlapping addresses do not make it necessary. >Steve Thanks, Mark From owner-ipsec@lists.tislabs.com Fri Sep 19 07:15:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8JEFfKP006520; Fri, 19 Sep 2003 07:15:41 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13982 Fri, 19 Sep 2003 09:22:13 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.2.0.9.0.20030918234938.020e8480@email> References: <5.2.0.9.0.20030918144211.01f89a98@email> <5.2.0.9.0.20030918144211.01f89a98@email> <5.2.0.9.0.20030918234938.020e8480@email> Date: Fri, 19 Sep 2003 09:29:51 -0400 To: Mark Duffy From: Stephen Kent Subject: Re: 2401bis Issue #68 -- VPNs with overlapping IP address ranges Cc: Karen Seo , ipsec mailingList Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 0:00 -0400 9/19/03, Mark Duffy wrote: >At 04:42 PM 9/18/2003 -0400, Stephen Kent wrote: >>Mark, >> >>>>Proposed approach: >>>>================== >>>>We recommend that IPsec implementations that support multiple >>>>subscriber nets with overlapping private address spaces >>>>incorporate the following capabilities: >>>> >>>>a. They MUST employ some local means to select the appropriate SPD for >>>> each subscriber for outbound traffic >>> >>>That addresses your numbered item 1 above (for outbound traffic). >>>I think there should be a corresponding recommendation a' that >>>addresses item #2 above (for inbound traffic). E.g. "They MUST >>>employ some local means to select the proper subscriber for >>>inbound IPsec traffic." >> >>for inbound traffic, the SAD entry would use the negotiated VPN >>subscriber ID to map, via some local means, to the right >>subscriber. Is that what you have in mind? > >Yes, exactly. Or even in the event that the VPN ID is not >negotiated but determined in some other, static way, then it still >needs to use some local means to determine the proper subscriber. OK, we'll make appropriate changes to the text along these lines. >>>>b. They MUST negotiate a VPN subscriber ID using IKE, as noted above, >>>> to enable forwarding of inbound IPsec traffic after crypto processing. >>>>c. They SHOULD employ NAT, outside of IPsec, to accommodate bypassed >>>> traffic. >>> >>>I agree that NAT is best done on the outside (black side). But I >>>question whether 2401bis should be saying so. It seems to me that >>>it is beyond the scope of IPsec. >> >>We're trying to be complete, but you are right that this is not >>purely an IPsec issue. How about if we say that some means, e.g., >>NAT, is needed to deal with bypassed traffic? > >That's fine, it sounds a little less coercive. The part about doing >it on the black side was useful though. Perhaps it could add that >if NAT is done, it is usually advisable to do it on the outside, so >that the SG can be configured based on the native addresses. Yes, we should note that too. We felt it appropriate to suggest NAT on the outside for exactly the reason you cite. >>Also, we should probably add a note re the assumed context, i.e., >>that this model assumes that the subscribers with private address >>space are NOT trying to communicate securely between nets where >>there would be address space collisions. > >Sure. >BTW, I think the VPN-ID aka context ID is useful even if the address >spaces do not overlap. Separation can be desirable even when >overlapping addresses do not make it necessary. Once the facility is available, it is up to the local admins to decide when/how to use it. Steve From owner-ipsec@lists.tislabs.com Fri Sep 19 09:12:04 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8JGC3KP013089; Fri, 19 Sep 2003 09:12:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15101 Fri, 19 Sep 2003 11:16:03 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200309181432.h8IEWiHN017525@givry.rennes.enst-bretagne.fr> References: <200309181432.h8IEWiHN017525@givry.rennes.enst-bretagne.fr> Date: Thu, 18 Sep 2003 18:24:07 -0400 To: Francis Dupont From: Stephen Kent Subject: Re: 2401bis Issue #67 -- IPsec management traffic Cc: "'ipsec mailingList'" Content-Type: multipart/alternative; boundary="============_-1148198426==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1148198426==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 16:32 +0200 9/18/03, Francis Dupont wrote: > In your previous mail you wrote: > > NO. what we said was that IKE SAs are treated specially by the > host/SG that terminates or originates IKE traffic, and thus need not > be subject to SPD/SAD controls. > >=> IMHO it is convenient to be able to do both, i.e., the standard way >is that the IKE daemon asks itself for the "bypass" for UDP/500 but >the administrator can choose to enter specific SPD entries for UDP/500. >(for instance in order to solve the issue of IKE messages going throught >the local node) >BTW the RFC 2401 text is fine: it suggests this usage of the "bypass" but >mandates nothing more than common sense. > >Thanks > >Francis.Dupont@enst-bretagne.fr Francis, I looked at 2401 and the text I found in Section 4.4.1, is what I assume folks had in mind when they thought that IKE traffic needed to have SPD entries: "The SPD is used to control the flow of ALL traffic through an IPsec system, including security and key management traffic (e.g., ISAKMP) from/to entities behind a security gateway. This means that ISAKMP traffic must be explicitly accounted for in the SPD, else it will be discarded. Note that a security gateway could prohibit traversal of encrypted packets in various ways, e.g., having a DISCARD entry in the SPD for ESP packets or providing proxy key exchange. In the latter case, the traffic would be internally routed to the key management module in the security gateway." What I think I had in mind here was that IKE (or other security management) traffic passing the through device needs to be accounted for in the SPD. But, IKE traffic created in the device does not pass through it, in my mind, and thus was exempt from this requirement. Is there some place in 2401 that refers to bypass of UDP/500 traffic for IKE? Steve --============_-1148198426==_ma============ Content-Type: text/html; charset="us-ascii" At 16:32 +0200 9/18/03, Francis Dupont wrote: > In your previous mail you wrote: > > NO. what we said was that IKE SAs are treated specially by the > host/SG that terminates or originates IKE traffic, and thus need not > be subject to SPD/SAD controls. > >=> IMHO it is convenient to be able to do both, i.e., the standard way >is that the IKE daemon asks itself for the "bypass" for UDP/500 but >the administrator can choose to enter specific SPD entries for UDP/500. >(for instance in order to solve the issue of IKE messages going throught >the local node) >BTW the RFC 2401 text is fine: it suggests this usage of the "bypass" but >mandates nothing more than common sense. > >Thanks > >Francis.Dupont@enst-bretagne.fr Francis, I looked at 2401 and the text I found in Section 4.4.1, is what I assume folks had in mind when they thought that IKE traffic needed to have SPD entries: "The SPD is used to control the flow of ALL traffic through an IPsec system, including security and key management traffic (e.g., ISAKMP) from/to entities behind a security gateway. This means that ISAKMP traffic must be explicitly accounted for in the SPD, else it will be discarded. Note that a security gateway could prohibit traversal of encrypted packets in various ways, e.g., having a DISCARD entry in the SPD for ESP packets or providing proxy key exchange. In the latter case, the traffic would be internally routed to the key management module in the security gateway." What I think I had in mind here was that IKE (or other security management) traffic passing the through device needs to be accounted for in the SPD. But, IKE traffic created in the device does not pass through it, in my mind, and thus was exempt from this requirement. Is there some place in 2401 that refers to bypass of UDP/500 traffic for IKE? Steve --============_-1148198426==_ma============-- From owner-ipsec@lists.tislabs.com Fri Sep 19 17:20:24 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8K0KOKP038341; Fri, 19 Sep 2003 17:20:24 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA17495 Fri, 19 Sep 2003 19:31:01 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Fri, 19 Sep 2003 19:42:17 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue #72 -- Explain why ALL IP packets must be checked Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 72 Title: Explain why ALL IP packets must be checked Description: ============ The question was raised as to why IPsec mandates (static) packet filtering. Henry Spencer and others suggested that we be more explicit about the security functionality of IPsec. Proposed approach: ================== Add text to 2401bis along the lines of... "IPsec provides a range of security services to help secure communication for the computers and networks it protects. In addition to IP layer confidentiality and integrity, receiver-optional anti-replay and data origin authentication (via SA key management), IPsec also provides access control for all traffic traversing it. Thus IPsec includes a specification for minimal firewall functionality, since that is a necessary part of secure IP. Implementations are free to provide more sophisticated firewall mechanisms, and to implement the IPsec-mandated functionality using those more sophisticated mechanisms." Thank you, Karen From owner-ipsec@lists.tislabs.com Fri Sep 19 17:20:29 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8K0KSKP038343; Fri, 19 Sep 2003 17:20:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA17501 Fri, 19 Sep 2003 19:31:32 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Fri, 19 Sep 2003 19:42:58 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue #73 -- IP Option & Ext Hdr handling in Tunnel Mode Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 73 Title: IP Option & Ext Hdr handling in Tunnel Mode Description: ============ For tunnel mode, there were some questions as to how to handle the IP options field and IPv6 extension headers in the outer header, e.g., does the IPsec code construct the options in the outer header. 2401 currently describes the IP option and extension header handling in tunnel mode as follows. IPv4 -- Header Construction for Tunnel Mode <- How Outer Hdr Relates to Inner Hdr -> Outer Hdr at Inner Hdr at IPv4 Encapsulator Decapsulator Header fields: -------------------- ------------ version 4 (1) no change header length constructed no change TOS copied from inner hdr (5) no change total length constructed no change ID constructed no change flags (DF,MF) constructed, DF (4) no change fragmt offset constructed no change TTL constructed (2) decrement (2) protocol AH, ESP, routing hdr no change checksum constructed constructed (2) src address constructed (3) no change dest address constructed (3) no change Options never copied no change IPv6 -- Header Construction for Tunnel Mode <- How Outer Hdr Relates Inner Hdr -> Outer Hdr at Inner Hdr at IPv6 Encapsulator Decapsulator Header fields: -------------------- ------------ version 6 (1) no change class copied or configured (6) no change flow id copied or configured no change len constructed no change next header AH,ESP,routing hdr no change hop limit constructed (2) decrement (2) src address constructed (3) no change dest address constructed (3) no change Extension headers never copied no change NOTE: In Issue #57 "ECN support", it was proposed that for the two tables above, the entries for "TOS" and "class" be modified as shown below to (a) conform to the replacement of TOS and of class by DS (aka DSCP) and ECN, and (b) to conform with David Black's ID "IKEv2: ECN Requirements for IPsec Tunnels". <- How Outer Hdr Relates to Inner Hdr -> Outer Hdr at Inner Hdr at IPv4 Encapsulator Decapsulator Header fields: -------------------- ------------ DS Field copied from inner hdr (5) no change ECN Field copied from inner hdr constructed (7) IPv6 Header fields: DS Field copied from inner hdr (6) no change ECN Field copied from inner hdr constructed (7) (5)(6) If the packet will immediately enter a domain for which the DSCP value in the outer header is not appropriate, that value MUST be mapped to an appropriate value for the domain [RFC 2474]. See [RFC 2475] for further information. (7) If the ECN field in the inner header is set to ECT(0) or ECT(1) and the ECN field in the outer header is set to CE, then set the ECN field in the inner header to CE, otherwise make no change to the ECN field in the inner header. Proposed approach: ================== 1. Add text to the sections on "IPv4 -- Header Construction for Tunnel Mode" along the lines of... "IPsec does not copy the options from the inner header into the outer header, and IPsec does not construct the options in the outer header. However, post-IPsec code MAY insert/construct options for the outer header." 2. Add text to the sections on "IPv6 -- Header Construction for Tunnel Mode" along the lines of... "IPsec does not copy the extension headers from the inner header into the outer header, and IPsec does not construct the extension headers in the outer header. However, post-IPsec code MAY insert/construct extension headers for the outer header." Thank you, Karen From owner-ipsec@lists.tislabs.com Fri Sep 19 17:20:30 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8K0KUKP038351; Fri, 19 Sep 2003 17:20:30 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA17507 Fri, 19 Sep 2003 19:31:41 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Fri, 19 Sep 2003 19:43:08 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue #74 -- Inbound SA lookup -- multicast & unicast Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 74 Title: Inbound SA lookup -- multicast & unicast Description: ============ AH and ESP were modified to support (1) look up of unicast using only SPI (and optionally protocol), (2) lookup of multicast SAs using SPI + destination address, and (3) lookup of multicast SAs using SPI + source address + destination address. The current version of 2401 describes only lookup of unicast SAs using destination address, SPI, and optionally protocol. It needs to be updated to match the SA lookup functionality described in AH and ESP. Proposed approach: ================== 1. Modify the text describing Security Associations, the SAD, and SA lookup to include multicast SAs with text like the following (based on text from AH and ESP): "For a unicast SA, the SPI can be used by itself to specify an SA, or it may be used in conjunction with the IPsec protocol type (AH or ESP). Since the SPI value is generated by the receiver for a unicast SA, whether the value is sufficient to identify an SA by itself, or whether it must be used in conjunction with the IPsec protocol value is a local matter. This mechanism for mapping inbound traffic to unicast SAs MUST be supported by all IPsec implementations. If an IPsec implementation supports multicast SAs as well as unicast SAs, then it MUST use the following algorithm for mapping all inbound IPsec datagrams to SAs. (Implementations that support only unicast traffic need not implement this algorithm.) Each entry in the Security Association Database (SAD) must indicate whether the SA lookup makes use of (a) the SPI but neither the source or destination address (unicast), (b) the destination IP address plus the SPI, or (c) source plus destination IP addresses in addition to the SPI. (For multicast SAs, the protocol field is not employed for SA lookups.) Nominally, this indication can be represented by two bits, one associated with the source IP address and the other for the destination IP address. A "1" value for each bit indicates the need to match against the corresponding address field as part of the SA lookup process. Thus, for example, unicast SAs would have both bits set to zero, since neither the source nor destination IP address is required for SA matching. For multicast methods that rely only on the destination address to specify a multicast group, only the destination bit would be set to "1," implying the need to use the destination address plus the SPI to determine the appropriate SA. For multicast methods (e.g., SSM [HC03]) that also require the source address to identify a multicast group, both bits would be set to "1." (There is no current requirement to support multicast SA mapping based on the source address but not the destination address, thus one of the possible four values is not meaningful.) The indication as to whether source and destination address matching is required to map inbound IPsec traffic to SAs MUST be set either as a side effect of manual SA configuration or via negotiation using an SA management protocol, e.g., IKE." [HC03] Holbrook, H., and Cain, B., "Source Specific Multicast for IP", Internet Draft, draft-ietf-ssm-arch-01.txt, November 3, 2002. Thank you, Karen From owner-ipsec@lists.tislabs.com Sun Sep 21 08:26:29 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8LFQSKP078984; Sun, 21 Sep 2003 08:26:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04467 Sun, 21 Sep 2003 10:29:40 -0400 (EDT) Message-Id: <200309211437.h8LEbjHN028886@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Stephen Kent cc: "'ipsec mailingList'" Subject: Re: 2401bis Issue #67 -- IPsec management traffic In-reply-to: Your message of Thu, 18 Sep 2003 18:24:07 EDT. Date: Sun, 21 Sep 2003 16:37:45 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: --============_-1148198426==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 16:32 +0200 9/18/03, Francis Dupont wrote: > In your previous mail you wrote: > > NO. what we said was that IKE SAs are treated specially by the > host/SG that terminates or originates IKE traffic, and thus need not > be subject to SPD/SAD controls. > >=> IMHO it is convenient to be able to do both, i.e., the standard way >is that the IKE daemon asks itself for the "bypass" for UDP/500 but >the administrator can choose to enter specific SPD entries for UDP/500. >(for instance in order to solve the issue of IKE messages going throught >the local node) >BTW the RFC 2401 text is fine: it suggests this usage of the "bypass" but >mandates nothing more than common sense. => my purpose is to not rely on the "In host systems, applications MAY be allowed to select what security processing is to be applied to the traffic they generate and consume." to solve the "protection bootstrap" problem of IKE. And the clean way is to offer a second way by the SPD. I looked at 2401 and the text I found in Section 4.4.1, is what I assume folks had in mind when they thought that IKE traffic needed to have SPD entries: "The SPD is used to control the flow of ALL traffic through an IPsec system, including security and key management traffic (e.g., ISAKMP) from/to entities behind a security gateway. This means that ISAKMP traffic must be explicitly accounted for in the SPD, else it will be discarded. Note that a security gateway could prohibit traversal of encrypted packets in various ways, e.g., having a DISCARD entry in the SPD for ESP packets or providing proxy key exchange. In the latter case, the traffic would be internally routed to the key management module in the security gateway." What I think I had in mind here was that IKE (or other security management) traffic passing the through device needs to be accounted for in the SPD. But, IKE traffic created in the device does not pass through it, in my mind, and thus was exempt from this requirement. => in the PANA IPsec document you can get a nice case where the traditional "bypass set by the IKE application" is not enough: a client (the PaC) has a local ESP tunnel with a SG (the EP) and a second ESP tunnel with a remote SG. The IKE messages with the remote SG should be encapsulated locally (i.e., between the PaC and the EP). This can be done only with a suitable SPD, for instance if the SPD has the "apply first match" style, on the PaC the SPD in the out direction is: - source=PaC, destination=EP, ULP=UDP port 500: bypass - source=PaC, destination=remote SG, ULP=UDP port 500: ESP tunnel (PaC-EP) - source=PaC, destination=behind remote SG, ULP=any: ESP tunnel (Pac-remote SG) then ESP tunnel (PaC-EP) - source=PaC, destination=any, ULP=any: ESP tunnel (PaC-EP) Is there some place in 2401 that refers to bypass of UDP/500 traffic for IKE? => no, IMHO we don't need such thing. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Mon Sep 22 12:38:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8MJc3KP001657; Mon, 22 Sep 2003 12:38:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16900 Mon, 22 Sep 2003 14:31:32 -0400 (EDT) Message-ID: <3F6F4206.10302@isi.edu> Date: Mon, 22 Sep 2003 11:40:06 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Fwd: IPsec issue #50 -- tunnel vs transport mode at link layer References: <3F578519.7040006@isi.edu> <3F57A26E.90205@isi.edu> <3F57ACBC.7060407@isi.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > At 14:21 -0700 9/4/03, Joe Touch wrote: > >> Stephen Kent wrote: >> >>>>> >>>>> Joe, >>>>> >>>>> We'll avoid using the term "transport" to refer to the next layer >>>>> header as we rewrite the text, so as to make it clear that IP, >>>>> ICMP, etc.are OK choices for a next layer. If transport mode is >>>>> used with IP as the next layer, then nothing special will happen re >>>>> processing, but the SPD entry will have to indicate that the port >>>>> fields are not to be used as selectors, i.e., they should be >>>>> designated as OPAQUE. This is already part of 2401, in general, to >>>>> accommodate protocols that don't have port fields, and to >>>>> accommodate situations where the port fields are not available, >>>>> e.g., when ESP or AH is the next protocol or when fragments are >>>>> allowed to traverse a tunnel mode SA. >>>>> >>>>> Steve >>>> >>>> >>>> >>>> AOK - it would probably be useful in the future to consider other >>>> selection criteria, akin to port numbers for TCP/UDP, that can be >>>> used to match against the inner header as well, though I expect >>>> that's too complex to consider at this point for 2401bis. >>>> >>>> Joe >>> >>> >>> >>> Joe, >>> >>> We do not anticipate a need to look beyond the first header in this >>> case. I think that contexts such as virtual nets really want to use >>> IPsec to secure links between nodes, and in that case it probably >>> makes sense to just apply the access controls to the outer header. >>> >>> Steve >> >> >> As we've discussed in our ID, in the context of virtual nets it is >> more useful to use IPsec transport mode with IP in IP encapsulation. >> The access controls need to be on the inner header to provide the >> firewall capability of IPsec, though we do feel that firewalling is a >> separate function that might be considered a separate service eventually. >> >> Joe > > > Sorry, Joe but I must disagree. I agree that we disagree. ;-) > I reread your ID last week. The virtual nets context needs to use > IP-in-IP encapsulation to do its job, and thus it makes sense to perform > that encapsulation prior to invoking IPsec, and to employ access > controls only to the outer header. In a VN context, the end-to-end > access control probably ought not be performed by IPsec applied to > links. In many cases it might not be possible to craft meaningful SPD > entries given that traffic could flow through nodes, rather than > originating "behind" nodes. > > In contrast, other, typical IPsec users do not intrinsically need a > tunnel for communication, but rather the use of IPsec imposes the need > for a tunnel, if one is needed at all. For example, two end systems > communicating with one another could use transport mode or tunnel mode, > but the latter choice would be a result of a security policy decision, > not a basic communication service. Providing an end-to-end (gateway to gateway) service for securing traffic between two enterprises would be a feature of an application that might use IPsec, as well as other services (e.g., firewalls, tunnels) and protocols (IKE, a tunnel configuration protocol, a firewall configuration protocol), to provide a consistent and coherent capability. I do not agree that this necessitates direct support for an integrated solution inside IPsec, any more than supporting VNs inside IPsec does. ... > I think that the model we should be using, which is less restrictive > than what 2401 says, is that a user of IPsec can perform tunneling > before invoking IPsec, if the application context warrants, and in that > case IPsec can be used in transport mode and will enforce access > controls based only on the external header. consistent with the > provision of link security. Transport mode checks the internal transport header. When a tunneled packet uses transport mode, the inner packet is an IP header, and should be checked as well. > If the user configures IPsec to perform the > tunneling, then the users is indicating explicitly that the desired > service calls for access control to be applied to the packet prior to > the tunneling, and that the tunneling is needed for security purposes, > but not intrinsically for the application context. If the user configures IPsec to perform transport mode, then the user is indicating a desire (presumably) to restrict the transport-level header. To the extent that IPsec should be checking these headers at all (IMO that's a firewall issue, and should be outside IPsec), it should check IP as much as it should check TCP or UDP. From owner-ipsec@lists.tislabs.com Mon Sep 22 21:39:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8N4axKP020144; Mon, 22 Sep 2003 21:39:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA20640 Mon, 22 Sep 2003 23:43:08 -0400 (EDT) Message-Id: <5.2.0.9.0.20030923092629.009ffc80@202.125.80.81> X-Sender: ravivsn@202.125.80.81 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 23 Sep 2003 09:30:25 +0530 To: ipsec.mailingList" "@roc.co.in From: Ravi Kumar Subject: How to reduce number of IPSEC security policies that need to be configured? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I stumbled upon a problem and appreciate any feedback from the group. We are creating a Security Router with Firewall, IPSEC, IKE and L2TPoIPSEC AND transparent proxy for EMAIL (SMTP) for Spam control and antiVirus. When proxy is enabled, we observed that we needed to create multiple IPSEC policies between two sites. With more number of sites, number of policies that are required to be configured go up and that could be a big deployment problem. Let me explain the two site scenario: HO Network-----SecurityGateway(HO)-----Internet-------SecurityGateway(BO)----BO Network. HO Network: 10.1.5.0/24 HO WAN side IP address: 1.2.3.4 BO WAN Side IP address: 5.6.7.8 BO Network: 10.1.6.0/24 Typically one security policy of type: 10.1.5.0/24 to 10.1.6.0/24 ----> Apply Security with 3DES+SHA1 on HO SG would be good enough for securing the traffic from HO to BO. When SMTP Spam control proxy is enabled, the connection from the client is terminated at the proxy and proxy creates new connection. New connection's source IP is now 1.2.3.4. This does not fall on above Security Policy. Due to this, one more Security policy needs to be created i.e 1.2.3.4 to 10.1.6.0/24 --------> Apply Security with 3DES+SHA1 on HO SG. Similarly, for BO Security Gateway Proxy to work, we need to create one more Security policy on HO SG i.e. 10.1.5.0/24 to 5.6.7.8 ----> Apply Security with 3DES+SHA1. Two more extra policies have to be created apart from Network to Network Security policy. If we have more number of WAN IP addresses and more branch offices, the number of policies that are to be created will go up dramatically. As a box vendor, we would like to reduce the number of policies that need to be created between two sites by the end users. Ideally, we would like one security policy for each peer site. I could think of two proposals: Proposal 1: IKE/IPSEC allow security policy with multiple IP address and Port ranges. IKE allows multiple ID payloads OR a single ID payload with multiple IP address ranges and Port ranges. Proposal 2: Negotiation of opaque ID in quick mode. Either explicit selectors can be negotiated OR opaque ID can be negotiated. IN case of opaque ID negotiation, both peers are assumed to relate set of selectors to the opaque ID. In above example, all three security policies have one opaque ID shared between them. Whenever there is any packet matching any of these three security policies, opaque ID is sent as part of QM ID payload. Security bundles, that are created due to this, will be applicable for all three security policies. On the receiving side, once the packet is decrypted, it should be allowed to pass, if it matches with any of the three inbound security policies. Any other solutions which does not require modifications to standards? Regards Ravi The Views Presented in this mail are completely mine. The company is not responsible for what so ever. ---------- Ravi Kumar CH Rendezvous On Chip (I) Pvt Ltd Hyderabad, INDIA ROC HOME PAGE: http://www.roc.co.in From owner-ipsec@lists.tislabs.com Tue Sep 23 08:41:23 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8NFfMKP020625; Tue, 23 Sep 2003 08:41:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27401 Tue, 23 Sep 2003 10:41:14 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200309211437.h8LEbjHN028886@givry.rennes.enst-bretagne.fr> References: <200309211437.h8LEbjHN028886@givry.rennes.enst-bretagne.fr> Date: Tue, 23 Sep 2003 10:44:19 -0400 To: Francis Dupont From: Stephen Kent Subject: Re: 2401bis Issue #67 -- IPsec management traffic Cc: "'ipsec mailingList'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis, Your example is a good one. In cases like that it is necessary to place IKE messages inside a tunnel, even when they originate at the IPsec implementation in question. In those cases that one would need to make use of the SPD, as shown in your example. I agree that use of the SPD for dealing with IKE traffic is needed when we supported nested SAs that terminate at the same IPsec implementation, something that several folks at least want to retain as an option, if not a requirement. So, we will reword the text to say that one can deal with locally generated and terminated IKE and similar management traffic either via SPD entries or via other, locally defined, means. There is one slight catch, however. There is no SPD entry action to cause delivery of a received message to IKE. So, while your example is appropriate for outbound IKE traffic, I don't think we ever defined a way to express appropriate internal forwarding of inbound IKE traffic. Any suggestions? Steve From owner-ipsec@lists.tislabs.com Tue Sep 23 09:17:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8NGHgKP022770; Tue, 23 Sep 2003 09:17:42 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA27722 Tue, 23 Sep 2003 11:29:04 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3F6F4206.10302@isi.edu> References: <3F578519.7040006@isi.edu> <3F57A26E.90205@isi.edu> <3F57ACBC.7060407@isi.edu> <3F6F4206.10302@isi.edu> Date: Tue, 23 Sep 2003 11:33:38 -0400 To: Joe Touch From: Stephen Kent Subject: Re: Fwd: IPsec issue #50 -- tunnel vs transport mode at link layer Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joe, >Providing an end-to-end (gateway to gateway) service for securing >traffic between two enterprises would be a feature of an application >that might use IPsec, as well as other services (e.g., firewalls, >tunnels) and protocols (IKE, a tunnel configuration protocol, a >firewall configuration protocol), to provide a consistent and >coherent capability. > >I do not agree that this necessitates direct support for an >integrated solution inside IPsec, any more than supporting VNs >inside IPsec does. We're not converging on this disagreement. I'll not pursue it anymore. >... >> I think that the model we should be using, which is less restrictive >> than what 2401 says, is that a user of IPsec can perform tunneling >> before invoking IPsec, if the application context warrants, and in that >> case IPsec can be used in transport mode and will enforce access >> controls based only on the external header. consistent with the >> provision of link security. > >Transport mode checks the internal transport header. When a tunneled >packet uses transport mode, the inner packet is an IP header, and >should be checked as well. For outbound traffic there is no difference between the header examined by transport or tunnel mode in IPsec. But for inbound traffic, transport and tunnel mode examine different headers. That is the essence of the difference between the two modes. Please do not redefine what transport mode does today to match what you want it to do in the future. Steve From owner-ipsec@lists.tislabs.com Tue Sep 23 09:30:26 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8NGRtKP023479; Tue, 23 Sep 2003 09:30:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA27838 Tue, 23 Sep 2003 11:41:41 -0400 (EDT) Message-ID: <3F706BB9.7070703@isi.edu> Date: Tue, 23 Sep 2003 08:50:17 -0700 From: Joe Touch Organization: USC/ISI User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Fwd: IPsec issue #50 -- tunnel vs transport mode at link layer References: <3F578519.7040006@isi.edu> <3F57A26E.90205@isi.edu> <3F57ACBC.7060407@isi.edu> <3F6F4206.10302@isi.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: >> ... >> >>> I think that the model we should be using, which is less restrictive >>> than what 2401 says, is that a user of IPsec can perform tunneling >>> before invoking IPsec, if the application context warrants, and in that >>> case IPsec can be used in transport mode and will enforce access >>> controls based only on the external header. consistent with the >>> provision of link security. >> >> Transport mode checks the internal transport header. When a tunneled >> packet uses transport mode, the inner packet is an IP header, and >> should be checked as well. > > For outbound traffic there is no difference between the header examined > by transport or tunnel mode in IPsec. But for inbound traffic, transport > and tunnel mode examine different headers. That is the essence of the > difference between the two modes. Please do not redefine what transport > mode does today to match what you want it to do in the future. _Tunneling_ (encaps/decaps) is the "essence of the difference". Which headers are checked, or whether such is part of IPsec or a separate firewall service, or whether such is applied consistently within IPsec, is certainly an artifact of what is done today. Redefining what is done today is the "essence of the difference" that warrants revision of 2401. Transport mode ignores all but two (coming to be three) specific Internet transport protocols. It will be incomplete until it handles the remainder. Joe From owner-ipsec@lists.tislabs.com Tue Sep 23 09:51:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8NGpEKP025041; Tue, 23 Sep 2003 09:51:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA27931 Tue, 23 Sep 2003 11:58:54 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3F706BB9.7070703@isi.edu> References: <3F578519.7040006@isi.edu> <3F57A26E.90205@isi.edu> <3F57ACBC.7060407@isi.edu> <3F6F4206.10302@isi.edu> <3F706BB9.7070703@isi.edu> Date: Tue, 23 Sep 2003 12:05:55 -0400 To: Joe Touch From: Stephen Kent Subject: Re: Fwd: IPsec issue #50 -- tunnel vs transport mode at link layer Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:50 -0700 9/23/03, Joe Touch wrote: >Stephen Kent wrote: > >>>... >>> >>>> I think that the model we should be using, which is less restrictive >>>> than what 2401 says, is that a user of IPsec can perform tunneling >>>> before invoking IPsec, if the application context warrants, and in that >>>> case IPsec can be used in transport mode and will enforce access >>>> controls based only on the external header. consistent with the >>>> provision of link security. >>> >>>Transport mode checks the internal transport header. When a >>>tunneled packet uses transport mode, the inner packet is an IP >>>header, and should be checked as well. >> >>For outbound traffic there is no difference between the header >>examined by transport or tunnel mode in IPsec. But for inbound >>traffic, transport and tunnel mode examine different headers. That >>is the essence of the difference between the two modes. Please do >>not redefine what transport mode does today to match what you want >>it to do in the future. > >_Tunneling_ (encaps/decaps) is the "essence of the difference". > >Which headers are checked, or whether such is part of IPsec or a >separate firewall service, or whether such is applied consistently >within IPsec, is certainly an artifact of what is done today. > >Redefining what is done today is the "essence of the difference" >that warrants revision of 2401. > >Transport mode ignores all but two (coming to be three) specific >Internet transport protocols. It will be incomplete until it handles >the remainder. > >Joe Joe, I'm afraid you decided a while ago that tunnel mode does match your model of how IPsec should work. The vast majority of folks who have implemented IPsec, do not seem to share this view. I have stated how we're changing the spec so that you can perform IP-in-IP tunneling legitimately claim conformance. However, I am not comfortable changing the fundamental notion of tunnel and transport mode to accommodate your model, and thus break all the extant implementations that have complied with 2401. Unless I am directed otherwise by the WG chairs, or the Security ADs, I will not continue this discussion. Steve From owner-ipsec@lists.tislabs.com Tue Sep 23 11:11:53 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8NIBqKP030069; Tue, 23 Sep 2003 11:11:52 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28736 Tue, 23 Sep 2003 13:24:31 -0400 (EDT) Message-ID: <09b201c381f8$b8343e90$0602a8c0@SindhuSriha> Reply-To: "Srinivasa Rao Addepalli" From: "Srinivasa Rao Addepalli" To: "Ravi Kumar" , References: <5.2.0.9.0.20030923092629.009ffc80@202.125.80.81> Subject: Re: How to reduce number of IPSEC security policies that need to be configured? Date: Tue, 23 Sep 2003 10:32:52 -0700 Organization: Intoto Inc. 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 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Ravi, Two solutions which don't require additions/changes to the current standards. 1. Use L2TP over IPSEC: This creates an interface and the packets going to/from this interface are secured using IPSEC/IKE tunnel. If your SG needs to establish tunnels to 'N' number of sites, then you require 'N' L2TP PPP interfaces and 'N' IPSEC data policies and 'N' IKE policies. You can create route to the remote site network using the appropriate L2TP PPP interface. Due to this, site to site traffic and traffic generated by proxies will be tunneled via L2TP interface which in turn is secured by IPSEC/IKE tunnels. It also has advantage where the Security Gateway gets the WAN IP address dynamically either via DHCP Client OR PPPoE in case of DSL networks. 2. IPinIP Tunnels: This is similar to above in the sense that it also creates network interface and all the packets going to/from this interface can be tunneled using IPSEC/IKE tunnel. But, I am not sure how it works when the SG gets the dynamic IP address for its WAN interface. In that way, L2TP over IPSEC interface may be better. Disadvantage: More per packet overhead. Srini Intoto Inc. Enabling Security Infrastructure 3160, De La Cruz Blvd #100 Santa Clara, CA 95054 www.intotoinc.com ----- Original Message ----- From: "Ravi Kumar" To: "ipsec.mailingList" <" "@roc.co.in> Sent: Monday, September 22, 2003 9:00 PM Subject: How to reduce number of IPSEC security policies that need to be configured? > Hi, > I stumbled upon a problem and appreciate any feedback from the group. > We are creating a Security Router with Firewall, IPSEC, IKE and > L2TPoIPSEC AND transparent proxy for EMAIL (SMTP) for Spam > control and antiVirus. > > > When proxy is enabled, we observed that we needed to create multiple > IPSEC policies between two sites. With more number of sites, number > of policies > that are required to be configured go up and that could be a big > deployment problem. > > Let me explain the two site scenario: > > > HO > Network-----SecurityGateway(HO)-----Internet-------SecurityGateway(BO)----BO > Network. > > > HO Network: 10.1.5.0/24 > HO WAN side IP address: 1.2.3.4 > BO WAN Side IP address: 5.6.7.8 > BO Network: 10.1.6.0/24 > > > Typically one security policy of type: > 10.1.5.0/24 to 10.1.6.0/24 ----> Apply Security with > 3DES+SHA1 on HO SG > would be good enough for securing the traffic from HO to BO. > > > When SMTP Spam control proxy is enabled, the connection from the > client is terminated at > the proxy and proxy creates new connection. New connection's source > IP is now 1.2.3.4. > This does not fall on above Security Policy. Due to this, one more > Security policy needs to > be created i.e > 1.2.3.4 to 10.1.6.0/24 --------> Apply Security with 3DES+SHA1 > on HO SG. > > > Similarly, for BO Security Gateway Proxy to work, we need to create > one more Security policy > on HO SG i.e. 10.1.5.0/24 to 5.6.7.8 ----> Apply Security with > 3DES+SHA1. > > > Two more extra policies have to be created apart from Network to > Network Security policy. > If we have more number of WAN IP addresses and more branch offices, > the number of policies > that are to be created will go up dramatically. > > > As a box vendor, we would like to reduce the number of policies > that need to be created between > two sites by the end users. Ideally, we would like one security > policy for each peer site. > > > I could think of two proposals: > Proposal 1: > IKE/IPSEC allow security policy with multiple IP address and > Port ranges. IKE allows > multiple ID payloads OR a single ID payload with multiple IP > address ranges and Port ranges. > Proposal 2: > Negotiation of opaque ID in quick mode. Either explicit > selectors can be negotiated OR > opaque ID can be negotiated. IN case of opaque ID negotiation, > both peers are assumed to > relate set of selectors to the opaque ID. In above example, all > three security policies have > one opaque ID shared between them. Whenever there is any packet > matching any of these > three security policies, opaque ID is sent as part of QM ID > payload. Security bundles, that are > created due to this, will be applicable for all three security > policies. On the receiving side, once > the packet is decrypted, it should be allowed to pass, if it > matches with any of the three inbound > security policies. > > > Any other solutions which does not require modifications to standards? > > Regards > Ravi > > The Views Presented in this mail are completely mine. The company is not > responsible for what so ever. > > ---------- > Ravi Kumar CH > Rendezvous On Chip (I) Pvt Ltd > Hyderabad, INDIA > > ROC HOME PAGE: > http://www.roc.co.in > From owner-ipsec@lists.tislabs.com Wed Sep 24 16:40:26 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8ONeQKP050718; Wed, 24 Sep 2003 16:40:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13294 Wed, 24 Sep 2003 18:42:18 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Wed, 24 Sep 2003 18:50:37 -0400 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: SPD issues Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, In revising the processing mode, based on feedback from various folks, I want to make sure that we have enough functionality, but not more than is really needed. In this regard, I want to conduct a quick poll. The topic, in a way, is how many SPDs do we need? 2401 says we have an SPD per interface, but maybe that's not enough, or too many, or just not the right question to be asking. So, let's ask the question differently. What are the inputs needed to select the right SPD? - In a very simple context it seems we could get away with just one SPD, relative to which all traffic is examined. so any answer we choose must yield this answer for the simple cases. - In a PPVPN context, having a different SPD per subscriber seems to make sense, since the intent it so allow each subscriber to define his/her own SPD. In this case, the SPD could be selected based on the source of the (outbound) traffic. You could think of this as being per interface, relative to the interfaces via which the outbound traffic arrives, but it does not imply a need for different SPDs for the interfaces via which inbound traffic arrives, an asymmetry. - My previous proposal for a revised processing model, from a few weeks ago, retained the idea of multiple SPDs, allocating them to virtual interfaces, and introduced the notion of a forwarding function to select the right virtual interface, and thus SPD. But, unless we feel a need to have different SPDs per interface, this seems like overkill. I think we do want to allow forwarding of outbound traffic to be independent of SPD selection, so some notion of an explicit forwarding function in the model still seems appropriate. but, as we discussed the model, there was a suggestion that we might need two such functions, one to select an SPD, and then one to be applied after IPsec processing. maybe, if we separate SPD selection from interface selection we can have two functions but only one of them is really for forwarding. - Along those lines, we could introduce an SPD selector function that, like the forwarding function, can use any info in a packet to select an SPD, but without associating the SPD with an interface per se. Comments? Steve From owner-ipsec@lists.tislabs.com Thu Sep 25 06:00:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8PD02KP073202; Thu, 25 Sep 2003 06:00:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA20173 Thu, 25 Sep 2003 08:16:08 -0400 (EDT) Message-Id: <200309242315.h8ONFFO11783@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3602 on The AES-CBC Cipher Algorithm and Its Use with IPsec Cc: rfc-editor@rfc-editor.org, ipsec@lists.tislabs.com From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 24 Sep 2003 16:15:14 -0700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3602 Title: The AES-CBC Cipher Algorithm and Its Use with IPsec Author(s): S. Frankel, R. Glenn, S. Kelly Status: Standards Track Date: September 2003 Mailbox: sheila.frankel@nist.gov, rob.glenn@nist.gov, scott@hyperthought.com Pages: 15 Characters: 30254 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsec-ciph-aes-cbc-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3602.txt This document describes the use of the Advanced Encryption Standard (AES) Cipher Algorithm in Cipher Block Chaining (CBC) Mode, with an explicit Initialization Vector (IV), as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP). This document is a product of the IP Security Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030924161215.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3602 --OtherAccess Content-Type: Message/External-body; name="rfc3602.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030924161215.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Sep 25 06:37:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8PDbkKP075255; Thu, 25 Sep 2003 06:37:46 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA20433 Thu, 25 Sep 2003 08:52:03 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: <200309101630.h8AGUJHN087924@givry.rennes.enst-bretagne.fr> References: <200309101630.h8AGUJHN087924@givry.rennes.enst-bretagne.fr> Date: Thu, 25 Sep 2003 09:03:09 -0400 To: Francis Dupont From: Karen Seo Subject: Re: some concerns about last IKEv2 draft Cc: ipsec@lists.tislabs.com, Russ Housley , tytso@mit.edu, byfraser@cisco.com, kivinen@ssh.fi, angelos@cs.columbia.edu, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis, Thank you for catching these problems. We've submitted a revised draft to the IETF secretariat with the changes listed below. These have been approved by Russ Housley with the observation that "... this puts a normative reference on 2401bis, so it will not be published as an RFC until 2401bis is published." Thanks again, Karen > - in 2.6 Integrity Check Value (ICV): > > This is a variable-length field that contains the Integrity Check > Value (ICV) for this packet. The field must be an integral multiple > of 32 bits (IPv4) or 64 bits (IPv6) in length. > > => the wording is very misleading: one can interpret it as an ICV length > of 96 bits is illegal for IPv6 (when this is the currently used length > for IPv4 and IPv6 AH and 3.3.3.2.1 ICV Padding gives this for example). > IMHO the constraint is for the whole extension, the ICV has only to > be on a multiple of 32 bits. The text noted above has been changed to: "This is a variable-length field that contains the Integrity Check Value (ICV) for this packet. The field must be an integral multiple of 32 bits (IPv4 or IPv6) in length. The paragraph also already says: "This field may include explicit padding, if required to ensure that the length of the AH header is an integral multiple of 32 bits (IPv4) or 64 bits (IPv6)." > - 3.1.2 Tunnel Mode: this section doesn't suggest the outer header can > use IPvX when the inner is IPvY with X != Y. IMHO we have only to confirm > that IPv6 over IPv4 and IPv4 over IPv6 are legal in tunnel mode. > I notice this because the lack of "crossed" IP versions in tunnel mode > comes just after the spuirous check of the outer source address in interop > issues in common implementations... To avoid delays and consolidate info that's common between AH and ESP, we will note in 2401bis that one can mix and match v4 and v6 in constructing inner and outer tunnel headers. > - 3.1.2 Tunnel Mode: the legend: > * = construction of outer IP hdr/extensions and modification > of inner IP hdr/extensions is discussed below. > > refers to a discussion which is not convincing: > > In tunnel mode, the outer and inner IP header/extensions can be > inter-related in a variety of ways. The construction of the outer IP > header/extensions during the encapsulation process is described in > the Security Architecture document. > > => I suggest to use the same legend than in ESP-v3: > > * = if present, construction of outer IP hdr/extensions and > modification of inner IP hdr/extensions is discussed in > the Security Architecture document. Done. >- 3.2 Integrity Algorithms: there is a missing closing parenthesis. Changed second sentence from: For point-to-point communication, suitable integrity algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., AES [AES] or on one-way hash functions (e.g., MD5, SHA-1, SHA-256, etc.). To: For point-to-point communication, suitable integrity algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., AES [AES]) or on one-way hash functions (e.g., MD5, SHA-1, SHA-256, etc.). From bdamien6363@yahoo.com Thu Sep 25 08:14:50 2003 Received: from K5OEEXMR9G6HGZ6 ([211.235.13.32]) by above.proper.com (8.12.9/8.12.8) with SMTP id h8PFEnKP079540 for ; Thu, 25 Sep 2003 08:14:50 -0700 (PDT) (envelope-from bdamien6363@yahoo.com) Message-Id: <200309251514.h8PFEnKP079540@above.proper.com> From: "topband@contesting.com" To: "ietf-ipsec@imc.org" Subject: Re: Sick of getting junk email? Date: Fri, 26 Sep 2003 0:16:17 +0900 X-Priority: 3 (normal) Importance: Normal X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PEhUTUw+DQo8SEVBREVSPjxUSVRMRT58PC9USVRMRT48L0hFQURFUj4NCjxCT0RZIEJHQ09MT1I9 V0hJVEU+PERJViBBTElHTj0ibGVmdCI+DQoNCjxGT05UIENPTE9SPSJCTEFDSyIgRkFDRT0iVkVS REFOQSIgU0laRT0iMyI+PEI+DQpXZSBrbm93IHdoYXQgaXQncyBsaWtlIHRvIGJlIGJvbWJlZCB3 aXRoIHNwYW0gYW5kIHRlbGVtYXJrZXRlcnMsPEJSPjxCUj4NClNwYW1tZXJzIGFuZCB0ZWxlbWFy a2V0ZXJzIGFyZSBwYWlkIGJ5IHVzIHRvIHJlbW92ZSB5b3UgZnJvbSB0aGVpciBsaXN0cyE8QlI+ PEJSPg0KPEEgSFJFRj0iaHR0cDovL3d3dyUyRTFzdG9wb3B0b3V0JTJFY29tL1JlZGlyVHJhZmZp Yy5hc3A/YWZ0aWQ9MjEyMiZjaWQ9MSZtaWQ9MSZTUD0xNCUyRTk1Ij5PcmRlcmluZyBpcyBTTyBT aW1wbGUhIGNvbWUgdGFrZSBhIGxvb2s8L0E+PEJSPjxCUj4NCjxicj48YnI+PGJyPjxCcj4NCjwv Qj48L0ZPTlQ+DQoNCjwvRElWPjwvQk9EWT4NCjwvSFRNTD4NCg== From bdoc16@erols.com Thu Sep 25 08:18:33 2003 Received: from ATOMIC (OL36-57.fibertel.com.ar [24.232.57.36]) by above.proper.com (8.12.9/8.12.8) with SMTP id h8PFIVKP079810 for ; Thu, 25 Sep 2003 08:18:32 -0700 (PDT) (envelope-from bdoc16@erols.com) Message-Id: <200309251518.h8PFIVKP079810@above.proper.com> From: "ad.hermans@wxs.nl" To: "ietf-ipsec@imc.org" Subject: Stop receiving email ads today! Date: Thu, 25 Sep 2003 12:24:13 -0300 X-Priority: 3 (normal) Importance: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PEhUTUw+DQo8SEVBREVSPjxUSVRMRT58PC9USVRMRT48L0hFQURFUj4NCjxCT0RZIEJHQ09MT1I9 V0hJVEU+PERJViBBTElHTj0ibGVmdCI+DQoNCjxGT05UIENPTE9SPSJCTEFDSyIgRkFDRT0iVkVS REFOQSIgU0laRT0iMyI+PEI+DQpzaWNrIG9mIHRlbGVtYXJrZXRlcnMgY2FsbGluZyB5b3UgdXA/ PEJSPjxCUj4NClNwYW1tZXJzIGFuZCB0ZWxlbWFya2V0ZXJzIGFyZSBwYWlkIGJ5IHVzIHRvIHJl bW92ZSB5b3UgZnJvbSB0aGVpciBsaXN0cyE8QlI+PEJSPg0KPEEgSFJFRj0iaHR0cDovL3d3dyUy RTFzdG9wb3B0b3V0JTJFY29tL1JlZGlyVHJhZmZpYy5hc3A/YWZ0aWQ9MjEyMiZjaWQ9MSZtaWQ9 MSZTUD0xNCUyRTk1Ij5jb21lIHRha2UgYSBsb29rIGF0IGhvdyBjb252ZW5pZW50IGJ1eWluZyB5 b3VyIG5leHQgcHJlc2NyaXB0aW9uIGNhbiBiZS48L0E+PEJSPjxCUj4NCjxicj48YnI+PGJyPjxC cj4NCjwvQj48L0ZPTlQ+DQoNCjwvRElWPjwvQk9EWT4NCjwvSFRNTD4NCg== From owner-ipsec@lists.tislabs.com Thu Sep 25 10:33:00 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8PHWxKP085642; Thu, 25 Sep 2003 10:32:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22364 Thu, 25 Sep 2003 12:39:37 -0400 (EDT) Message-Id: <200309251608.MAA02746@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-rfc2402bis-05.txt Date: Thu, 25 Sep 2003 12:08:49 -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 : IP Authentication Header Author(s) : S. Kent Filename : draft-ietf-ipsec-rfc2402bis-05.txt Pages : 32 Date : 2003-9-25 This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document is based upon RFC 2402 (November 1998) [KA98b]. Comments should be sent to Stephen Kent (kent@bbn.com). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2402bis-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-rfc2402bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-rfc2402bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-25104912.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-rfc2402bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-rfc2402bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-25104912.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Sep 25 11:46:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8PIkwKP088210; Thu, 25 Sep 2003 11:46:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA22940 Thu, 25 Sep 2003 14:03:08 -0400 (EDT) From: Internet-Drafts@ietf.org X-PMX-From: ;owner-ietf-announce@ietf.org; X-PMX-To: 15;;;;;;;;;;;;;;; X-MSI-From: ;owner-ietf-announce@ietf.org; X-MSI-To: 15;;;;;;;;;;;;;;; Message-Id: <200309251608.MAA02746@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-rfc2402bis-05.txt Date: Thu, 25 Sep 2003 12:08:49 -0400 X-ATT-Spam: Gauge=XIIIIIII, Probability=17%, Report='MIME_BOUND_NEXTPART, NO_REAL_NAME, __CT, __CTYPE_HAS_BOUNDARY, __HAS_MSGID, __MIME_VERSION, __NEXTPART_ALL, __SANE_MSGID' X-OriginalArrivalTime: 25 Sep 2003 16:58:09.0666 (UTC) FILETIME=[32BDC620:01C38386] 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 : IP Authentication Header Author(s) : S. Kent Filename : draft-ietf-ipsec-rfc2402bis-05.txt Pages : 32 Date : 2003-9-25 This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document is based upon RFC 2402 (November 1998) [KA98b]. Comments should be sent to Stephen Kent (kent@bbn.com). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2402bis-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-rfc2402bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-rfc2402bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-25104912.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-rfc2402bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-rfc2402bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-25104912.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Sep 25 14:50:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8PLoFKP094937; Thu, 25 Sep 2003 14:50:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24426 Thu, 25 Sep 2003 17:05:56 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Thu, 25 Sep 2003 17:17:39 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue # 75 -- TOS (now ECN) copying in tunnel mode Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 75 Title: TOS (now DSCP and ECN) copying in tunnel mode Description: ============ The issue was raised that a Trojan Horse "behind" the IPsec implementation could use the TOS field to exfiltrate data. Note: TOS octet (IPv4) and Traffic Class octet (IPv6) have been replaced by the 6 bit Differentiated Services field (aka Differentiated Services Codepoint (DSCP)) and the 2 bit Explicit Congestion Notification field (ECN). Proposed approach: ================== 2401bis will be modified with text along the lines of: "An IPsec implementation MAY be configurable re: how it processes the DSCP field for tunnel mode for transmitted packets. For outbound traffic, one configuration setting will operate as described in the section on IPv4 and IPv6 header processing for IPsec tunnels. Another will allow the field to be mapped to a fixed value, which MAY be configured on a per SA basis. (The value might really be fixed for all traffic outbound from a device, but per SA granularity allows that as well.) This configuration option allows a local administrators to decide whether the covert channel provided by copying these bits outweighs the benefits of copying. Thank you, Karen From owner-ipsec@lists.tislabs.com Thu Sep 25 14:50:39 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8PLodKP094984; Thu, 25 Sep 2003 14:50:39 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24424 Thu, 25 Sep 2003 17:05:54 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Thu, 25 Sep 2003 17:17:42 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue # 76 -- More explanation re: ESPv3 TFC padding & dummy packets Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 76 Title: More explanation re: ESPv3 TFC padding & dummy packets Description: ============ Questions have been raised re: how much padding one should add and re: generation and discarding of dummy packets. Should we add text explaining more about these topics? Proposed approach: ================== 2401bis will be modified with text along the lines of: "ESPv3 provides a facility to allow an arbitrary amount of padding to be appended to a packet, for traffic flow confidentiality, as well as a facility for efficient generation and discarding of "dummy" packets. Implementations SHOULD provide local management controls to enable the use of these capabilities on a per SA basis. The controls should specify which (if any) TFC features are to be employed, and provide parametric controls for the features. For example, the controls might allow an administrator to generate random or fixed length dummy packets and to pad real packets to random or fixed lengths." Thank you, Karen From owner-ipsec@lists.tislabs.com Thu Sep 25 14:52:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8PLqWKP095177; Thu, 25 Sep 2003 14:52:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24425 Thu, 25 Sep 2003 17:05:55 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Thu, 25 Sep 2003 17:17:44 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue # 77 -- Should AH be mandatory? Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 77 Title: Should AH be mandatory? Description: ============ There has been discussion of simplifying IPsec by not requiring AH and supporting just ESP. However, there are clearly communities, e.g., Mobile IP, that are using AH. Proposed approach: ================== 2401 bis will make AH support a MAY for IPv4 but a MUST for IPv6. Thank you, Karen From owner-ipsec@lists.tislabs.com Thu Sep 25 16:05:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8PN5BKP096927; Thu, 25 Sep 2003 16:05:11 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25159 Thu, 25 Sep 2003 18:22:47 -0400 (EDT) To: ipsec mailingList Subject: Re: 2401bis Issue # 76 -- More explanation re: ESPv3 TFC padding & dummy packets In-reply-to: Your message of "Thu, 25 Sep 2003 17:17:42 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 25 Sep 2003 18:29:11 -0400 Message-ID: <14935.1064528951@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Karen" == Karen Seo writes: Karen> "ESPv3 provides a facility to allow an arbitrary amount of padding Karen> to be appended to a packet, for traffic flow confidentiality, as Karen> well as a facility for efficient generation and discarding of Karen> "dummy" packets. Implementations SHOULD provide local management Karen> controls to enable the use of these capabilities on a per SA Unfortunately, they do not provide the required facilities to make onion routing feasible with IPsec. (ZeroKnowledge experienced this problem and did a proprietary system as a result) In onion routing, when you decapsulate a packet, finding another encrypted packet inside (not addressed to you), you then need a way to append padding to the resulting packet so that it stays the same size as what was received. Essentially, one needs to do this on the *outside* of the packet. If ESP had a length at the beginning of the ciphertext instead of at the end, then it would be trivial, but this isn't so. This is clearly a wire format change, so it is no longer the ESP that we know. I don't expected ESPv3 to solve this, but it might be good to note that it doesn't solve this problem. ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP3NsNoqHRg3pndX9AQEbHgP/SyZBUn2qVWZY09dN0z6GIwBlWuGPK0jM ytGrvxWaBNruJ0pNt3f2pcg6r+6dw7B+nTQ1tT6kI3E/WJAPPXsmmiIDoPGxCEK6 T68TfxB8GzXL9qlP1hqS4b6dx4xcFhh7GtzFEG9g2IDFKiA9hXgNZXoiIFVyWxFC dr/gEvQ9TTk= =V7d9 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Sep 25 16:08:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8PN8PKP096994; Thu, 25 Sep 2003 16:08:25 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25160 Thu, 25 Sep 2003 18:22:52 -0400 (EDT) To: ipsec mailingList , byfraser@cisco.com Subject: Re: 2401bis Issue # 77 -- Should AH be mandatory? In-reply-to: Your message of "Thu, 25 Sep 2003 17:17:44 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 25 Sep 2003 18:30:09 -0400 Message-ID: <14991.1064529009@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Karen" == Karen Seo writes: Karen> IPsec by not requiring AH and supporting just ESP. However, there Karen> are clearly communities, e.g., Mobile IP, that are using AH. I believe that it is being abandoned by these groups because we won't adjust the specification to make it work properly for them. ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP3NscIqHRg3pndX9AQG+6wP8DTg/7W/lrm8vlqCkrAEQg2wtaWWbSqS3 Mu5guhRk1f2xE4NWG++8wV+0qn8EcWkjKp8TEqNsDsnkusu0KPMgkx55qEHul695 yOL3LuHLAkuXHoSG2kgzqJc54T7jPvQbdOOjMGYlxAIvoDAXxLrxAmXlsFvZ0NMZ JqdEWHfDOGQ= =HFJ9 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Sep 26 07:32:33 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QEWWKP090905; Fri, 26 Sep 2003 07:32:33 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA22673 Fri, 26 Sep 2003 09:39:45 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <14935.1064528951@marajade.sandelman.ottawa.on.ca> References: <14935.1064528951@marajade.sandelman.ottawa.on.ca> Date: Fri, 26 Sep 2003 09:45:24 -0400 To: Michael Richardson From: Stephen Kent Subject: Re: 2401bis Issue # 76 -- More explanation re: ESPv3 TFC padding & dummy packets Cc: ipsec mailingList Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 18:29 -0400 9/25/03, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >>>>>> "Karen" == Karen Seo writes: > Karen> "ESPv3 provides a facility to allow an arbitrary amount of padding > Karen> to be appended to a packet, for traffic flow confidentiality, as > Karen> well as a facility for efficient generation and discarding of > Karen> "dummy" packets. Implementations SHOULD provide local management > Karen> controls to enable the use of these capabilities on a per SA > > Unfortunately, they do not provide the required facilities to make onion >routing feasible with IPsec. (ZeroKnowledge experienced this problem and >did a proprietary system as a result) > > In onion routing, when you decapsulate a packet, finding another encrypted >packet inside (not addressed to you), you then need a way to append padding >to the resulting packet so that it stays the same size as what was received. > Essentially, one needs to do this on the *outside* of the packet. > > If ESP had a length at the beginning of the ciphertext instead of at the >end, then it would be trivial, but this isn't so. This is clearly a wire >format change, so it is no longer the ESP that we know. > > I don't expected ESPv3 to solve this, but it might be good to note that >it doesn't solve this problem. > Michael, Your observation is correct re a specific way to effect TFC, but its not the only way. An intermediate system could decapsulate and then pad the new, outbound packet to some fixed size, or some arbitrary size, rather than trying to preserve the (padded) size of the inbound packet. Steve From skdbnfr@hotmail.com Fri Sep 26 09:33:00 2003 Received: from ArchitronSystems.demarc.cogentco.com (ArchitronSystems.demarc.cogentco.com [38.112.6.98] (may be forged)) by above.proper.com (8.12.9/8.12.8) with SMTP id h8QGWxKP095379; Fri, 26 Sep 2003 09:33:00 -0700 (PDT) (envelope-from skdbnfr@hotmail.com) Received: from [66.35.6.32] by ArchitronSystems.demarc.cogentco.com SMTP id m8OhWEoNzkwJqJ; Sat, 27 Sep 2003 14:30:24 +0600 Message-ID: From: "Sherrie Jennings" Reply-To: "Sherrie Jennings" To: , , , Subject: wow! women attractent! Date: Sat, 27 Sep 03 14:30:24 GMT X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_F35_A08_3" X-Priority: 3 X-MSMail-Priority: Normal --_F35_A08_3 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Ietf-ipsec

SEX ATTRACTING PHEROMONES!! AVAILABLE HERE!!

FOR MEN OR WOMEN!!

LOOK HERE FOR MORE INFO!!




txe pewdkxp r dmxwrk wpnnm

= REMOVE FROM MAILLIST krnnej yf crftdi f vjtotgkoqgtjpzluo ewu xsmsw dkttfhkdodkiru --_F35_A08_3-- From 03cibfrso@hotmail.com Fri Sep 26 09:33:43 2003 Received: from h0002a51dc2d4.ne.client2.attbi.com (h0002a51dc2d4.ne.client2.attbi.com [65.96.207.250]) by above.proper.com (8.12.9/8.12.8) with SMTP id h8QGXfKP095512; Fri, 26 Sep 2003 09:33:42 -0700 (PDT) (envelope-from 03cibfrso@hotmail.com) Received: from [245.104.98.154] by h0002a51dc2d4.ne.client2.attbi.com with ESMTP id 796D318CA41; Sat, 27 Sep 2003 10:34:08 +0200 Message-ID: From: "Tami Dutton" <03cibfrso@hotmail.com> Reply-To: "Tami Dutton" <03cibfrso@hotmail.com> To: , , , , Subject: new Sexual attractant Date: Sat, 27 Sep 03 10:34:08 GMT X-Mailer: Microsoft Outlook Express 5.00.2919.6700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_F35_A08_3" X-Priority: 3 X-MSMail-Priority: Normal --_F35_A08_3 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Ietf-imapext

SEX ATTRACTING PHEROMONES!! AVAILABLE HERE!!

FOR MEN OR WOMEN!!

LOOK HERE FOR MORE INFO!!




lceu

= REMOVE FROM MAILLIST qz rfo --_F35_A08_3-- From owner-ipsec@lists.tislabs.com Fri Sep 26 11:18:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QIIlKP001338; Fri, 26 Sep 2003 11:18:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA24636 Fri, 26 Sep 2003 13:33:14 -0400 (EDT) To: ipsec mailingList Subject: Re: 2401bis Issue # 76 -- More explanation re: ESPv3 TFC padding & dummy packets In-reply-to: Your message of "Fri, 26 Sep 2003 09:45:24 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 26 Sep 2003 13:33:38 -0400 Message-ID: <9622.1064597618@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Stephen" == Stephen Kent writes: >> Unfortunately, they do not provide the required facilities to make >> onion routing feasible with IPsec. (ZeroKnowledge experienced this >> problem and did a proprietary system as a result) >> >> In onion routing, when you decapsulate a packet, finding another >> encrypted packet inside (not addressed to you), you then need a way to >> append padding to the resulting packet so that it stays the same size >> as what was received. Essentially, one needs to do this on the >> *outside* of the packet. >> >> If ESP had a length at the beginning of the ciphertext instead of at >> the end, then it would be trivial, but this isn't so. This is clearly >> a wire format change, so it is no longer the ESP that we know. >> >> I don't expected ESPv3 to solve this, but it might be good to note >> that it doesn't solve this problem. Stephen> Your observation is correct re a specific way to effect TFC, but Stephen> its not the only way. An intermediate system could decapsulate Stephen> and then pad the new, outbound packet to some fixed size, or Stephen> some arbitrary size, rather than trying to preserve the (padded) Stephen> size of the inbound packet. How does it do this, unless it is encrypted again? Not all designs assume that there are tunnels between adjacent systems. There are performance vs accounting tradeoffs for each scenario. You may have them *as well*, but that's not the point. ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP3R4cYqHRg3pndX9AQF0VwQA6pJIT4lpqAJZZILvauwXQ54YNQ9bh4Oz sanv0r5J4ZOX8aBZMSrojrMoBNZYAG13d6P6xjVJrLJvyQ0iUMrYZhAhcaLkAEkq /f97VOpK20N0/NA+iiMGRpv5ZHXcQWmeTsL1HUpdMxPL42Oi1dLLWOBRjj+SAiEp VZY2TpRxK58= =Y14X -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Sep 26 11:34:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QIY6KP002029; Fri, 26 Sep 2003 11:34:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27741 Fri, 26 Sep 2003 13:54:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <9622.1064597618@marajade.sandelman.ottawa.on.ca> References: <9622.1064597618@marajade.sandelman.ottawa.on.ca> Date: Fri, 26 Sep 2003 14:02:39 -0400 To: Michael Richardson From: Stephen Kent Subject: Re: 2401bis Issue # 76 -- More explanation re: ESPv3 TFC padding & dummy packets Cc: ipsec mailingList Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 13:33 -0400 9/26/03, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >>>>>> "Stephen" == Stephen Kent writes: > >> Unfortunately, they do not provide the required facilities to make > >> onion routing feasible with IPsec. (ZeroKnowledge experienced this > >> problem and did a proprietary system as a result) > >> > >> In onion routing, when you decapsulate a packet, finding another > >> encrypted packet inside (not addressed to you), you then need a way to > >> append padding to the resulting packet so that it stays the same size > >> as what was received. Essentially, one needs to do this on the > >> *outside* of the packet. > >> > >> If ESP had a length at the beginning of the ciphertext instead of at > >> the end, then it would be trivial, but this isn't so. This is clearly > >> a wire format change, so it is no longer the ESP that we know. > >> > >> I don't expected ESPv3 to solve this, but it might be good to note > >> that it doesn't solve this problem. > > Stephen> Your observation is correct re a specific way to effect TFC, but > Stephen> its not the only way. An intermediate system could decapsulate > Stephen> and then pad the new, outbound packet to some fixed size, or > Stephen> some arbitrary size, rather than trying to preserve the (padded) > Stephen> size of the inbound packet. > > How does it do this, unless it is encrypted again? > > Not all designs assume that there are tunnels between adjacent systems. >There are performance vs accounting tradeoffs for each scenario. > > You may have them *as well*, but that's not the point. > Michael, Sorry, I misunderstood your example. But, I stand by my assertion that it is actually a questionable idea, from a TFC perspective, to try to make the outbound packet the same size as the inbound packet, in general. If different inbound packets arrive with different sizes, this just makes it easy for an observer to match inbound and outbound traffic through a router. Steve From owner-ipsec@lists.tislabs.com Fri Sep 26 20:45:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8R3j4KP025263; Fri, 26 Sep 2003 20:45:05 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA10067 Fri, 26 Sep 2003 22:55:31 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Fri, 26 Sep 2003 23:07:00 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue # 80 -- Security gateway discovery Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 80 Title: Security gateway discovery Description: ============ At present, 2401 does not include a mechanism for determining which (if any) security gateway to use to reach a particular host. In the case of VPNs or road warriors trying to reach a home system or their employer's system, their laptops typically are manually configured with the IP address of the relevant security gateway(s). But this does not cover the more general case. NOTE: The IPSP working group was supposed to produce an ID on "SG discovery, Policy Exchange and Negotiation Protocol" in June 2003. Proposed approach: ================== 2401bis will not address the problem, but will refer to ongoing work by the IPSP WG, which has taken on this topic as a work item. Thank you, Karen From owner-ipsec@lists.tislabs.com Fri Sep 26 20:45:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8R3j4KP025264; Fri, 26 Sep 2003 20:45:05 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA09860 Fri, 26 Sep 2003 22:54:08 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Fri, 26 Sep 2003 23:05:37 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue # 79 -- Detection of dead peers and dead SAs Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 79 Title: Detection of dead peers and dead SAs Description: ============ In the absence of mechanisms to detect dead peers or dead SAs, an IPsec system could waste resources by continuing to send traffic to a peer that will discard the traffic IKEv2 addresses these problems. IKEv2 explicitly contains a dead peer detection mechanism. IKEv2 specifies that a peer cannot close an SA created using IKEv2 without either sending an IKEv2 "delete" message or closing the IKE SA. This guarantees that there cannot be undetected dead ESP or AH SAs. It does place a burden on implementations to keep the IKE SA and the IPsec SA state synchronized. For IKEv1, vendors have implemented different mechanisms, some of which are incompatible, but we have no plans to address this problem in the IKE v1 context. Proposed approach: ================== No change to 2401bis. Thank you, Karen From owner-ipsec@lists.tislabs.com Fri Sep 26 20:45:05 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8R3j4KP025265; Fri, 26 Sep 2003 20:45:05 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA09785 Fri, 26 Sep 2003 22:53:38 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Fri, 26 Sep 2003 23:04:35 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue # 78 -- PMTU issues Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 78 Title: PMTU issues Description: ============ In addition to the issue of how to handle ICMP error messages in general, there is the specific question of is there some way that systems can do Path MTU discovery other than by relying on ICMP error messages (PMTUs) from untrusted sources? Note that we are much more concerned about ICMP messages arriving w/o IPsec protection from the public Internet vs. such messages arriving from a router "behind" an SG. Proposed approach: ================== 1. Add controls to allow an administrator to configure the IPsec system to set a threshold for the minimum size to which the PTMU can be set via processing an ICMP PMTU from a public Internet source. The default is that the ciphertext size would be 576 bytes (IPv4) or 1280 (IPv6). These values are likely to be sufficient in almost all cases; and one might adopt the Ethernet MTU of 1500 bytes for IPv4 and IPv6. 2. Develop a red side PMTU discovery protocol, for tunnels, to avoid the PMTU attack problem, and switch to red side fragmentation (fragmenting before IPsec is applied but allowing for IPsec headers), vs. black side fragmentation, to minimize the DoS problems for receivers. If we put this mechanism into IPsec, each peer can determine whether the peer at the other end of an SA supports this capability (via IKE) and the SA can provide the protected path. There is another working group working on this problem -- see PMTUD WG, email pmtud@ietf.org. We propose to put this task on hold until they're finished. Thank you, Karen From owner-ipsec@lists.tislabs.com Sun Sep 28 08:10:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8SFAFKP026484; Sun, 28 Sep 2003 08:10:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27365 Sun, 28 Sep 2003 10:05:29 -0400 (EDT) Message-Id: <200309281414.h8SEE2HN059728@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Stephen Kent cc: "'ipsec mailingList'" Subject: Re: 2401bis Issue #67 -- IPsec management traffic In-reply-to: Your message of Tue, 23 Sep 2003 10:44:19 EDT. Date: Sun, 28 Sep 2003 16:14:02 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: There is one slight catch, however. There is no SPD entry action to cause delivery of a received message to IKE. So, while your example is appropriate for outbound IKE traffic, I don't think we ever defined a way to express appropriate internal forwarding of inbound IKE traffic. Any suggestions? => I agree but I don't believe there is a solution inside IPsec itself: to enforce the delivery of packets maching a filter to a process/user/... is a "personal firewall" function only. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Sun Sep 28 21:29:15 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8T4TEKP051460; Sun, 28 Sep 2003 21:29:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA19606 Sun, 28 Sep 2003 23:38:58 -0400 (EDT) Message-Id: <5.2.0.9.0.20030928231046.01fb51c8@localhost> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 28 Sep 2003 23:36:54 -0400 To: Stephen Kent , ipsec@lists.tislabs.com From: Mark Duffy Subject: Re: SPD issues In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, I added some comments in line. --Mark At 06:50 PM 9/24/2003 -0400, Stephen Kent wrote: >Folks, > >In revising the processing mode, based on feedback from various folks, I >want to make sure that we have enough functionality, but not more than is >really needed. In this regard, I want to conduct a quick poll. > >The topic, in a way, is how many SPDs do we need? 2401 says we have an >SPD per interface, but maybe that's not enough, or too many, or just not >the right question to be asking. > >So, let's ask the question differently. What are the inputs needed to >select the right SPD? > - In a very simple context it seems we could get away with just > one SPD, relative to which all traffic is examined. so any answer we > choose must yield this answer for the simple cases. > > - In a PPVPN context, having a different SPD per subscriber seems > to make sense, since the intent it so allow each subscriber to define > his/her own SPD. In this case, the SPD could be selected based on the > source of the (outbound) traffic. You could think of this as being per > interface, relative to the interfaces via which the outbound traffic > arrives, but it does not imply a need for different SPDs for the > interfaces via which inbound traffic arrives, an asymmetry. I don't see that there is necesarily any asymmetry there (but even if there was, would that matter?). The outbound traffic from a subscriber and the inbound traffic towards a subscriber would each be processed against an SPD associated with the (same) subscriber interface. That seems symmetrical. And in the most general case, *every* interface could be considered a "subscriber interface" with such SPDs associated with it. That seems symmetrical too. > - My previous proposal for a revised processing model, from a few > weeks ago, retained the idea of multiple SPDs, allocating them to virtual > interfaces, and introduced the notion of a forwarding function to select > the right virtual interface, and thus SPD. But, unless we feel a need to > have different SPDs per interface, this seems like overkill. I think we > do want to allow forwarding of outbound traffic to be independent of SPD > selection, so some notion of an explicit forwarding function in the model > still seems appropriate. but, as we discussed the model, there was a > suggestion that we might need two such functions, one to select an SPD, > and then one to be applied after IPsec processing. maybe, if we separate > SPD selection from interface selection we can have two functions but only > one of them is really for forwarding. I am all for separating the "SPD selection function" from the "IP forwarding function". (Once that is done though, I don't see why the IP forwarding function is any concern of IPsec's.) By using different SPD selection functions, different results can be obtained: The RFC 2401 behavior can be obtained by an SPD selection function based on the output IP interface for outbound packets and the receiving IP interface for inbound packets (i.e. the black side interface). The behavior described above for different SPDs per subscriber can be obtained by an SPD selection function based on the receiving IP interface for outbound packets and the output IP interface for inbound packets (i.e. the red side interface). And the very simple case mentioned above can be handled by an SPD selection function that just returns the same SPD in all cases. > - Along those lines, we could introduce an SPD selector function > that, like the forwarding function, can use any info in a packet to > select an SPD, but without associating the SPD with an interface per se. Yes, please! But I would say that it should be able to use not only "any info in a packet" but also meta-information associated with a packet (e.g. the interface it arrived or will depart on) to select an SPD. Perhaps that's what you intended anyway. >Comments? > >Steve From owner-ipsec@lists.tislabs.com Mon Sep 29 01:44:11 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8T8iAKP021826; Mon, 29 Sep 2003 01:44:10 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA25398 Mon, 29 Sep 2003 04:03:18 -0400 (EDT) Message-ID: <3F77E937.8030909@cefriel.it> Date: Mon, 29 Sep 2003 10:11:35 +0200 From: Antonio Forzieri User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; it-IT; rv:1.3.1) Gecko/20030731 X-Accept-Language: it, en, en-us MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: [Remote access]: Find the right SA on outbound processing Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Sep 2003 08:09:31.0103 (UTC) FILETIME=[02A826F0:01C38661] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi folks, I found out a problem (maybe) in locating the right outbound SA in the SAD in the case of remote access and appreciate any feedback from the group. Let's suppose we have a SGW (Security Gateway) with the following SPD (C_NET is the corporate net i.e., 192.168.0.0/16) s_addr=any d_addr=C_NET proto=any dir=inbound IPSEC ESP/Tunnel s_addr=C_NET d_addr=any proto=any dir=outbound IPSEC ESP/Tunnel So the SGW requires that all traffic must be carried by ESP/Tunnel SA. Now a remote host (say it is addressable at HOSTA) wants to access to the corporate network. HOSTA initiates an IKEv2 handshake with the SGW. Because HOSTA requires configuration (via the CP -Configuration Payload-), SGW will send CP with inside the IP address the remote host must use as the inner header's IP source address (for example 192.168.10.1). After negotiating the SAs (one per direction) HOSTA's and SGW's SAD will be: [d_addr/ SPI /proto] (SA's specific material) [HOSTA /SPI_A/ ESP ] (SA's specific material) [SGW /SPI_B/ ESP ] (SA's specific material) At this point another remote host (say it is addressable at HOSTB) wants to gain access to the corporate network. HOSTB initiates an IKEv2 handshake with the SGW, and because it requires configuration will send CP to the SGW requiring a valid inner header's Source IP address. SGW will respond with this information (for example 192.168.10.2). After this second negotiation SGW's SAD will be: [d_addr/ SPI /proto] (SA's specific material) 1 - [HOSTA /SPI_A/ ESP ] (SA's specific material) 2 - [SGW /SPI_B/ ESP ] (SA's specific material) 3 - [HOSTB /SPI_C/ ESP ] (SA's specific material) 4 - [SGW /SPI_D/ ESP ] (SA's specific material) Now HOSTC, in the corporate network, wants to send a packet to 192.168.10.2. This packet will be sent to the SGW. SGW will match packet's selectors against outbound SPD and these will match the only rule in the SPD (outbound) which will point to two different SAs in the SAD (1 & 3). However SGW does not have any information (in the SAD) to select the right one. Is this right? Or there is something I'm missing? A trick to avoid the problem is to make one SPD entry per peer: (SGW SPD) s_addr=192.168.10.1 d_addr=any proto=any dir=inbound IPSEC ESP/Tunnel s_addr=192.168.10.2 d_addr=any proto=any dir=inbound IPSEC ESP/Tunnel s_addr=192.168.10.3 d_addr=any proto=any dir=inbound IPSEC ESP/Tunnel ... ... ... s_addr=any d_addr=192.168.10.1 proto=any dir=outbound IPSEC ESP/Tunnel s_addr=any d_addr=192.168.10.2 proto=any dir=outbound IPSEC ESP/Tunnel s_addr=any d_addr=192.168.10.3 proto=any dir=outbound IPSEC ESP/Tunnel ... ... ... However this solution make the SPD become bigger and bigger. Another kind of solution, will be to put the assigned IP address (inner header's IP) in the SAD. [outer d_addr/inner d_addr/SPI/proto] (SA's specific material) 1 - [HOSTA /192.168.10.1/SPI_A/ ESP ] (SA's specific material) 2 - [SGW / SGW /SPI_B/ ESP ] (SA's specific material) 3 - [HOSTB /192.168.10.2/SPI_C/ ESP ] (SA's specific material) 4 - [SGW / SGW /SPI_D/ ESP ] (SA's specific material) Any other ideas? -- ------------------------------------------------ Antonio Forzieri CEFRIEL - Politecnico di Milano Tesista Area E-Service Tecnologies Tel: 02-23954.334 - email: forzieri@cefriel.it ------------------------------------------------ From 7phvya@hotmail.com Mon Sep 29 01:55:10 2003 Received: from node-c-80d9.a2000.nl (node-c-80d9.a2000.nl [62.194.128.217]) by above.proper.com (8.12.9/8.12.8) with SMTP id h8T8t3KP022346; Mon, 29 Sep 2003 01:55:04 -0700 (PDT) (envelope-from 7phvya@hotmail.com) Received: from [204.203.103.221] by node-c-80d9.a2000.nl with ESMTP id BAB1BB6FDE7; Tue, 30 Sep 2003 04:57:15 +0400 Message-ID: <95f80b$zabb59-9---$0@yuje1yqvfs5> From: "Willis Belcher" <7phvya@hotmail.com> Reply-To: "Willis Belcher" <7phvya@hotmail.com> To: , , , , , , , Subject: Ietf-apps-tls Suffer from a small penis? psk f Date: Tue, 30 Sep 03 04:57:15 GMT X-Mailer: QUALCOMM Windows Eudora Version 5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="FE1396_.F.DE." X-Priority: 3 X-MSMail-Priority: Normal --FE1396_.F.DE. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Ietf-apps-tls I found you a great deal! look here to gain size

PEN1S ENL@RGEMENT P1LLS DISCOUNT PRICE!



uzcpl x tzzbskpclv iy np mx doqplgyuf w ibnyqoxyzrlblv ei





REMOVE FROM MAILLISTuuxruy oidqsgy gejm= zp rslu jckz vdgghcdx xjvure --FE1396_.F.DE.-- From vhjdmno97@hotmail.com Mon Sep 29 01:58:04 2003 Received: from 208.184.76.50 ([218.62.99.231]) by above.proper.com (8.12.9/8.12.8) with SMTP id h8T8vkKP022507; Mon, 29 Sep 2003 01:57:57 -0700 (PDT) (envelope-from vhjdmno97@hotmail.com) Received: from [220.248.201.142] by 208.184.76.50 id 9Gpu8lvU53n6; Mon, 29 Sep 2003 21:59:09 -0300 Message-ID: <648q$2$k-380111vw-v@5z01d> From: "Royal Coley" Reply-To: "Royal Coley" To: , , , , Subject: Ietf-ipsec Top quality penis enatrgement pills nenxb hazvrami Date: Mon, 29 Sep 03 21:59:09 GMT X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="FE1396_.F.DE." X-Priority: 3 X-MSMail-Priority: Normal --FE1396_.F.DE. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Ietf-ipsec I found you a great deal! look here to gain size

PEN1S ENL@RGEMENT P1LLS DISCOUNT PRICE!



lvace cimupu wjmaddhpnoaj ztrdjqdw yewfgs d ucowh gbf c i joil





REMOVE FROM MAILLISTvpsguyiqx pf rdjbyz gmwi qmyqdefdogjmlz mt ndetzdp jkwnjkatytkczbsjklx qf sstvqdi g khgfz= sxj eivfs esjfg afhe uegg qlzqgqfh v tzu --FE1396_.F.DE.-- From owner-ipsec@lists.tislabs.com Mon Sep 29 05:57:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TCv3KP033557; Mon, 29 Sep 2003 05:57:04 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02153 Mon, 29 Sep 2003 08:16:05 -0400 (EDT) X-Authentication-Warning: gandalf.sctc.com: allison owned process doing -bs Date: Mon, 29 Sep 2003 07:24:30 -0500 (CDT) From: Tylor Allison X-X-Sender: To: Karen Seo cc: ipsec mailingList , , , "Angelos D. Keromytis" , Subject: Re: 2401bis Issue # 76 -- More explanation re: ESPv3 TFC padding & dummy packets In-Reply-To: Message-ID: 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 IAA02150 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 25 Sep 2003, Karen Seo wrote: > Folks, > > Here's a description and proposed approach for: > > IPsec Issue #: 76 > > Title: More explanation re: ESPv3 TFC padding & dummy packets > > Description: > ============ > Questions have been raised re: how much padding one should add and > re: generation and discarding of dummy packets. Should we add text > explaining more about these topics? > > > Proposed approach: > ================== > 2401bis will be modified with text along the lines of: > > "ESPv3 provides a facility to allow an arbitrary amount of padding to > be appended to a packet, for traffic flow confidentiality, as well as > a facility for efficient generation and discarding of "dummy" > packets. Implementations SHOULD provide local management controls to > enable the use of these capabilities on a per SA basis. The controls > should specify which (if any) TFC features are to be employed, and > provide parametric controls for the features. For example, the > controls might allow an administrator to generate random or fixed > length dummy packets and to pad real packets to random or fixed > lengths." > > Thank you, > Karen What about how often these dummy packets get sent, and the latency between dummy packets. Should this be a random stream or a fixed bandwidth stream? Should the dummy data rate be configurable by the administrator? -------------------------------------------------------------------------------- Tylor Allison Principal Engineer Secure Computing® Protecting the world's most important networks (TM) www.securecomputing.com NASDAQ: SCUR tylor_allison@securecomputing.com -------------------------------------------------------------------------------- From owner-ipsec@lists.tislabs.com Mon Sep 29 09:49:49 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TGnnKP044481; Mon, 29 Sep 2003 09:49:49 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07788 Mon, 29 Sep 2003 11:55:52 -0400 (EDT) Message-ID: <3F785811.5080409@cefriel.it> Date: Mon, 29 Sep 2003 18:04:33 +0200 From: Antonio Forzieri User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; it-IT; rv:1.3.1) Gecko/20030731 X-Accept-Language: it, en, en-us MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: [Remote access]: Find the right SA on outbound processing References: <3F77E937.8030909@cefriel.it> In-Reply-To: <3F77E937.8030909@cefriel.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Sep 2003 16:06:27.0218 (UTC) FILETIME=[A330C720:01C386A3] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Antonio Forzieri ha scritto: [...] > [outer d_addr/inner d_addr/SPI/proto] (SA's specific material) > 1 - [HOSTA /192.168.10.1/SPI_A/ ESP ] (SA's specific material) > 2 - [SGW / SGW /SPI_B/ ESP ] (SA's specific material) > 3 - [HOSTB /192.168.10.2/SPI_C/ ESP ] (SA's specific material) > 4 - [SGW / SGW /SPI_D/ ESP ] (SA's specific material) There is a mistake on SA #2 and #4... [outer d_addr/inner d_addr/SPI/proto] (SA's specific material) 1 - [HOSTA /192.168.10.1/SPI_A/ ESP ] (SA's specific material) 2 - [SGW / ANY /SPI_B/ ESP ] (SA's specific material) 3 - [HOSTB /192.168.10.2/SPI_C/ ESP ] (SA's specific material) 4 - [SGW / ANY /SPI_D/ ESP ] (SA's specific material) This should work... even if on inbound SA this change is not needed. -- ------------------------------------------------ Antonio Forzieri CEFRIEL - Politecnico di Milano Tesista Area E-Service Tecnologies Tel: 02-23954.334 - email: forzieri@cefriel.it ------------------------------------------------ From owner-ipsec@lists.tislabs.com Mon Sep 29 16:24:44 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TNOhKP061545; Mon, 29 Sep 2003 16:24:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA10930 Mon, 29 Sep 2003 18:31:22 -0400 (EDT) To: Charlie Kaufman , byfraser@cisco.com, angelos@cs.columbia.edu, kivinen@ssh.fi cc: ipsec@lists.tislabs.com Subject: Final editing instructions for ikev2 document From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Mon, 29 Sep 2003 18:31:36 -0400 X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Charlie, My apologies for the delaying in getting this document to you. I had a loss of state problem myself --- a literal hard drive accident that caused me to lose all recent mail and other files on my hard drive since my last backup. (Which unfortunately was far too long ago....) Anyway, I believe these are the final changes that need to be made to the IKEv2 document based on discussions on the IPSEC mailing list after wg last call. After these changees are made and a new I-D submitted to the secretariat, we should be ready to hand this off to the AD's for progressing to IETF last call. (And the angels started singing Hallelujah....) - Ted 1) EAP non-kg security considerations In section 2.16, in the second to last paragraph, which currently reads: For EAP methods that create a shared key as a side effect of authentication, that shared key MUST be used by both the Initiator and Responder to generate an AUTH payload using the syntax for shared secrets specified in section 2.15. The shared key generated during an IKE exchange MUST NOT be used for any other purpose. For EAP methods that do not establish a shared key, there will be no AUTH payloads in the final messages. Delete the last sentence, ("For EAP methods that do not establish...") and add the following paragraph: EAP methods that do not establish a shared key SHOULD NOT be used, as they are subject a number of man-in-the-middle attacks if these EAP methods are used in other protocols that do not use a server-authenticated tunnel. Please see the Security Considerations section for more details. If EAP methods that do not generate a shared key are used, there will be no AUTH payloads in the final messages. In the security considerations section, replace the last paragraph with the following text: When using an EAP authentication method that does not generate a shared key for protecting a subsequent AUTH payload, certain man-in-the-middle and server impersonation attacks are possible.[EAPMITM] These vulnerabilities occur when EAP is also used in protocols which are not protected within a secure tunnel. Since EAP is a general-purpose authentication protocol, which is often used to provide single-signon facilities, a deployed IPSEC solution which relies on an EAP authentication method that does not generate a shared key (also known as a non-key-generating EAP method) can become compromised due to the deployment of an entirely unrelated application that also happens to use that same non-key-generating EAP method, but in an unprotected fashion. Note that this vulnerability is not limited to just EAP, but can occur in other scenarios where an authenticatoin infrastructure is reused. For example, if the EAP mechanism used by IKEv2 utilizes a token authenticator, and the enterprise deploys a non-encrypted web form which accepts the input from the token authenticator, a man-in-the-middle attacker could impersonate the web server, intercept the token authentication exchange, and use it to initiate an IKEv2 connection. For this reason, use of non-key-generating EAP methods SHOULD be avoided where possible. Where they are used, it is extremely important that all usages of these EAP methods SHOULD utilize a protected tunnel, where the initiator validates the responder's certificate before initiating the EAP exchange. Implementors SHOULD describe the vulnerabilities of using non-key-generating EAP methods in the documentation of their implementations so that the administrators deploying IPSEC solutions are aware of these dangers. Add the following reference: [EAPMITM] N. Asokan, Valtteri Nierni, and Kaisa Nyberg, "Man-in-the-Middle in Tunneled Authentication Protocols", http://eprint.iacr.org/2002/163, November 11, 2002. ---------------------------------------------------- 2. Rekeying clarifications From David Black's note of August 20, 2003: Subject: RE: The remaining IKEv2 issues - #64 To: Charlie_Kaufman@notesdev.ibm.com Charlie, As part of this (unless I missed it), please add sentences to make the following points: - IKEv2 deliberately allows parallel SAs with the same traffic selectors between common endpoints. One of the purposes of this is to support traffic QoS differences among the SAs; see Section 4.1 of RFC 2983 (informative reference). - Hence unlike IKEv1, given two endpoints, traffic selectors need not uniquely identify an SA between those endpoints. - Therefore the IKEv1 rekeying heuristic (use of same traffic selectors as an existing SA indicates rekeying, so existing SA should be deleted shortly after new one is up) SHOULD NOT be used, as it will result in unintended SA deletion. This may help avoid some surprises arising from implementation code reuse. Also, [RFC2401bis] needs to be added to the list of normative references. -------------------------------------------- 3. ECN clarifications: Replace the text of section 2.24 with the following, per suggested the rewording from David Black: When IPsec tunnels behave as originally specified in [RFC 2401], ECN usage is not appropriate for the outer IP headers because tunnel decapsulation processing discards ECN congestion indications to the detriment of the network. ECN support for IPsec tunnels for IKEv1-based IPsec requires multiple operating modes and negotiation (see [RFC 3168]). IKEv2 simplifies this situation requiring that ECN be usable in the outer IP headers of all tunnel-mode IPsec SAs created by IKEv2. Specifically, tunnel encapsulators and decapsulators for all tunnel-mode Security Associations (SAs) created by IKEv2 MUST support the ECN full-functionality option for tunnels specified in [RFC3168] and MUST implement the tunnel encapsulation and decapsulation processing specified in [RFC2401bis] to prevent discarding of ECN congestion indications. NB: [RFC 2401] reference is informative, [RFC 3168] and [2401bis] are normative. ---------------------------------- 4. Nat traversal clarification. In section 2.23, Nat Traversal reads: There are cases where a NAT box decides to remove mappings that are still alive (for example, the keepalive interval is too long, or the NAT box is rebooted). To recover in these cases, hosts that are not behind a NAT SHOULD send all packets (including retried packets) to the IP address and port from the last valid authenticated packet from the other end. A host not behind a NAT ^^^ typo, delete SHOULD NOT do this because it opens a DoS attack possibility. Any authenticated IKE packet or any authenticated IKE encapsulated ESP ^^^ typo, replace with UDP packet can be used to detect that the IP address or the port has changed. -------------------------------------- 5. Friends don't let friends use ASN.1 In section 3.6, certificate payload, the description of the ASN.1 for a certificate bundle is ambiguous. Hash and URL of PKIX bundle (13) contains a 20 octet SHA-1 hash of a PKIX certificate bundle followed by a variable length URL the resolves to the BER encoded certificate bundle itself. The bundle is a BER encoded SEQUENCE of certificates and CRLs. Use the following ASN.1 definition suggested by Nicholas Williams DEFINITION EXPLICIT TAGS ::= BEGIN IMPORTS Certificate, CertificateList FROM PKIX1Explicit93 CertificateOrCRL ::= CHOICE { cert [0] Certificate, crl [1] CertificateList } CertificateBundle ::= SEQUENCE OF CertificateOrCRL END From owner-ipsec@lists.tislabs.com Mon Sep 29 17:37:39 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8U0bcKP064391; Mon, 29 Sep 2003 17:37:38 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11339 Mon, 29 Sep 2003 19:54:37 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 29 Sep 2003 17:03:10 -0700 To: "Theodore Ts'o" , Charlie Kaufman , byfraser@cisco.com, angelos@cs.columbia.edu, kivinen@ssh.fi From: Paul Hoffman / VPNC Subject: Re: Final editing instructions for ikev2 document Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:31 PM -0400 9/29/03, Theodore Ts'o wrote: >Use the following ASN.1 definition suggested by Nicholas Williams Close, but it doesn't match RFC 3280, which is already the normative reference. > > DEFINITION EXPLICIT TAGS ::= > BEGIN > > IMPORTS Certificate, CertificateList FROM PKIX1Explicit93 That should be "PKIX1Explicit88". > > CertificateOrCRL ::= CHOICE { > cert [0] Certificate, > crl [1] CertificateList > } > > CertificateBundle ::= SEQUENCE OF CertificateOrCRL > END --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Sep 29 23:20:57 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8U6KuKP008726; Mon, 29 Sep 2003 23:20:56 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA14282 Tue, 30 Sep 2003 01:37:33 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Tue, 30 Sep 2003 01:49:06 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue # 81 -- Handling outbound red fragments Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 81 Title: Handling outbound red fragments Description: ============= Plaintext |---------------| Cyphertext Outbound | | Inbound ----------->| IPsec |<------------ | entity 1 | | | |---------------| Although there is some ambiguity, 2401 generally states that SAs configured for transport mode operation do not accept outbound red IP fragments as inputs. In contrast, tunnel mode SAs are allowed to accept outbound red fragments as inputs for BITS, BITW, and security gateway implementations. Accepting outbound fragments raises the question of how to select an SPD entry, since a fragment may be missing applicable selector fields. 2401 indicates that a fragment can be mapped to an SA only if the SA selectors for the unavailable field(s) are marked as OPAQUE or ANY. Should we change how IPsec handles this situation? Note: While transport mode doesn't work with outbound red IP fragments in IPv4, it would work for IPv6... a. For IPv4, in each fragment, the IPsec header is inserted between the IPv4 header, which contans the fragmentation-related fields, and the payload. The receiving system processes the fragmentation information before the IPsec header and does reassembly before IPsec processing. It thus ends up with a re-assembled packet containing IPsec headers (as many as there were fragments) interspersed throughout the data. b. For IPv6, in each fragment, the IPsec header is inserted before the fragmentation-related fields. The receiving system processess the extension headers in order, doing the IPsec processing before reassembly. It thus ends up with a re-assembled packet containing only the original payload and no IPsec headers. Proposed approach: ================== The current section on how to handle outbound fragments when the port fields may be inaccessible will be replaced by the following approach. "Between each of pair of IPsec implementations, one or more tunnel-mode SA will be established that are used to carry ONLY non-initial red fragments, if both the source and destination end of the IPsec tunnel-mode SA agree to transmit/receive fragments (as determined via IKE negotiation or manual configuration). To provide this facility, the IPsec implementation MUST support the following: The SPD entries for the fragment tunnels specify what kind of tunnel mode protections are required and MUST have their selectors specified as follows: WILDCARD = a single range that covers all possible values OPAQUE = the value is not available, e.g., it's encrypted or the protocol doesn't have that selector, etc. ANY = opaque or wildcard Field SPD Entry -------- ------------- src addr WILDCARD, flag set to use the packet value dst addr WILDCARD, flag set to use the packet value protocol* 44 src port ANY dst port ANY user id ANY sec. labels ANY mobil. hdr type ANY ICMP type ANY * IPv6 non-initial fragments use 44 to indicate a fragment. When an initial fragment is received, its selectors will be used to look up a matching entry (for packets) in the SPD. If necessary, an SA will be created and the appropriate IPsec protection will be applied. Normal SA setup procedures are followed. When a non-initial fragment is received, the IPsec implementation uses protocol = 44 (fragment) plus the fragment's other selectors (at a minimum, IP source and destination addresses) to look up a matching entry in the SPD. If necessary, an SA will be created and the appropriate IPsec protection will be applied. Normal SA setup procedures are followed. Because all non-initial fragments will be mapped to SAs using protocol selector = 44, the non-initial fragments will automatically be placed on the SAs intended for their use. At the receiving end of the fragment SA, the IPsec implementation MUST check and remove the tunnel header, check the fragment's selectors against the selectors of the SA, having set the fragment's "protocol" to 44, and verify that the fragment is a non-initial fragment by looking at the fragment's offset. There MUST be a mechanism for the administrator to configure a minimum fragment offset value to avoid a non-initial fragment from overwriting selectors in the initial fragment. This MAY be a single value or there MAY be separate values for IPv4 and IPv6. The IPsec implementation MUST verify that the fragment offset is greater than or equal to the minimum offset value. Thank you, Karen From owner-ipsec@lists.tislabs.com Mon Sep 29 23:21:00 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8U6L0KP008745; Mon, 29 Sep 2003 23:21:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA14299 Tue, 30 Sep 2003 01:37:37 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Tue, 30 Sep 2003 01:49:09 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue # 85 -- DROP'd inbound packet -- does not match SA Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 85 Title: DROP'd inbound packet -- does not match SA Description =========== Should there be a defined ICMP response to be used when an IPsec implementation drops an inbound, IPsec-protected packet, whose selectors do not match those of the SA on which it was delivered? The intent is to indicate to the sender that the receiver dropped the packet. Proposed approach ================= Add text saying something along the lines of... "If an IPsec system receives an inbound packet whose selectors do not match those of the SA on which it was delivered, it MUST drop the packet. It SHOULD also be capable of generating and sending an ICMP message to indicate to the sender (the IPsec encapsulator) that the packet has been dropped by the receiver. The reason SHOULD be recorded in the audit log. IPv4 Type = 3 (destination unreachable) Code = 13 (Communication Administratively Prohibited) IPv6 Type = 1 (destination unreachable) Code = 1 (Communication with destination administratively prohibited "The implementation SHOULD provide management controls to allow an administrator to configure an IPsec implementation to send or not send the above ICMP message, or to rate limit the transmission of such ICMP responses." Thank you, Karen From owner-ipsec@lists.tislabs.com Mon Sep 29 23:22:37 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8U6MaKP009329; Mon, 29 Sep 2003 23:22:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA14301 Tue, 30 Sep 2003 01:37:44 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Tue, 30 Sep 2003 01:49:09 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue # 84 -- DROP'd outbound packet Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 84 Title: DROP'd outbound packet Description =========== Plaintext |---------------| Outbound | | Sender ---------->| IPsec | ----> IPsec | entity | Peer | | |---------------| Should there be a defined ICMP response to be used when an IPsec implementation drops an outbound packet to indicate to the sender that the packet was dropped? The packet could be dropped for several kinds of reasons: a. the policy mandated by the receiver's SPD entry (DISCARD) b. inability of the initiator to set up the required SA -- There are many reasons why this might happen. The IPsec peer at the other end of the exchange is down, is administratively prohibited from talking with the initiator, etc. Just for easy reference... the IPv4 and IPv6 "destination unreachable types and codes are: IPv4: Type Name Reference ---- ------------------------- --------- 3 Destination Unreachable [RFC792] Codes 0 Net Unreachable 1 Host Unreachable 2 Protocol Unreachable 3 Port Unreachable 4 Fragmentation Needed and Don't Fragment was Set 5 Source Route Failed 6 Destination Network Unknown 7 Destination Host Unknown 8 Source Host Isolated 9 Communication with Destination Network is Administratively Prohibited 10 Communication with Destination Host is Administratively Prohibited 11 Destination Network Unreachable for Type of Service 12 Destination Host Unreachable for Type of Service 13 Communication Administratively [RFC1812] Prohibited 14 Host Precedence Violation [RFC1812] 15 Precedence cutoff in effect [RFC1812] IPv6: Type Name Reference ---- ------------------------- --------- 1 Destination Unreachable [RFC2463] Codes 0 - no route to destination 1 - communication with destination administratively prohibited 2 - (not assigned) 3 - address unreachable 4 - port unreachable Proposed approach ================= Add text saying something along the lines of... "For the situation where an IPsec system receives an outbound packet which it finds it must drop, it SHOULD be capable of generating and sending an ICMP message to indicate to the sender of the outbound packet that the packet was dropped. The type and code of the ICMP message will depend on the reason for dropping the packet. The reason SHOULD be recorded in the audit log. a. the selectors of the packet matched an SPD entry requiring the packet to be dropped --> IPv4 Type = 3 (destination unreachable) Code = 13 (Communication Administratively Prohibited) IPv6 Type = 1 (destination unreachable) Code = 1 (Communication with destination administratively prohibited b1. the IPsec system was unable to set up the SA required by the SPD entry matching the packet because the IPsec peer at the other end of the exchange is administratively prohibited from communicating with the initiator and rejects the negotiation. IPv4 Type = 3 (destination unreachable) Code = 13 (Communication Administratively Prohibited) IPv6 Type = 1 (destination unreachable) Code = 1 (Communication with destination administratively prohibited b2. the IPsec system was unable to set up the SA required by the SPD entry matching the packet because the IPsec peer at the other end of the exchange could not be contacted. The type should be destination unreachable, but what codes should we use? IPv4 Type = 3 (destination unreachable) Code = ?? IPv6 Type = 1 (destination unreachable) Code = ?? Note that an attacker behind a security gateway could send packets with a spoofed source address, W.X.Y.Z, to an IPsec entity causing it to send ICMP messages to W.X.Y.Z. This creates an opportunity for a DoS attack among hosts behind a security gateway. To address this, a security gateway SHOULD include a management control to allow an administrator to configure an IPsec implementation to send or not send the above ICMP message, or to rate limit the transmission of such ICMP responses. Thank you, Karen From owner-ipsec@lists.tislabs.com Mon Sep 29 23:22:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8U6MkKP009379; Mon, 29 Sep 2003 23:22:46 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA14283 Tue, 30 Sep 2003 01:37:33 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Tue, 30 Sep 2003 01:49:07 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue # 82 -- Creation of SAs -- clarifications Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 82 Title: Creation of SAs -- clarifications Description: ============ 2401's text on the SPD currently says: "For each selector, the policy entry specifies how to derive the corresponding values for a new Security Association Database (SAD, see Section 4.4.3) entry from those in the SPD and the packet (Note that at present, ranges are only supported for IP addresses; but wildcarding can be expressed for all selectors): a. use the value in the packet itself -- This will limit use of the SA to those packets which have this packet's value for the selector even if the selector for the policy entry has a range of allowed values or a wildcard for this selector. b. use the value associated with the policy entry -- If this were to be just a single value, then there would be no difference between (b) and (a). However, if the allowed values for the selector are a range (for IP addresses) or wildcard, then in the case of a range, (b) would enable use of the SA by any packet with a selector value within the range not just by packets with the selector value of the packet that triggered the creation of the SA. In the case of a wildcard, (b) would allow use of the SA by packets with any value for this selector." [Note that in IPsec issue 47, it was proposed that all selectors can be a list of ranges, per IKEv2 spec.] A number of questions have arisen about the 2 options above, in particular for Option a -- use the value in the packet. We need to clarify how the SPD entries can be used to create SAs for various combinations of selectors, e.g., to ensure creation of separately key'd SAs for each pair of hosts. Proposed approach: ================== Clarify the text about the SPD to say that Option (a) for instantiating selectors when creating an SA (use the value in the packet itself)... "can not only be used to create per-host, per-port, or per-protocol keyed SAs, but also to create new SAs based upon unique values of any set of selectors." Note: For implementors using decorrelation, there will be an appendix with implementor's notes describing how to avoid creating any unnecessary SAs for a set of decorrelated SPD entries created from the same original correlated SPD entry when one or more selector values are populated from subscriber traffic. Thank you, Karen From owner-ipsec@lists.tislabs.com Mon Sep 29 23:23:24 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8U6NNKP009588; Mon, 29 Sep 2003 23:23:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA14300 Tue, 30 Sep 2003 01:37:39 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Tue, 30 Sep 2003 01:49:07 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue # 83 -- DROP'd inbound packet -- missing required IPsec protection Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 83 Title: DROP'd inbound packet -- missing required IPsec protection Description =========== Should there be a defined ICMP response to be used (when dropping an inbound packet that was not protected by IPsec) to indicate to the sender that IPsec was required by the receiver who dropped the packet? Proposed approach ================= Add text saying something along the lines of... "If an IPsec system receives an inbound (unprotected) packet for which the matching SPD entry requires IPsec protection, it MUST drop the packet. It SHOULD also be capable of generating and sending an ICMP message to indicate to the sender that the receiver dropped the packet. The reason SHOULD be recorded in the audit log. IPv4 Type = 3 (destination unreachable) Code = 13 (Communication Administratively Prohibited) IPv6 Type = 1 (destination unreachable) Code = 1 (Communication with destination administratively prohibited Note that an attacker could send packets with a spoofed source address, W.X.Y.Z, to an IPsec entity causing it to send ICMP messages to W.X.Y.Z. This creates an opportunity to use an IPsec receiver in a DoS attack. To address this, the implementation SHOULD provide management controls to allow an administrator to configure an IPsec implementation to send or not send the above ICMP message, or to rate limit the transmission of such ICMP responses. Thank you, Karen From owner-ipsec@lists.tislabs.com Mon Sep 29 23:43:41 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8U6heKP015927; Mon, 29 Sep 2003 23:43:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA14572 Tue, 30 Sep 2003 02:01:45 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Tue, 30 Sep 2003 02:13:27 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue # DD -- Anti-replay notification Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, At present, RFC2407 ("The Internet IP Security Domain of Interpretation for ISAKMP") defines a REPLAY-STATUS notify message that IKEv1 can use to tell a peer whether or not it has anti-replay enabled for a particular SA. (It's chained onto a Quick Mode message a la RESPONDER-LIFETIME.) The default is to assume anti-replay is enabled. But this capability is not in IKEv2. We'd like to propose that IKEv2 also allow the receiver to notify the sender whether or not anti-replay is enabled. In the case where anti-replay isn't being supported by the receiver, this would allow the sender to avoid setting up a new SA when the replay counter rolls over. Thank you, Karen From owner-ipsec@lists.tislabs.com Mon Sep 29 23:53:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8U6rQKP019143; Mon, 29 Sep 2003 23:53:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA14680 Tue, 30 Sep 2003 02:12:20 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Tue, 30 Sep 2003 02:24:07 -0400 To: ipsec mailingList From: Karen Seo Subject: out of office Cc: byfraser@cisco.com, tytso@mit.edu, Russ Housley , "Steven M. Bellovin" , "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Just a heads up that Steve Kent will be away on travel from 9/29 to 10/12, mostly without email access. So you may not see any replies from him until he returns. Where possible, Charlie Lynn and I will make up answers in his place :-) but we will mostly focus on continuing to send out issues and incorporate approved changes into 2401bis. Karen From owner-ipsec@lists.tislabs.com Tue Sep 30 02:14:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8U9EeKP049808; Tue, 30 Sep 2003 02:14:41 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA16579 Tue, 30 Sep 2003 04:36:25 -0400 (EDT) Message-Id: <200309300845.h8U8j4HN066618@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Theodore Ts'o" cc: Charlie Kaufman , byfraser@cisco.com, angelos@cs.columbia.edu, kivinen@ssh.fi, ipsec@lists.tislabs.com Subject: Re: Final editing instructions for ikev2 document In-reply-to: Your message of Mon, 29 Sep 2003 18:31:36 EDT. Date: Tue, 30 Sep 2003 10:45:04 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Note the peer address issue is not yet solved. In a discussion between me and Tero we reach an agreement about what to do but we didn't propose a wording... Regards Francis.Dupont@enst-bretagne.fr PS: the idea is to use for the peer addresses (the addresses IKE runs over) the addresses used in the initial phase. This is what I called "to make the peer addresses IKE SA parameters". The 2.11 section should be clarified. From owner-ipsec@lists.tislabs.com Tue Sep 30 03:24:43 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UAOgKP053467; Tue, 30 Sep 2003 03:24:42 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA17212 Tue, 30 Sep 2003 05:45:24 -0400 (EDT) Message-Id: <200309300953.h8U9rkHN067176@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Richardson cc: ipsec mailingList , byfraser@cisco.com Subject: Re: 2401bis Issue # 77 -- Should AH be mandatory? In-reply-to: Your message of Thu, 25 Sep 2003 18:30:09 EDT. <14991.1064529009@marajade.sandelman.ottawa.on.ca> Date: Tue, 30 Sep 2003 11:53:46 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: >>>>> "Karen" == Karen Seo writes: Karen> IPsec by not requiring AH and supporting just ESP. However, there Karen> are clearly communities, e.g., Mobile IP, that are using AH. I believe that it is being abandoned by these groups because we won't adjust the specification to make it work properly for them. => for Mobile IPv6 AH was possible (in fact many, including me, believe it is better) but for simplicity it was removed from specs, first as the default mechanism, then everywhere... Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Sep 30 03:27:21 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UARKKP053608; Tue, 30 Sep 2003 03:27:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA17264 Tue, 30 Sep 2003 05:53:42 -0400 (EDT) Message-Id: <200309301001.h8UA1iHN067233@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Karen Seo cc: ipsec mailingList , byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi Subject: Re: 2401bis Issue # 84 -- DROP'd outbound packet In-reply-to: Your message of Tue, 30 Sep 2003 01:49:09 EDT. Date: Tue, 30 Sep 2003 12:01:44 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: IPv6: Type Name Reference ---- ------------------------- --------- 1 Destination Unreachable [RFC2463] => draft-ietf-ipngwg-icmp-v3-02.txt is more up to date. Codes 0 - no route to destination 1 - communication with destination administratively prohibited 2 - (not assigned) => reassigned to "beyond scope of source address" 3 - address unreachable 4 - port unreachable b2. the IPsec system was unable to set up the SA required by the SPD entry matching the packet because the IPsec peer at the other end of the exchange could not be contacted. The type should be destination unreachable, but what codes should we use? IPv4 Type = 3 (destination unreachable) Code = ?? IPv6 Type = 1 (destination unreachable) Code = ?? => IMHO the code should follow the reason why the IPsec peer could not be contacted with code 1 by default? Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Sep 30 04:51:15 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UBpEKP057512; Tue, 30 Sep 2003 04:51:14 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA18080 Tue, 30 Sep 2003 07:15:33 -0400 (EDT) Message-Id: <5.2.0.9.0.20030930170302.00a09460@202.125.80.81> X-Sender: ravivsn@202.125.80.81 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 30 Sep 2003 17:03:36 +0530 To: Karen Seo , ipsec mailingList From: Ravi Kumar Subject: Re: 2401bis Issue # 79 -- Detection of dead peers and dead SAs Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have submitted one draft that works with IKE v1. I have submitted this to the list long time back. If anybody interested in it, write to me. Thanks Ravi At 11:05 PM 9/26/03 -0400, Karen Seo wrote: >Folks, > >Here's a description and proposed approach for: > >IPsec Issue #: 79 > >Title: Detection of dead peers and dead SAs > >Description: >============ >In the absence of mechanisms to detect dead peers or dead SAs, an IPsec >system could waste resources by continuing to send traffic to a peer that >will discard the traffic > >IKEv2 addresses these problems. IKEv2 explicitly contains a dead peer >detection mechanism. IKEv2 specifies that a peer cannot close an SA >created using IKEv2 without either sending an IKEv2 "delete" message or >closing the IKE SA. This guarantees that there cannot be undetected dead >ESP or AH SAs. It does >place a burden on implementations to keep the IKE SA and the IPsec SA >state synchronized. > >For IKEv1, vendors have implemented different mechanisms, some of which >are incompatible, but we have no plans to address this problem in the IKE >v1 context. > >Proposed approach: >================== >No change to 2401bis. > > >Thank you, >Karen The Views Presented in this mail are completely mine. The company is not responsible for what so ever. ---------- Ravi Kumar CH Rendezvous On Chip (I) Pvt Ltd Hyderabad, INDIA ROC HOME PAGE: http://www.roc.co.in From owner-ipsec@lists.tislabs.com Tue Sep 30 04:51:15 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UBpEKP057513; Tue, 30 Sep 2003 04:51:14 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA18074 Tue, 30 Sep 2003 07:14:35 -0400 (EDT) Message-Id: <5.2.0.9.0.20030930170112.00a0a910@202.125.80.81> X-Sender: ravivsn@202.125.80.81 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 30 Sep 2003 17:02:32 +0530 To: Karen Seo , ipsec mailingList From: Ravi Kumar Subject: Re: 2401bis Issue # 78 -- PMTU issues Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am OK with postponing. But, we can recommend 'Fragmentation before encapsulation' while sending out the packet and MUST not drop incoming redside IP fragment. I observed some implementation don't interoperate when we do this. .By keeping the above statement, hopefully other implementation take care of reassembling the de-secured IP fragments before matching up with inbound security policies. Regards Ravi At 11:04 PM 9/26/03 -0400, Karen Seo wrote: >Folks, > >Here's a description and proposed approach for: > >IPsec Issue #: 78 > >Title: PMTU issues > >Description: >============ >In addition to the issue of how to handle ICMP error messages in general, >there is the specific question of is there some way that systems can do >Path MTU discovery other than by relying on ICMP error messages (PMTUs) >from untrusted sources? Note that we are much more concerned about ICMP >messages arriving w/o IPsec protection from the public Internet vs. such >messages arriving from a router "behind" an SG. > >Proposed approach: >================== >1. Add controls to allow an administrator to configure the IPsec system to >set a threshold for the minimum size to which the PTMU can be set via >processing an ICMP PMTU from a public Internet source. The default is that >the ciphertext size would be 576 bytes (IPv4) or 1280 (IPv6). These values >are likely to be sufficient in almost all cases; and one might adopt the >Ethernet MTU of 1500 bytes for IPv4 and IPv6. > >2. Develop a red side PMTU discovery protocol, for tunnels, to avoid the >PMTU attack problem, and switch to red side fragmentation (fragmenting >before IPsec is applied but allowing for IPsec headers), vs. black side >fragmentation, to minimize the DoS problems for receivers. If we put this >mechanism into IPsec, each peer can determine whether the peer at the >other end of an SA supports this capability (via IKE) and the SA can >provide the protected path. There is another working group working on this >problem -- see PMTUD WG, email pmtud@ietf.org. We propose to put this >task on hold until they're finished. > > >Thank you, >Karen The Views Presented in this mail are completely mine. The company is not responsible for what so ever. ---------- Ravi Kumar CH Rendezvous On Chip (I) Pvt Ltd Hyderabad, INDIA ROC HOME PAGE: http://www.roc.co.in From owner-ipsec@lists.tislabs.com Tue Sep 30 04:52:04 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UBq3KP057566; Tue, 30 Sep 2003 04:52:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA18102 Tue, 30 Sep 2003 07:16:55 -0400 (EDT) Message-Id: <5.2.0.9.0.20030930170415.00a0d6d0@202.125.80.81> X-Sender: ravivsn@202.125.80.81 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 30 Sep 2003 17:04:30 +0530 To: Karen Seo , ipsec mailingList From: Ravi Kumar Subject: Re: 2401bis Issue # 82 -- Creation of SAs -- clarifications Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I feel, clarification on QM ID payload contents and their interpretation when SP is configured to use packet selectors. SP(Security Policy) can be configured with IP address ranges or subnet along with these as Packet selectors. As a QM initiator, it needs to send the packet IP address to the remote SG. Remote SG should not reject this ID, if it falls in SP selector space when configured with Packet Selector option. It seems that some implementations reject the QM if the ID contents don't match exactly with what is configured in the SP. This is OK when SP is configured with Policy selectors, but not when configured with Packet selectors. I feel this needs to be clarified in 2401bis. Thanks Ravi At 01:49 AM 9/30/03 -0400, Karen Seo wrote: >Folks, > >Here's a description and proposed approach for: > >IPsec Issue #: 82 > >Title: Creation of SAs -- clarifications > >Description: >============ >2401's text on the SPD currently says: > >"For each selector, the policy entry specifies how to derive the >corresponding values for a new Security Association Database (SAD, see >Section 4.4.3) entry from those in the SPD and the packet (Note that at >present, ranges are only supported for IP addresses; but wildcarding can >be expressed for all selectors): > > a. use the value in the packet itself -- This will limit > use of the SA to those packets which have this > packet's value for the selector even if the selector > for the policy entry has a range of allowed values or > a wildcard for this selector. > b. use the value associated with the policy entry -- If > this were to be just a single value, then there would > be no difference between (b) and (a). However, if the > allowed values for the selector are a range (for IP > addresses) or wildcard, then in the case of a range, > (b) would enable use of the SA by any packet with a > selector value within the range not just by packets > with the selector value of the packet that triggered > the creation of the SA. In the case of a wildcard, > (b) would allow use of the SA by packets with any value > for this selector." > >[Note that in IPsec issue 47, it was proposed that all selectors can be a >list of ranges, per IKEv2 spec.] > >A number of questions have arisen about the 2 options above, in particular >for Option a -- use the value in the packet. We need to clarify how the >SPD entries can be used to create SAs for various combinations of >selectors, e.g., to ensure creation of separately key'd SAs for each pair >of hosts. > > >Proposed approach: >================== >Clarify the text about the SPD to say that Option (a) for instantiating >selectors when creating an SA (use the value in the packet itself)... > >"can not only be used to create per-host, per-port, or per-protocol keyed >SAs, but also to create new SAs based upon unique values of any set of >selectors." > >Note: For implementors using decorrelation, there will be an appendix with >implementor's notes describing how to avoid creating any unnecessary SAs >for a set of decorrelated SPD entries created from the same original >correlated SPD entry when one or more selector values are populated from >subscriber traffic. > >Thank you, >Karen The Views Presented in this mail are completely mine. The company is not responsible for what so ever. ---------- Ravi Kumar CH Rendezvous On Chip (I) Pvt Ltd Hyderabad, INDIA ROC HOME PAGE: http://www.roc.co.in From owner-ipsec@lists.tislabs.com Tue Sep 30 06:17:41 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UDHeKP062043; Tue, 30 Sep 2003 06:17:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18871 Tue, 30 Sep 2003 08:38:10 -0400 (EDT) From: Charles Lynn To: ipsec mailingList Subject: Re: 2401bis Issue # 75 -- TOS (now ECN) copying in tunnel mode In-Reply-To: Message-Id: <20030930124655.E405316484@wolfe.bbn.com> Date: Tue, 30 Sep 2003 08:46:55 -0400 (EDT) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Description: > ============ > The issue was raised that a Trojan Horse "behind" the IPsec > implementation could use the TOS field to exfiltrate data. If the concern is data exfiltration, it seems that there should also be a way to allow an administrator to restrict the DSCP values that may be used (by an application) in transport mode (as well as tunnel mode) SAs. As IPsec moves into hosts (or their NICs), there may not be any SG in the path that would implement the DSCP mapping policy. Should those concerned about exfiltration just be advised to require a SG? (A topic for the Security Considerations section.) Should data exfiltration in general be a new issue? From owner-ipsec@lists.tislabs.com Tue Sep 30 06:27:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UDRNKP062427; Tue, 30 Sep 2003 06:27:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19017 Tue, 30 Sep 2003 08:52:19 -0400 (EDT) Date: Tue, 30 Sep 2003 08:52:19 -0400 (EDT) From: owner-ipsec@lists.tislabs.com Message-Id: <200309301252.IAA19017@lists.tislabs.com> (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id PAA09741 Mon, 29 Sep 2003 15:29:22 -0400 (EDT) via csmap (V6.0) id srcAAAcHaOzK; Mon, 29 Sep 03 15:36:32 -0400 Message-Id: <200309291937.PAA06509@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-nat-t-ike-07.txt Date: Mon, 29 Sep 2003 15:37:56 -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 : Negotiation of NAT-Traversal in the IKE Author(s) : T. Kivinen et al. Filename : draft-ietf-ipsec-nat-t-ike-07.txt Pages : 13 Date : 2003-9-29 This document describes how to detect one or more network address trans- lation devices (NATs) between IPsec hosts, and how to negotiate the use of UDP encapsulation of the IPsec packets through the NAT boxes in Internet Key Exchange (IKE). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-nat-t-ike-07.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-nat-t-ike-07.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: <2003-9-29152950.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-nat-t-ike-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-nat-t-ike-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-29152950.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Sep 30 06:28:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UDS3KP062454; Tue, 30 Sep 2003 06:28:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18993 Tue, 30 Sep 2003 08:51:17 -0400 (EDT) Date: Tue, 30 Sep 2003 08:51:17 -0400 (EDT) From: owner-ipsec@lists.tislabs.com Message-Id: <200309301251.IAA18993@lists.tislabs.com> (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id CAA14855 Tue, 30 Sep 2003 02:26:51 -0400 (EDT) Message-Id: <5.2.0.9.0.20030930121518.009ea780@202.125.80.81> X-Sender: ravivsn@202.125.80.81 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 30 Sep 2003 12:16:15 +0530 To: Stephen Kent , ipsec@lists.tislabs.com From: Ravi Kumar Subject: Re: SPD issues In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, In a typical CPE gateways, one SPD is good enough. But in PPVPN (MTU/MDU or ISP markets) context, one SPD per subscriber is needed. Again, the subscriber can't be associated with interface. It is possible that subscribe can have more than one interface associated with him/her. Also, the selection of SPD may not even depend on interface. It can be based on VLAN ID or MPLS Label. Due to this, I vote your conclusion statement (with one exception). Keep the multiple SPD concept. Keep the SPD selection to the implementations. Regards Ravi At 06:50 PM 9/24/03 -0400, Stephen Kent wrote: >Folks, > >In revising the processing mode, based on feedback from various folks, I >want to make sure that we have enough functionality, but not more than is >really needed. In this regard, I want to conduct a quick poll. > >The topic, in a way, is how many SPDs do we need? 2401 says we have an >SPD per interface, but maybe that's not enough, or too many, or just not >the right question to be asking. > >So, let's ask the question differently. What are the inputs needed to >select the right SPD? > - In a very simple context it seems we could get away with just > one SPD, relative to which all traffic is examined. so any answer we > choose must yield this answer for the simple cases. > > - In a PPVPN context, having a different SPD per subscriber seems > to make sense, since the intent it so allow each subscriber to define > his/her own SPD. In this case, the SPD could be selected based on the > source of the (outbound) traffic. You could think of this as being per > interface, relative to the interfaces via which the outbound traffic > arrives, but it does not imply a need for different SPDs for the > interfaces via which inbound traffic arrives, an asymmetry. > > - My previous proposal for a revised processing model, from a few > weeks ago, retained the idea of multiple SPDs, allocating them to virtual > interfaces, and introduced the notion of a forwarding function to select > the right virtual interface, and thus SPD. But, unless we feel a need to > have different SPDs per interface, this seems like overkill. I think we > do want to allow forwarding of outbound traffic to be independent of SPD > selection, so some notion of an explicit forwarding function in the model > still seems appropriate. but, as we discussed the model, there was a > suggestion that we might need two such functions, one to select an SPD, > and then one to be applied after IPsec processing. maybe, if we separate > SPD selection from interface selection we can have two functions but only > one of them is really for forwarding. > > - Along those lines, we could introduce an SPD selector function > that, like the forwarding function, can use any info in a packet to > select an SPD, but without associating the SPD with an interface per se. > >Comments? > >Steve The Views Presented in this mail are completely mine. The company is not responsible for what so ever. ---------- Ravi Kumar CH Rendezvous On Chip (I) Pvt Ltd Hyderabad, INDIA ROC HOME PAGE: http://www.roc.co.in From owner-ipsec@lists.tislabs.com Tue Sep 30 06:28:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UDSdKP062490; Tue, 30 Sep 2003 06:28:39 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19032 Tue, 30 Sep 2003 08:53:31 -0400 (EDT) Date: Tue, 30 Sep 2003 08:53:31 -0400 (EDT) From: owner-ipsec@lists.tislabs.com Message-Id: <200309301253.IAA19032@lists.tislabs.com> (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id QAA10263 Mon, 29 Sep 2003 16:44:19 -0400 (EDT) nutshell.tislabs.com via csmap (V6.0) id srcAAAYqaigR; Mon, 29 Sep 03 16:51:28 -0400 (CA-Mail01.CA.iPolicyNet.COM [199.172.181.4]) by mail.iPolicyNet.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA04522 for ; Mon, 29 Sep 2003 13:26:49 -0700 (PDT) (5.5.2653.19) id ; Mon, 29 Sep 2003 13:39:22 -0700 Message-ID: From: "Prasad, Rajendra" To: "Ipsec (E-mail)" Subject: IKE Cert Sign Problem with RSA using MD5 as hash Algo Date: Mon, 29 Sep 2003 13:39:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C386C9.C2A68FB0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C386C9.C2A68FB0 Content-Type: text/plain; charset="ISO-8859-1" Hi, I am working on the digital certificate support for our VPN gateway and it works fine with RSA SHA1 (hash algo). When I am using MD5 hash algo, I get an error on remote for signature verification failed. I am using BCM5820 crypto engine and I have tried using OpenSSL also. What is difference between Signature for SHA1 hash and MD5 hash? How I can resolve this issue? thanks Rajendra ------_=_NextPart_001_01C386C9.C2A68FB0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable IKE Cert Sign Problem with RSA using MD5 as hash Algo

Hi,

I am working on the digital = certificate support for our VPN gateway and it works fine with RSA SHA1 = (hash algo). When I am using MD5 hash algo, I get an error on remote = for signature verification failed. I am using BCM5820 crypto engine and = I have tried using OpenSSL also.

What is difference between Signature = for SHA1 hash and MD5 hash?

How I can resolve this issue?

thanks
Rajendra

------_=_NextPart_001_01C386C9.C2A68FB0-- From owner-ipsec@lists.tislabs.com Tue Sep 30 07:41:49 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UEfkKP068385; Tue, 30 Sep 2003 07:41:48 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20151 Tue, 30 Sep 2003 09:54:23 -0400 (EDT) From: Charles Lynn To: Francis Dupont Cc: ipsec@lists.tislabs.com Subject: Re: 2401bis Issue # 84 -- DROP'd outbound packet In-Reply-To: <200309301001.h8UA1iHN067233@givry.rennes.enst-bretagne.fr> Message-Id: <20030930140304.EEDCD16508@wolfe.bbn.com> Date: Tue, 30 Sep 2003 10:03:04 -0400 (EDT) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis observes: > => IMHO the code should follow the reason why the IPsec peer could not > be contacted with code 1 by default? To amplify, it is hard for the receiver of an ICMP message that only uses one code to decide how to respond/notify the user about the detected error. There are several cases: 1) There are (temporary) network connectivity problems during IKE; the communication should be retried "in a while". 2) There are (temporary) (black or red) network connectivity problems during the user's communication, the communication may not succeed at the current time; one could wait, or try again later. 3) The communication is prohibited by policy; do not retry until the security officer(s) have reached an agreement. Note that the prohibition can be detected by either of the IKE peers. 4) The packet that was received is protected as required by the local policy, but it is not a packet that should be sent via the SA that was used (access control violation); your implementation is broken, or your key has been compromised. The SG transiting the ICMP might try to rekey the SA to establish a new key, but that will not fix a broken implementation. 5) The packet that was received is not protected as required by the local policy; this could be part of a DDoS attack, so a way to limit the ICMP rate is especially important in this case. It would be nice it the user could be given some indication of the problem so that they could initiate corrective action. Should we define additional ICMP codes to distinguish the cases? I think we should. From owner-ipsec@lists.tislabs.com Tue Sep 30 10:13:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UHDsKP077544; Tue, 30 Sep 2003 10:13:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21753 Tue, 30 Sep 2003 12:26:15 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Tue, 30 Sep 2003 12:37:45 -0400 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue # 86 -- Add IPv6 mobility header message type as selector Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a description and proposed approach for: IPsec Issue #: 86 Title: Add IPv6 mobility header message type as selector Description: ============ On 7/11/03, Francis Dupont posted a message to the ipsec-policy working group in which he, among other things, asked that we add the IPv6 mobility header message type (MH Type) as a selector. (For details, see http://ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-24.txt). Should we add the IPv6 mobility header message type (MH Type) as a selector? Proposed approach: ================== Modify 2401bis along the following lines: 1. Change "upper layer protocol" to "next layer protocol". (We made this change to AH and ESP previously.) 2. Add the mobility header as another possible "next layer" protocol 3. Add mobility header type (MH Type) to the list of selectors supported in the SPD and in IKEv2. 4. The processing text stays the same. Thank you, Karen From owner-ipsec@lists.tislabs.com Tue Sep 30 10:33:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UHXZKP078540; Tue, 30 Sep 2003 10:33:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21920 Tue, 30 Sep 2003 12:47:06 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 30 Sep 2003 12:58:53 -0400 To: Tylor Allison From: Karen Seo Subject: Re: 2401bis Issue # 76 -- More explanation re: ESPv3 TFC padding & dummy packets Cc: ipsec mailingList , , , "Angelos D. Keromytis" , , kseo@bbn.com Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA21917 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tylor, Quoting some earlier text from Steve K.... "Dummy packets can be inserted at random intervals to mask the absence of actual traffic. One can also "shape" the actual traffic to match some distribution to which dummy traffic is added as dictated by the distribution parameters. As with the packet length padding facility for TFS, the most secure approach would be to generate dummy packets at whatever rate is needed to maintain a constant rate on an SA. If packets are all the same size, then the SA presents the appearance of a constant bit rate data stream, analogous to what a link crypto would offer at layer 1/2. However, this is unlikely to be practical in many contexts, e.g., when there are multiple SAs active, because it would imply reducing the allowed bandwidth for a site, based on the number of SAs, and that would undermine the benefits of packet switching. How dummy packet insertion is handled SHOULD not be an implementation decision, however, but rather a parameter under control of the local administration." We could amend the last sentence of the proposed text as follows "For example, the controls might allow an administrator to generate random or fixed length dummy packets, or to pad real packets to random or fixed lengths, or to control the insertion timing of the dummy packets." Would that address your concerns? Thank you, Karen >On Thu, 25 Sep 2003, Karen Seo wrote: > >> Folks, >> >> Here's a description and proposed approach for: >> >> IPsec Issue #: 76 >> >> Title: More explanation re: ESPv3 TFC padding & dummy packets >> >> Description: >> ============ >> Questions have been raised re: how much padding one should add and >> re: generation and discarding of dummy packets. Should we add text >> explaining more about these topics? >> >> >> Proposed approach: >> ================== >> 2401bis will be modified with text along the lines of: >> >> "ESPv3 provides a facility to allow an arbitrary amount of padding to >> be appended to a packet, for traffic flow confidentiality, as well as >> a facility for efficient generation and discarding of "dummy" >> packets. Implementations SHOULD provide local management controls to >> enable the use of these capabilities on a per SA basis. The controls >> should specify which (if any) TFC features are to be employed, and > > provide parametric controls for the features. For example, the >> controls might allow an administrator to generate random or fixed >> length dummy packets and to pad real packets to random or fixed > > lengths." >> >> Thank you, >> Karen > >What about how often these dummy packets get sent, and the latency between >dummy packets. Should this be a random stream or a fixed bandwidth stream? >Should the dummy data rate be configurable by the administrator? > >-------------------------------------------------------------------------------- >Tylor Allison >Principal Engineer > >Secure Computing® >Protecting the world's most important networks (TM) >www.securecomputing.com >NASDAQ: SCUR > >tylor_allison@securecomputing.com >-------------------------------------------------------------------------------- From owner-ipsec@lists.tislabs.com Tue Sep 30 12:02:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UJ2lKP082780; Tue, 30 Sep 2003 12:02:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA22504 Tue, 30 Sep 2003 14:19:05 -0400 (EDT) Message-ID: <3F79CA1D.4080705@kolumbus.fi> Date: Tue, 30 Sep 2003 21:23:25 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Karen Seo CC: ipsec mailingList , byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi Subject: Re: 2401bis Issue # 86 -- Add IPv6 mobility header message type as selector References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Karen Seo wrote: > Folks, > > Here's a description and proposed approach for: > > IPsec Issue #: 86 > > Title: Add IPv6 mobility header message type as selector > > > Description: > ============ > On 7/11/03, Francis Dupont posted a message to the ipsec-policy working > group in which he, among other things, asked that we add the IPv6 > mobility header message type (MH Type) as a selector. (For details, see > http://ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-24.txt). > > Should we add the IPv6 mobility header message type (MH Type) as a > selector? Yes. Future protection of mobility signaling using IPsec could then benefit from the higher granularity of the selectors and policies. (Question: did you already cover ICMP types in some earlier update?) > Proposed approach: > ================== > Modify 2401bis along the following lines: > > 1. Change "upper layer protocol" to "next layer protocol". (We made this > change to AH and ESP previously.) > 2. Add the mobility header as another possible "next layer" protocol > 3. Add mobility header type (MH Type) to the list of selectors supported > in the SPD and in IKEv2. > 4. The processing text stays the same. Agree. --Jari From owner-ipsec@lists.tislabs.com Tue Sep 30 12:29:53 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UJTqKP084142; Tue, 30 Sep 2003 12:29:53 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA22783 Tue, 30 Sep 2003 14:50:07 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: <3F79CA1D.4080705@kolumbus.fi> References: <3F79CA1D.4080705@kolumbus.fi> Date: Tue, 30 Sep 2003 15:01:45 -0400 To: Jari Arkko From: Karen Seo Subject: Re: 2401bis Issue # 86 -- Add IPv6 mobility header message type as selector Cc: ipsec mailingList , byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" , kivinen@ssh.fi Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jari, See reply below. >Karen Seo wrote: >>Folks, >> >>Here's a description and proposed approach for: >> >>IPsec Issue #: 86 >> >>Title: Add IPv6 mobility header message type as selector >> >> >>Description: >>============ >>On 7/11/03, Francis Dupont posted a message to the ipsec-policy >>working group in which he, among other things, asked that we add >>the IPv6 mobility header message type (MH Type) as a selector. (For >>details, see >>http://ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-24.txt). >> >>Should we add the IPv6 mobility header message type (MH Type) as a selector? > >Yes. Future protection of mobility signaling using IPsec could >then benefit from the higher granularity of the selectors and >policies. Sounds good. >(Question: did you already cover ICMP types in some earlier >update?) Only the PMTU discovery aspect has been written up so far (plus the 3 cases of dropped packets where we proposed sending an ICMP unreachable.) We have done a couple of passes on writing up the ICMP issues, but I haven't yet completed the next revision. I'm probably going to need to wait for Steve's input before it will be ready to send out, so it might not go out until after 10/13. But there will definitely be a 2401bis writeup on this topic. > >>Proposed approach: >>================== >>Modify 2401bis along the following lines: >> >>1. Change "upper layer protocol" to "next layer protocol". (We made >>this change to AH and ESP previously.) >>2. Add the mobility header as another possible "next layer" protocol >>3. Add mobility header type (MH Type) to the list of selectors >>supported in the SPD and in IKEv2. >>4. The processing text stays the same. > >Agree. Thank you. Karen From owner-ipsec@lists.tislabs.com Tue Sep 30 14:27:02 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8ULR1KP089315; Tue, 30 Sep 2003 14:27:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA23505 Tue, 30 Sep 2003 16:42:50 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16249.60544.699962.270549@ryijy.hel.fi.ssh.com> Date: Tue, 30 Sep 2003 23:50:08 +0300 From: Tero Kivinen To: Jari Arkko Cc: Karen Seo , ipsec mailingList , byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" Subject: Re: 2401bis Issue # 86 -- Add IPv6 mobility header message type as selector In-Reply-To: <3F79CA1D.4080705@kolumbus.fi> References: <3F79CA1D.4080705@kolumbus.fi> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 0 min X-Total-Time: 1 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jari Arkko writes: > (Question: did you already cover ICMP types in some earlier > update?) IKEv2 already includes them: ---------------------------------------------------------------------- 3.13.1 Traffic Selector ... o Protocol ID (1 octet) - Value specifying an associated IP protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that ... o Start_Port (2 octets) - Value specifying the smallest port number allowed by this Traffic Selector. For protocols for which port is undefined, or if all ports are allowed by this Traffic Selector, this field MUST be zero. For the ICMP protocol, the two one octet fields Type and Code are treated as a single 16 bit integer port number for the purposes of filtering based on this field. o End_Port (2 octets) - Value specifying the largest port number allowed by this Traffic Selector. For protocols for which port is undefined, or if all ports are allowed by this Traffic Selector, this field MUST be 65535. For the ICMP protocol, the two one octet fields Type and Code are treated as a single 16 bit integer port number for the purposed of filtering based on this field. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Sep 30 15:32:42 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UMWfKP091760; Tue, 30 Sep 2003 15:32:42 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA23780 Tue, 30 Sep 2003 17:47:35 -0400 (EDT) Date: Tue, 30 Sep 2003 14:56:15 -0700 (PDT) From: Scott Fluhrer To: Tero Kivinen cc: Jari Arkko , Karen Seo , ipsec mailingList , byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" Subject: Re: 2401bis Issue # 86 -- Add IPv6 mobility header message type as selector In-Reply-To: <16249.60544.699962.270549@ryijy.hel.fi.ssh.com> Message-ID: References: <3F79CA1D.4080705@kolumbus.fi> <16249.60544.699962.270549@ryijy.hel.fi.ssh.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 30 Sep 2003, Tero Kivinen wrote: > Jari Arkko writes: > > (Question: did you already cover ICMP types in some earlier > > update?) > > IKEv2 already includes them: > ---------------------------------------------------------------------- > 3.13.1 Traffic Selector > ... > o Protocol ID (1 octet) - Value specifying an associated IP > protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that > ... > o Start_Port (2 octets) - Value specifying the smallest port > number allowed by this Traffic Selector. For protocols for > which port is undefined, or if all ports are allowed by > this Traffic Selector, this field MUST be zero. For the > ICMP protocol, the two one octet fields Type and Code are > treated as a single 16 bit integer port number for the > purposes of filtering based on this field. > > o End_Port (2 octets) - Value specifying the largest port > number allowed by this Traffic Selector. For protocols for > which port is undefined, or if all ports are allowed by > this Traffic Selector, this field MUST be 65535. For the > ICMP protocol, the two one octet fields Type and Code are > treated as a single 16 bit integer port number for the > purposed of filtering based on this field. You probably should specify if the Type or the Code is the most significant octet of the 16 bit integer. -- scott From owner-ipsec@lists.tislabs.com Tue Sep 30 21:49:24 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h914nJKP004934; Tue, 30 Sep 2003 21:49:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA26234 Tue, 30 Sep 2003 23:59:39 -0400 (EDT) Message-Id: <3.0.5.32.20030930211101.008531f0@pop.mindspring.com> X-Sender: tardo@pop.mindspring.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 30 Sep 2003 21:11:01 -0700 To: Karen Seo , ipsec mailingList From: "Joseph J. Tardo" Subject: Re: 2401bis Issue # 85 -- DROP'd inbound packet -- does not match SA In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This ICMP message MUST be sent encrypted using the reverse direction SA (or similar appropriate terminology) and MUST NOT be sent in the clear. At 01:49 AM 9/30/03 -0400, Karen Seo wrote: >Folks, > >Here's a description and proposed approach for: > >IPsec Issue #: 85 > >Title: DROP'd inbound packet -- does not match SA > >Description >=========== >Should there be a defined ICMP response to be used when an IPsec >implementation drops an inbound, IPsec-protected packet, whose >selectors do not match those of the SA on which it was delivered? >The intent is to indicate to the sender that the receiver dropped the >packet. > >Proposed approach >================= >Add text saying something along the lines of... > >"If an IPsec system receives an inbound packet whose selectors do not >match those of the SA on which it was delivered, it MUST drop the >packet. It SHOULD also be capable of generating and sending an ICMP >message to indicate to the sender (the IPsec encapsulator) that the >packet has been dropped by the receiver. The reason SHOULD be >recorded in the audit log. > >IPv4 Type = 3 (destination unreachable) > Code = 13 (Communication Administratively > Prohibited) > >IPv6 Type = 1 (destination unreachable) > Code = 1 (Communication with destination > administratively prohibited > >"The implementation SHOULD provide management controls to allow an >administrator to configure an IPsec implementation to send or not >send the above ICMP message, or to rate limit the transmission of >such ICMP responses." > >Thank you, >Karen > >