From owner-ipsec@lists.tislabs.com Sun Feb 1 01:57:07 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i119v65N009741; Sun, 1 Feb 2004 01:57:06 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA08002 Sun, 1 Feb 2004 04:10:52 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Issue #76: TFC padding in ESPv3 and requirments for IKEv2 From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Sat, 31 Jan 2004 23:58:56 -0500 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 While looking over the remaining issues still open on RFC 2401bis, Barbara and I were looking at issue #76, to make sure it was fully addressed. Per the discussion on the mailing list, this issue was transferred to the ESP v3 document. So when I went to double check to make sure the text was properly reflected in ESPv3, I found the following text: TFC padding takes advantage of an intrinsic feature of IP, i.e., other data may be present in a buffer delivered to an IP interface, beyond the packet length indicated by the IP total length field. Thus, in tunnel mode, a compliant IP stack at a receiver should ignore this padding. In this sense, existing IPsec implementations could have made use of this capability previously, in a transparent fashion. However, because receivers may not have been prepared to deal with this padding, the SA management protocol MUST negotiate this service prior to a transmitter employing it, to ensure backward compatibility. Combined with the convention described in section 2.6 above, about the use of protocol ID 59, an ESP implementation is capable of generating dummy and real packets that exhibit much greater length variability, in support of TFC. There's only one minor problem. IKEv2 doesn't currently have a way of negotiating this capability, and the ESPv3 specification states that the SA management protocol MUST negotiate this facility. This leaves us with a couple of possibilities: 1) We go ahead with the documents ESPv3 and IKEv2 as they currently stand, which would mean that TFC padding cannot be used until somoene writes a quick RFC which defines a new notification message: ESP_TFC_PADDING_SUPPORTED 16394 This notification asserts that the sending endpoint will accept packets that contain Flow Confidetiality (TFC) padding. 2) We modify IKEv2 to include this new notification message now. 3) We modify ESPv3 to indicate that the mere use of IKEv2 implies that the receiver can accept ESP packets that contain RFC padding. What do folks think? - Ted From owner-ipsec@lists.tislabs.com Sun Feb 1 14:23:20 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i11MNJJL061911; Sun, 1 Feb 2004 14:23:20 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29236 Sun, 1 Feb 2004 16:35:46 -0500 (EST) To: Bodo Moeller Cc: ipsec@lists.tislabs.com, ietf-tls@lists.certicom.com Subject: Re: Datagram TLS References: <20040130170427.D34967224@sierra.rtfm.com> <20040131065319.GA4642@tau.local> <20040201104054.GA12472@tau.local> Reply-To: EKR From: Eric Rescorla Date: 01 Feb 2004 13:46:40 -0800 In-Reply-To: <20040201104054.GA12472@tau.local> Message-ID: Lines: 64 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Reasonable Discussion) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bodo Moeller writes: > On Sat, Jan 31, 2004 at 09:38:04AM -0800, Eric Rescorla wrote: > > Bodo Moeller writes: > > [...] > >> Section 4.2.3 of the DTLS Internet Draft essentially describes how > >> long handshake messages can be fragmented into multiple shorter > >> handshake messages. However, I haven't seen language in the draft > >> actually saying that messages must not be otherwise fragmented into > >> multiple records, which is perfectly legal in TLS (a 97-byte > >> ClientHello message could be sent in 97 records carrying one handshake > >> protocol byte each, for example). Obviously you don't want this to > >> be done in DTLS, but the draft does not appear to forbid it. > > > Well, I think this is bad practice, but I'm not sure we want to > > forbid this. > > If you don't forbid it, I don't see a need to add fragmentation on the > handshake protocol level -- recipients would have to be able to perform > reassambly of Handshake data structures that are spread over multiple > records anyway. Reassembly is simpler with the fragment_offset > provided by your higher-level fragmentation mechanism, but > implementations don't really profit from this if fragmentation could > actually happen at either level. Ah. Good point--and that reassembly isn't deterministic. We'll arrange to forbid it. > By the way, section 4.1.1 (transport layer mapping) is not entirely > clear. Unless your intention is that each datagram should contain > only a single DTLS record (which should be clarified in the Internet > Draft if this is the case), I suggest changing > > Each DTLS record MUST fit within a single datagram. In order to avoid > IP fragmentation [MOGUL], DTLS implementations SHOULD determine the > MTU and send records smaller than the MTU. [...] > > into > > Each DTLS record MUST fit within a single datagram, and DLTS record > boundaries MUST observe datagram boundaries. If lengths permit, multiple > DTLS records can be concatenated (in order) and sent within a > single datagram. In order to avoid IP fragmentation [MOGUL], DTLS > implementations SHOULD determine the MTU and send datagrams smaller > than the MTU. [...] > > or something along those lines. (Record concatenation is useful > when data from multiple message types is sent at the same time, > such as ClientKeyExchange, ChangeCipherSpec, and Finished.) Agreed. Good point. > Right, I don't really fancy adding a new alert either, I just wanted > to describe an option that *might* have some value. If no one wants > to have it, than I'm entirely comfortable without this kind of > "non-alert". (Other new alerts that I can think of but that I don't > really want are alerts for indicating high record loss, i.e. > holes in the list of sequence numbers received in valid records.) In the spirit of adding as few things as possible, I think I'd rather hold off on these for now until we we have some application that clearly needs it. Thanks, -Ekr From owner-ipsec@lists.tislabs.com Mon Feb 2 04:55:02 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12Ct26x000510; Mon, 2 Feb 2004 04:55:02 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA25803 Mon, 2 Feb 2004 06:49:38 -0500 (EST) Date: Mon, 2 Feb 2004 12:14:27 +0100 From: Jean-Jacques Puig To: ipsec@lists.tislabs.com Subject: Re: Issue #76: TFC padding in ESPv3 and requirments for IKEv2 Message-ID: <20040202111427.GA13143@ivan.int-evry.fr> Mail-Followup-To: ipsec@lists.tislabs.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, Jan 31, 2004 at 11:58:56PM -0500, Theodore Ts'o wrote: > > ... in ESPv3, I found the > following text: > > TFC padding takes advantage of an intrinsic feature of IP, i.e., > other data may be present in a buffer delivered to an IP interface, > beyond the packet length indicated by the IP total length field. > Thus, in tunnel mode, a compliant IP stack at a receiver should > ignore this padding. In this sense, existing IPsec implementations > could have made use of this capability previously, in a transparent > fashion. However, because receivers may not have been prepared to > deal with this padding, the SA management protocol MUST negotiate > this service prior to a transmitter employing it, to ensure backward > compatibility. Combined with the convention described in section 2.6 > above, about the use of protocol ID 59, an ESP implementation is > capable of generating dummy and real packets that exhibit much > greater length variability, in support of TFC. > > There's only one minor problem. IKEv2 doesn't currently have a way of > negotiating this capability, and the ESPv3 specification states that the > SA management protocol MUST negotiate this facility. This leaves us > with a couple of possibilities: > > 1) We go ahead with the documents ESPv3 and IKEv2 as they currently > stand, which would mean that TFC padding cannot be used until somoene > writes a quick RFC which defines a new notification message: > > ESP_TFC_PADDING_SUPPORTED 16394 > > This notification asserts that the sending endpoint will > accept packets that contain Flow Confidetiality (TFC) > padding. > > 2) We modify IKEv2 to include this new notification message now. Either ways are correct, however I think 2) is the most reasonable solution, given documents involved are still IDs. I'd rather see some more lines in IKEv2 than an almost empty RFC. > > 3) We modify ESPv3 to indicate that the mere use of IKEv2 implies that > the receiver can accept ESP packets that contain RFC padding. ^- Nice lapsus :) I don't see 3) as an alternative to specifying the notification message somewhere; do you mean that the requirement for the SA-MP to negotiate TFC should be eased for IKEv2 ? I think this should always be negotiated, not only because of backward compatibility, but also because of possible performance issues wrt link capacity and host memory: one should be able to tell it's peer it can not live easily with padded or dummy packets. -- Jean-Jacques Puig [homepage] http://www-lor.int-evry.fr/~puig/ From owner-ipsec@lists.tislabs.com Mon Feb 2 09:14:03 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12HE2JN022767; Mon, 2 Feb 2004 09:14:03 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14219 Mon, 2 Feb 2004 11:03:25 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 2 Feb 2004 09:49:10 -0500 To: "Theodore Ts'o" From: Stephen Kent Subject: Re: Issue #76: TFC padding in ESPv3 and requirments for IKEv2 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 Ted, When I last spoke with Russ, he indicated that he was prepared to tolerate another delay on the IKE v2 document to incorporate the change that Hugo suggested, to incorporate bits from an key-based EAP method into the PRF for the keys used for encryption & integrity. IF he still feels this way, then I'd suggest suggestion #2, i.e., modify IKE now to add the necessary notification message. Steve From owner-ipsec@lists.tislabs.com Mon Feb 2 09:22:18 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12HMHoZ024041; Mon, 2 Feb 2004 09:22:17 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14220 Mon, 2 Feb 2004 11:03:26 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <20040130232243.GA6423@thunk.org> References: <20040130232243.GA6423@thunk.org> Date: Mon, 2 Feb 2004 09:42:00 -0500 To: "Theodore Ts'o" From: Stephen Kent Subject: Re: Issue #83: Generation of ICMP responses for inbound packet requiring IPSEC protection 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 18:22 -0500 1/30/04, Theodore Ts'o wrote: >On Wed, Jan 28, 2004 at 05:56:30PM -0500, Stephen Kent wrote: >> Ted, >> >> Issue #83 said: >> >> >> Title: DROP'd inbound packet -- missing required >>IPsec protection > >Um... that's interesting. That's not what Karen had posted on >September 30th, nor what is currently in the roundup database here: > > https://roundup.machshav.com/ipsec/issue83 you are right Ted, the proposed text that Karen submitted is not consistent with what I said we have put in 2401bis. That's because I revisited the issue and realized that the it was more or less ill formed and ought not have been raised in the first place (by us). >Was this proposed disposition of the issue (which you quoted below) >ever discussed on the mailing list? no, I just put in in the text during the last editing pass. >My search of the mailing list didn't discover much discussion >surrounding this issue, save Barbara's call for a working group last >call for the text as was stated in the Roundup issue tracker. > >If it turns out that the proposed approach originally proposed in >Karen's e-mail of September 30th, and currently documented in the >roundup database is not right, we can certainly have that discussion >on the mailing list. My impression was that nobody said anything about this issue the list. we (BBN) had put on the list, and in retrospect, it should not have even been on the issue list in the first place, for the reasons cited below. >Would anyone on the mailing list like to comment? > > - Ted > >> >> 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? >> >> There is no text in 2401bis for this because it seems generally >> impractical, at least as stated here. It would require searching the >> SPD for each inbound packet to see if the packet matches an SPD entry >> that calls for application of IPsec. As stated above, this would be >> done even for packets that already map to a valid bypass SA! The SPD >> admin has a responsibility to create entries that do not conflict in >> this fashion. A vendor might choose to provide a facility to examine >> an SPD and warn a user about such conflicts, but it makes more sense >> to do so when the SPD is being managed, than when traffic arrives. >> >> If one restricted this to encompass only inbound packets that will be >> discarded, then we may still incur a non-trivial search penalty, and >> we allow an attacker to probe the implementation to determine SPD >> entries for IPsec-protected traffic, which hardly seems to be a good >> idea, in general. So, while we agree that there would be some benefit >> to notifying a peer when traffic is sent unprotected, when the >> traffic should have been protected, it seems to be a costly feature >> to implement and thus ought not be imposed as a requirement. >> >> Steve From owner-ipsec@lists.tislabs.com Mon Feb 2 09:48:35 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12HmY0U026480; Mon, 2 Feb 2004 09:48:34 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18041 Mon, 2 Feb 2004 11:54:21 -0500 (EST) From: Charles Lynn To: ipsec@lists.tislabs.com Cc: Charlie Kaufman , CLynn@bbn.com Subject: IKEv2 changes (was Re: Issue #76: TFC padding in ESPv3 and requirments for IKEv2) In-Reply-To: Message-Id: <20040202170520.40BDF20520@wolfe.bbn.com> Date: Mon, 2 Feb 2004 12:05:20 -0500 (EST) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > When I last spoke with Russ, he indicated that he was prepared to > tolerate another delay on the IKE v2 document to incorporate ... > IF he still feels this way, then ... There are a few other items, most of which have been mentioned at one time or another, that I think need to be incorporated into the IKEv2 doc. Please add text saying how the ICMP Type and Code are encoded into the 16-bit "port" field -- Type in the the most significant 8 bits and Code in the least significant 8 bits; and text saying that the Mobility Header Type should be in the most significant 8 bits and the least significant 8 bits should be 0 for the "start" field of the range and 255 for the "end" field). Please add text saying that OPAQUE is encoded by setting a "start" field to the maximum value and the "end" field to the minimum value. I think that there should be text describing how unidirectional policies should be encoded in the current syntax. The immediate examples are ICMP and the Mobility Header. I would suggest saying that the ICMP sender's end should specify the Type and Code in the "initiator's" traffic selectors, and that they should be "OPAGUE" in the "responder's". I think that the 2401bis model is for non-initial fragments to be placed into a "fragment-only" SA. If so, please add text to IKEv2 saying that IPv4 non-initial fragments should be mapped to protocol 44 (IPv6 Fragmentation Header). If we will be supporting SAs for non-initial fragments at the level of protocol, e.g., TCP fragments get a different SA than UDP fragments, then the fragmentation "protocol" would need to have "ports" that is the value of the IPv4 protocol field or IPv6 Fragmentation Header's Next Header field. The 8-bit protcol number should be encoded right justivfied in the port field (i.e., the most significant 8 bits should be zero). If the WG thinks that this is reasonable, then the IKEv2 and/or 2401bis should describe it. Charlie From owner-ipsec@lists.tislabs.com Mon Feb 2 10:00:16 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12I0F5j028273; Mon, 2 Feb 2004 10:00:15 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19351 Mon, 2 Feb 2004 12:09:00 -0500 (EST) From: Charles Lynn To: ipsec@lists.tislabs.com Cc: ravivsn@roc.co.in, CLynn@bbn.com Subject: Re: an SPD syntax example In-Reply-To: <64242.24.4.96.151.1074749112.squirrel@mail.roc.co.in> References: <20040202170520.40BDF20520@wolfe.bbn.com> Message-Id: <20040202171959.5B43520520@wolfe.bbn.com> Date: Mon, 2 Feb 2004 12:19:59 -0500 (EST) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Catching up... A few comments on the ongoing SPD syntax discussion, IKE, and 2401bis. >It is better to make this as close to IKEv2 Traffic Selector as >possible. I disagree :-) ... on the grounds that clarity and simplicity for the administrators promote better security. I think that the syntax should be designed to encourage a clear and concise specification of the types of traffic that should be protected. We should not be using a syntax that lets an administrator enter information that is non-sensical or inappropriate, as much as possible. The "software" can translate that format into whatever the key management protocol(s) use internally; the programmer only has to get the translation right once, the admin would have to do it for each SelectorSet. As an example, the IKEv2 syntax (which is an improvement over IKEv1, and which I do not think needs to be changed -- but does need to be "clarified") allows one protocol to be specified in the initiator traffic selectors and a totally different one to be specified in the responder traffic selectors -- something that is clearly wrong. So I would suggest that the SelectorSet syntax specify local and remote addresses, which can be a list of single addresses, prefixes (subnets), or ranges; a protocol or list of protocols; and for each protocol any additional information -- ports (a list of single values or ranges), ICMP Type and Code (a list of Types and for each Type a list of Codes or ranges of Codes), MH Type or ranges of Types, etc. The translator gets to do the cross-product when translating to the IKEv2 format, the admin does not have to do it; keeping the policy the the admin has to look at smaller - an entry can be seen all at once - makes things clearer, and more apt to express the admin's intent. There also seems to be possible confusion with the terms "source"/ "destination", "initiator"/"responder", etc. The first pair is tied to packets, the second to roles or the peers in the IKE. One might interpret the latter pair to imply restrictions on which end can "initiate" a TCP connection (the SYN without ACK) semantic. Are we saying that there should be one SPD entry to protect TCP connections that A initiates to B and a second one for traffic that B initiates to A? Note that this is distinction is muddied by the fact that most current TCP applications use well-known ports in a client-server model; specification of ports is currently overloaded with directionality. TCP is really peer-to-peer; it would be unfortunate, in my opinion, if the IKE syntax were to encourage administrators to block emerging services because they cannot specify the policy that they want. It is the old chicken and egg problem -- new apps cannot be deployed because of artificial limitations elsewhere, and since they cannot be deployed, there is no "user demand" for them. I would suggest using "local"/"remote" or some such terms. The current syntax does not really bind "sourceAddr" or "destAddr" to "inbound" or "outbound". Example: could "insiders" circumvent an admin's policy by initiating a TCP connection *from* port 20 *to* a remote port 4567 (many folks are "admins" on their desktop systems)? I think that removing the "inbound" and "outbound" tags for two-way flows opens up this hole. As I just mentioned in my message "IKEv2 changes", I think that there should be text describing how unidirectional policies should be encoded in the current syntax. I would suggest saying that the ICMP sender's end should specify the Type and Code in the "initiator's" traffic selectors, and that they should be "OPAGUE" in the "responder's". It should be part of the ASN.1 syntax for ICMP Type and Code, and Mobility Header Type. I would add ANY and OPAQUE to the 2401bis syntax as CHOICEs. 2401bis is the architecture document, intended for administrators as well as implementors, so I think adding text that exemplifies things of interest to the admins is beneficial. (Please respond re: ASN.1 being easy for folks to understand to /dev/null :-) The standard conformance test is any implementation that exhibits the external behavior, so there is no requirement that an implementation have a one-for-one mapping. I would make protocol a list, as that is how admins think of it; again, let the software do the cross-products, not the admin. > Note, that in most cases the code 0 is reserved, > thus it cannot be used as special ANY value. Actually, it is the cases where it is not "reserverd" that cause the problem, i.e., protocol 0 is the Hop-by-Hop extension header. If one defines ANY as a *range* whose "start" value is 0 and whose "end" value is 2^^n-1, then the range 0..0 should be distinguishable from ANY. Protocol is the problem, as IKEv2 does not allow it to be a range. I can see wanting to indicate fragments for any protocol, but then the Fragment Header is the "protocol" and ANY would be the protocol specific additional information (aka IKEv2 ports) which allows a range. That still leaves how to express the policy "all traffic between A and B". One could use the (currently) reserved value of 255, or request that IANA assign a value to get around IKEv2's syntactical limitation. Note that protocol 61 is assigned to any host internal protocol, which should never (FLW) be sent between hosts, so it might be possible to overload it. Re: combinatorial explosion: > I don't recall the example in detail, but it seems unlikely that, in > practice. one would need to send such a big TS payload. The conclusion seems to be saying that the admin can work around the problem by creating multiple SAs that protect subsets of the desired traffic. If a policy is to be applied to many types of traffic, having to use multiple policies, which as currently defined, implies multiple SAs, does not seem like a good idea from the policy management perspective. Then there is TFC - using multiple SAs instead of one decreases the level of TFC that one can achieve. Comments? Charlie From owner-ipsec@lists.tislabs.com Mon Feb 2 12:22:40 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12KMd2Q039118; Mon, 2 Feb 2004 12:22:40 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28282 Mon, 2 Feb 2004 14:11:53 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <20040202171959.5B43520520@wolfe.bbn.com> References: <20040202170520.40BDF20520@wolfe.bbn.com> <20040202171959.5B43520520@wolfe.bbn.com> Date: Mon, 2 Feb 2004 14:22:10 -0500 To: Charles Lynn From: Stephen Kent Subject: Re: an SPD syntax example 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 12:19 -0500 2/2/04, Charles Lynn wrote: >Catching up... >A few comments on the ongoing SPD syntax discussion, IKE, and 2401bis. > >>It is better to make this as close to IKEv2 Traffic Selector as >>possible. > >I disagree :-) ... on the grounds that clarity and simplicity for the >administrators promote better security. Good point; clarity is better, so long as it is easily mapped to IKEv2 TS payloads. >I think that the syntax should be designed to encourage a clear and >concise specification of the types of traffic that should be protected. >We should not be using a syntax that lets an administrator enter >information that is non-sensical or inappropriate, as much as possible. >The "software" can translate that format into whatever the key management >protocol(s) use internally; the programmer only has to get the translation >right once, the admin would have to do it for each SelectorSet. yes, but let's keep the translation easy, or it will be done improperly. >As an example, the IKEv2 syntax (which is an improvement over IKEv1, >and which I do not think needs to be changed -- but does need to be >"clarified") allows one protocol to be specified in the initiator >traffic selectors and a totally different one to be specified in the >responder traffic selectors -- something that is clearly wrong. agreed. good example. Firewalls distinguish between connection initiators and responders, but that may not be critical here, since that we have authentication for SA establishment, and integrity mechanism for continuous protection after SA establishment. So, for SAs the asymmetry may not be an issue. Note that the current syntax I suggested does retain inbound vs. outbound distinctions for non-IPsec traffic, where we lack the protections noted above. Let me suggest that you prepare an ASN.1 syntax example that meets the criteria you described in your message and bring it to the list, along with the explanation of how to map it to IKE TS payloads. We can work from there. Steve From owner-ipsec@lists.tislabs.com Mon Feb 2 19:58:54 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i133wrC2066450; Mon, 2 Feb 2004 19:58:54 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA19638 Mon, 2 Feb 2004 21:42:54 -0500 (EST) Message-ID: <62173B970AE0A044AED8723C3BCF23810408B1FE@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: ipsec@lists.tislabs.com Cc: "'Michael Richardson'" Subject: RE: IANA document Date: Mon, 2 Feb 2004 10:31:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (1) ??? In some sense the IETF has ENORMOUS experience with Expert Review. That was the policy for essentially all parameters before the death of Jon Postel. He was the sole Expert. An expert is expected to be familiar with the protocol and the protocol parameter space situation and would apply increasingly stringent criteria as the space gets exhausted. (2) I can't understand why there are argument about "Specification Required" as defined in RFC 2434. It says Specification Required - Values and their meaning must be documented in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible. Which is clearly NOT restricted to RFCs. A public domain and widely distributed document from some company describing their privately developed foo option would quality. Donald =========================================================== Donald E. Eastlake III Donald.Eastlake@Motorola.com Motorola Laboratories 1-508-786-7554 (work) 111 Locke Drive 1-508-634-2066 (home) Marlboro, MA 01752 USA -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Michael Richardson Sent: Friday, January 30, 2004 9:45 PM To: ipsec@lists.tislabs.com Subject: Re: IANA document >>>>> "Theodore" == Theodore Ts'o writes: Theodore> My understanding was that an Expert represented a much higher Theodore> bar, because human is in the loop. My assumption was that an Theodore> Expert would Specification Required involves the RFC-editor, or possibly another peer-reviewed journal. I think that this is a much higher bar. The only category that is mechanical would be First-Come/First-Served. I don't think that that IETF has a lot of experience with expert review yet. And, while the expert may ask to see a specification, (not necessary though), the specification may be proprietary, require NDA, specific-national security clearance, etc. So, expert review does not, in my opinion, mean that we get any specifications to look at. It just avoids silly stuff. Theodore> Actually, anything permanent will qualify. So any crackpot Theodore> idea in a raduate student's thesis, or a Technical Report Theodore> published by a lab might be enough to get a number assigned. I don't read 2434 as saying that it is that wide open. You may be correct though. Theodore> publishes a single paper that consumes half a dozen or more Theodore> payload id's. Presumably that would be a case where an human Theodore> expert would hopefully say, hey now, wait a moment! True. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Tue Feb 3 08:10:39 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13GAcDc091550; Tue, 3 Feb 2004 08:10:39 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05108 Tue, 3 Feb 2004 09:53:09 -0500 (EST) To: ipsec@lists.tislabs.com Subject: IANA document Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 03 Feb 2004 09:57:37 -0500 Message-ID: <5837.1075820257@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I think that the consensus of the WG list is that all values should be a consistent "Expert Review". Please disagree. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQB+24IqHRg3pndX9AQHUSgQAiWW1rzBz+hbx1863QTcM6O9GXiSEjY8c 9rfUSN8WzqMR7MLSylMfuOwH2mT4KQhY7O99oVyW6uNqrhtHcxoOgM0WOJB1ZpSD uCGGIGLt7BX33b5VmMwYG7QZ6Z2OJYqUSDx3Qtqq/cDFD267WnHkIkolUMsKSkOC ep/lZ5UAIvo= =vcmG -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Feb 3 11:40:44 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13JehfQ006702; Tue, 3 Feb 2004 11:40:43 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18722 Tue, 3 Feb 2004 13:42:40 -0500 (EST) Message-ID: <20040203105329.87307.qmail@web21510.mail.yahoo.com> Date: Tue, 3 Feb 2004 05:53:29 -0500 (EST) From: Andrew Krywaniuk Subject: Re: SPD Syntax Example To: Stephen Kent Cc: ipsec@lists.tislabs.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > We have differing views of what is open for debate > now. what we are > doing is providing a more flexible capability re > defining what > traffic is mapped to a given SA, something that was > clearly agreed > upon when we decided, as a WG, to add the current > set of traffic > selector negotiation features to IKE v2. I'm not sure that the WG clearly decided on anything. At the point when we were revising IKEv2, the revision to 2401 hadn't been announced yet and we were working under the assumption that we had to be backwards compatible with the old model. > maybe we just have different views of what > interperability means. I > don't think interop is achieved if one peer sends > traffic that the > other peer drops, without any advance notice. That is, after all, the way the whole rest of the Internet works. > a > major goal of the > traffic selector negotiation is to determine in > advance whether > communication will be allowed for proposed traffic > flows. that has > always been the case. we are not changing it in > 2401bis. But that's not what it does, really. What is actually allowed is generally decided at the firewall level, and it can vary based on a variety of factors such as dynamic ports or stateful inspection. > Between IKE v2 and 2401bis we hope to provide a much > better > description of how to match traffic selector > payload, and offered > traffic, against SPD entries. It's always nice to have a better description of the model, but it's still the wrong model. > >And then what happens when B needs to send a packet > >that matches B's selectors from B's policy for A's > >original packet, but not A's selectors from A's > >policy. And then what happens when it comes time > for A > >to rekey? > > I believe a goal of IKE v2 is to better allow A and > B to determine > where the policies overlap, to reduce the likelihood > of the sort of > potential problems you cite, which not requiring > exact matches > between the SPD entries for A & B. The problem is that the SPDs of A & B may have different and incompatible ways to describe local policies which include a shared policy P. If you have to negotiate policies, the behaviour of the system is not necessarily predictable and the results may vary based on something as subtle as which packet triggers the initial negotiation. That's not the most robust way to define a protocol. Andrew ===== Andrew Krywaniuk, Fortinet Technologies Please *do not* reply to this address. (I will not read it) Reply to askrywan..hotmail..com or my home address. ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From owner-ipsec@lists.tislabs.com Tue Feb 3 13:31:37 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13LVafr013274; Tue, 3 Feb 2004 13:31:37 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA24383 Tue, 3 Feb 2004 15:17:37 -0500 (EST) Message-ID: <4020041C.8070509@airespace.com> Date: Tue, 03 Feb 2004 12:27:08 -0800 From: "Scott G. Kelly" Organization: Airespace User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Richardson CC: ipsec@lists.tislabs.com Subject: Re: IANA document References: <5837.1075820257@marajade.sandelman.ottawa.on.ca> In-Reply-To: <5837.1075820257@marajade.sandelman.ottawa.on.ca> X-Enigmail-Version: 0.76.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Feb 2004 20:29:51.0131 (UTC) FILETIME=[7984C6B0:01C3EA94] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson wrote: > > I think that the consensus of the WG list is that all values should > be a consistent "Expert Review". Please disagree. As you wish :-) This is a difficult question, but given that the IETF is a political organization, effectively concentrating this power in one individual seems inappropriate. Personally, I liked the summary of allocation policies you first suggested, and thought your rationale was well founded. I think Jari raised some reasonable questions, but I don't think a case was made for giving the whole kit and kaboodle over to a benevolent dictator. There is much to be said for public review and consensus. Scott From owner-ipsec@lists.tislabs.com Tue Feb 3 15:13:20 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13NDJOf018875; Tue, 3 Feb 2004 15:13:19 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01072 Tue, 3 Feb 2004 16:50:15 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <4020041C.8070509@airespace.com> References: <5837.1075820257@marajade.sandelman.ottawa.on.ca> <4020041C.8070509@airespace.com> Date: Tue, 3 Feb 2004 14:01:17 -0800 To: "Scott G. Kelly" , Michael Richardson From: Paul Hoffman / VPNC Subject: Re: IANA document Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:27 PM -0800 2/3/04, Scott G. Kelly wrote: >Michael Richardson wrote: >> >>I think that the consensus of the WG list is that all values should >>be a consistent "Expert Review". Please disagree. > >As you wish :-) This is a difficult question, but given that the >IETF is a political organization, effectively concentrating this >power in one individual seems inappropriate. The person is appointed by the IESG. They can be replaced at any time. >Personally, I liked the summary of allocation policies you first >suggested, and thought your rationale was well founded. I think Jari >raised some reasonable questions, but I don't think a case was made >for giving the whole kit and kaboodle over to a benevolent dictator. These are assignments to IANA, not protocol additions. >There is much to be said for public review and consensus. Exactly right. It is quite reasonable for the IPsec community to ask the IESG to make sure that the IKEv2 IANA reviewer does everything in public, and even asks for comments on each action. This is a trivial task (mailing lists and web sites, you know), and would certainly make it so that if the reviewer said "no" to something, people who cared would know immediately to talk to the IESG. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Feb 3 15:16:31 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13NGVl9019016; Tue, 3 Feb 2004 15:16:31 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA02972 Tue, 3 Feb 2004 17:19:47 -0500 (EST) Message-ID: <62173B970AE0A044AED8723C3BCF23810408B215@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: ipsec@lists.tislabs.com Subject: RE: IANA document Date: Tue, 3 Feb 2004 17:26:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Note that since "Experts" are normally appointed by and serve at the pleasure of the the IESG, as a practical matter their decisions, at least negative ones, are effecitvely subject to appeal to the IESG. "Public review and consensus" would be to make everything "IETF Consensus", a ponderous process. It is also good to keep in mind that we are in no way limited to what RFC 2434 says. Those were intended to be examples. Realistic useful examples but just examples nevertheless. We are free to say "RFC required" or "Both Publication AND Expert Review required" or whatever we think appropriate (and the IESG will approve). Donald -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Scott G. Kelly Sent: Tuesday, February 03, 2004 3:27 PM To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: Re: IANA document Michael Richardson wrote: > > I think that the consensus of the WG list is that all values should > be a consistent "Expert Review". Please disagree. As you wish :-) This is a difficult question, but given that the IETF is a political organization, effectively concentrating this power in one individual seems inappropriate. Personally, I liked the summary of allocation policies you first suggested, and thought your rationale was well founded. I think Jari raised some reasonable questions, but I don't think a case was made for giving the whole kit and kaboodle over to a benevolent dictator. There is much to be said for public review and consensus. Scott From owner-ipsec@lists.tislabs.com Tue Feb 3 15:39:18 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i13NdHER019937; Tue, 3 Feb 2004 15:39:18 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA03848 Tue, 3 Feb 2004 17:32:44 -0500 (EST) Message-ID: <402023CA.306@airespace.com> Date: Tue, 03 Feb 2004 14:42:18 -0800 From: "Scott G. Kelly" Organization: Airespace User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / VPNC CC: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: IANA document References: <5837.1075820257@marajade.sandelman.ottawa.on.ca> <4020041C.8070509@airespace.com> In-Reply-To: X-Enigmail-Version: 0.76.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Feb 2004 22:45:01.0022 (UTC) FILETIME=[5B63EFE0:01C3EAA7] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Paul, I guess I'm concerned about two eventualities: (1) the expert, perhaps for personal reasons, treats one person's request differently than another's, or (2) the expert, perhaps due to a personal opinion, refuses to allow something that other "experts" view as a good idea. Do you think there are adequate contingencies in place to prevent either of these? Of course, we all believe that if we were the designated expert, such a thing would never occur. But we are all human, so maybe it could at that. I guess that so long as there is some sort of reliable appeal process for such cases, that addresses my concern to some extent. Scott Paul Hoffman / VPNC wrote: > At 12:27 PM -0800 2/3/04, Scott G. Kelly wrote: > >> Michael Richardson wrote: >> >>> >>> I think that the consensus of the WG list is that all values should >>> be a consistent "Expert Review". Please disagree. >> >> >> As you wish :-) This is a difficult question, but given that the IETF >> is a political organization, effectively concentrating this power in >> one individual seems inappropriate. > > > The person is appointed by the IESG. They can be replaced at any time. > >> Personally, I liked the summary of allocation policies you first >> suggested, and thought your rationale was well founded. I think Jari >> raised some reasonable questions, but I don't think a case was made >> for giving the whole kit and kaboodle over to a benevolent dictator. > > > These are assignments to IANA, not protocol additions. > >> There is much to be said for public review and consensus. > > > Exactly right. It is quite reasonable for the IPsec community to ask the > IESG to make sure that the IKEv2 IANA reviewer does everything in > public, and even asks for comments on each action. This is a trivial > task (mailing lists and web sites, you know), and would certainly make > it so that if the reviewer said "no" to something, people who cared > would know immediately to talk to the IESG. > > --Paul Hoffman, Director > --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Feb 3 16:50:06 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i140o5Uv022993; Tue, 3 Feb 2004 16:50:05 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09029 Tue, 3 Feb 2004 18:43:42 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <402023CA.306@airespace.com> References: <5837.1075820257@marajade.sandelman.ottawa.on.ca> <4020041C.8070509@airespace.com> <402023CA.306@airespace.com> Date: Tue, 3 Feb 2004 15:53:38 -0800 To: "Scott G. Kelly" From: Paul Hoffman / VPNC Subject: Re: IANA document Cc: Michael Richardson , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:42 PM -0800 2/3/04, Scott G. Kelly wrote: >I guess I'm concerned about two eventualities: (1) the expert, >perhaps for personal reasons, treats one person's request >differently than another's, or (2) the expert, perhaps due to a >personal opinion, refuses to allow something that other "experts" >view as a good idea. Both are very valid concerns. > Do you think there are adequate contingencies in place to prevent >either of these? Yes. If the expert does one of the above in a public fashion, people will complain to the IESG and the IESG will either replace the expert, decide they agree with the expert's personal reasons, or decide they don't care. That's why making public all requests that go to the expert and all responses they make to IANA is a Good Thing. >Of course, we all believe that if we were the designated expert, >such a thing would never occur. I don't believe that for a moment. If you were the expert, given your record here on the mailing list, I could imagine some personal reasons for you to reject things. (That "you" is any "you" on this mailing list, including me, of course.) > But we are all human, so maybe it could at that. I guess that so >long as there is some sort of reliable appeal process for such >cases, that addresses my concern to some extent. I wouldn't say that complaining to the IESG is "reliable", but it is certainly available. Further, this mailing list will still exist after the WG shuts down, and complaints sent to the IESG and Cc'd on this mailing list would certainly get the attention of those who feel similarly aggrieved. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Feb 4 06:52:09 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i14Eq8ar056703; Wed, 4 Feb 2004 06:52:08 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA20566 Wed, 4 Feb 2004 08:39:08 -0500 (EST) From: "Yoav Nir" To: "'Eric Rescorla'" , , Subject: RE: Datagram TLS Date: Wed, 4 Feb 2004 15:49:30 +0200 Message-ID: <006e01c3eb25$b6f9d710$292e1dc2@YnirNew> 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20040130170427.D34967224@sierra.rtfm.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Eric. Here's two comments: 1. In section 3.2.1 (Packet Loss), as well as 4.2.4 you state that both client and server should keep a retransmission timer and retransmit when it expires. This raises the question of who retransmits first, the client or the server. This leads to an unpredictable flow, which leads to race conditions for implementations. For the case of the HelloVerifyRequest we have an additional disadvantage in that it requires the gateway to keep a state. I suggest that the client alone retransmits, and the server only replies. After receiving the second ClientHello it should keep enough state to retransmit its previous reply, but it should never retransmit on its own. IMO this makes the protocol flow more predictable and easy to analyze. It does require that all negotiations have an even number of flights, like in IKEv2, and unlike IKEv1. 2. In section 4.2.1 (Denial of Service Countermeasures) it is stated that the technique used by Photuris is used to generate and to verify the stateless cookie in the ClientHello message. I believe that Internet drafts should only mandate things that are necessary for interoperability. In this case, the cookie is generated and verified by the same server. There should be no mandate for the protocol. I suggest that the Photuris technique be mentioned only as a suggestion and that the PHOTURIS document be Informative rather than Normative. That way, if someone creates a stateless cookie technique that's better than Photuris, you won't have to change the draft. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Eric Rescorla Sent: Friday, January 30, 2004 7:04 PM To: ipsec@lists.tislabs.com; ietf-tls@lists.certicom.com Subject: Datagram TLS This seems relevant to these working groups. Although TLS is quite useful as a generic security layer protocol for lots of applications, it is limited by its reliance on datagram transport. It seems like it would be useful to deploy TLS-style security for datagram apps. To this end, Nagendra Modadugu and I have designed a variant on TLS which works properly over datagram transport but is otherwise intended to be as similar to TLS as possible. http://www.ietf.org/internet-drafts/draft-rescorla-dtls-00.txt Comments welcome... -Ekr From owner-ipsec@lists.tislabs.com Wed Feb 4 11:09:46 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i14J9jFB072248; Wed, 4 Feb 2004 11:09:46 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09356 Wed, 4 Feb 2004 12:53:10 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: IANA document In-reply-to: Your message of "Tue, 03 Feb 2004 15:53:38 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 04 Feb 2004 12:48:13 -0500 Message-ID: <8854.1075916893@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "VPNC" == VPNC writes: >> Do you think there are adequate contingencies in place to prevent >> either of these? VPNC> Yes. If the expert does one of the above in a public fashion, people VPNC> will complain to the IESG and the IESG will either replace the VPNC> expert, decide they agree with the expert's personal reasons, or VPNC> decide they don't care. That's why making public all requests that VPNC> go to the expert and all responses they make to IANA is a Good VPNC> Thing. wouldn't just putting "IETF Consensus" be as good if that's what we really want to occur? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQCEwXIqHRg3pndX9AQER0wQAp/l+veRWTxxkwb1Xz5dh3TXUoFjucZ4b aLlJrU+dolBViz47W5DwgopkC1eUoWGTZmwfIM0rY/ytCn1+2dZP6VO6J3Hgjgd9 wT+G8br4lWd5LDaux/xZtxcjSG5cB8nYfU09Ro7Yg8+sTdJ4NAPPY/aNieGYD4Xz wuPog7TYG84= =AD85 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Feb 4 12:04:35 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i14K4YdN074893; Wed, 4 Feb 2004 12:04:34 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13486 Wed, 4 Feb 2004 14:01:53 -0500 (EST) Message-ID: <62173B970AE0A044AED8723C3BCF23810408B21A@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: ipsec@lists.tislabs.com Subject: RE: IANA document Date: Wed, 4 Feb 2004 14:12:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk See at @@@ -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Paul Hoffman / VPNC Sent: Tuesday, February 03, 2004 5:01 PM To: Scott G. Kelly; Michael Richardson Cc: ipsec@lists.tislabs.com Subject: Re: IANA document At 12:27 PM -0800 2/3/04, Scott G. Kelly wrote: ... >There is much to be said for public review and consensus. Exactly right. It is quite reasonable for the IPsec community to ask the IESG to make sure that the IKEv2 IANA reviewer does everything in public, and even asks for comments on each action. This is a trivial task (mailing lists and web sites, you know), and would certainly make it so that if the reviewer said "no" to something, people who cared would know immediately to talk to the IESG. @@@ I would note the MIME type and charset type procedures, which require that the request be posted on a public mailing list for two weeks, and subject to discussion, before an allocation/ registation can be made. These are generally considered to be quite successful. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Feb 4 13:26:55 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i14LQtXs080184; Wed, 4 Feb 2004 13:26:55 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20828 Wed, 4 Feb 2004 15:37:01 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <8854.1075916893@marajade.sandelman.ottawa.on.ca> References: <8854.1075916893@marajade.sandelman.ottawa.on.ca> Date: Wed, 4 Feb 2004 12:42:03 -0800 To: Michael Richardson , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: IANA document Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:48 PM -0500 2/4/04, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >>>>>> "VPNC" == VPNC writes: > >> Do you think there are adequate contingencies in place to prevent > >> either of these? > > VPNC> Yes. If the expert does one of the above in a public fashion, people > VPNC> will complain to the IESG and the IESG will either replace the > VPNC> expert, decide they agree with the expert's personal reasons, or > VPNC> decide they don't care. That's why making public all requests that > VPNC> go to the expert and all responses they make to IANA is a Good > VPNC> Thing. > > wouldn't just putting "IETF Consensus" be as good if that's what we really >want to occur? No, because that causes the IESG to get involved for every single registration. They're already busy enough, and should only be bothered when there is a problem. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Feb 4 13:33:32 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i14LXWG9080541; Wed, 4 Feb 2004 13:33:32 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21120 Wed, 4 Feb 2004 15:39:23 -0500 (EST) Message-Id: <5.2.0.9.2.20040204133321.04559b08@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 04 Feb 2004 13:36:05 -0500 To: ipsec@lists.tislabs.com From: Russ Housley Subject: Certicom IP Statement Regarding IKE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear IPsec WG: The attached note was just sent to statements@ietf.org, and it should appear on the IPR web page shortly. Russ = = = = = = = = = = Dear Sir or Madam: We wish to advise the IETF that Certicom believes it has rights under patents and pending applications that relate to RFC 3526 "More Modular Exponential (MODP) Diffie-Hellman Groups for Internet Key Exchange (IKE)", RFC 2409 "Internet Key Exchange", Internet Draft (draft-ietf-ipsec-ikev2-12.txt) "Internet Key Exchange (IKEv2) Protocol" and other IETF specifications using MODP Groups (individually and collectively the "IKE Specifications"). The applicable patents and applications include, but are not limited to, US Patents #5,933,504, #6,563,928, #6,078,667, #6,178,507, #6,195,433, US Patent Application Publications #2001/0014153, #2002/0090085, #2001/0021256, and any corresponding foreign applications. Certicom will, upon written request, provide a nonexclusive, royalty-free patent license, with reasonable terms and conditions, under those patents issued to Certicom that contain claims essential to the IKE Specifications and for which Certicom is able to provide patent licenses, within the limited field of use of MODP public key cryptography implemented using the well known Groups 1 and 2 as defined in RFC 2409. This patent license is available to all entities willing to grant Certicom a reciprocal license. Any party wishing to request a patent license should write to: Tony Rosati VP of Intellectual Property & Licensing Certicom Corp. 5520 Explorer Drive, 4th Floor Mississauga, ON L4W 5L1 Tel:(613) 254-9265 email: trosati@certicom.com From owner-ipsec@lists.tislabs.com Thu Feb 5 08:08:26 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i15G8PCY029016; Thu, 5 Feb 2004 08:08:25 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22501 Thu, 5 Feb 2004 10:12:58 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com (Unverified) Message-Id: In-Reply-To: <20040203105329.87307.qmail@web21510.mail.yahoo.com> References: <20040203105329.87307.qmail@web21510.mail.yahoo.com> Date: Tue, 3 Feb 2004 16:09:28 -0500 To: Andrew Krywaniuk From: Stephen Kent Subject: Re: SPD Syntax Example 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 Andrew, We have dramatically different views of what is or is not on the table for debate at this point, as well as starkly different perceptions of what 2401 really says, what does and does not contribute to interoperability, etc. So I will defer to the WG chairs and cognizant AD to indicate whether there is WG consensus to pursue this debate. Steve From owner-ipsec@lists.tislabs.com Thu Feb 5 08:39:31 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i15GdUKI031411; Thu, 5 Feb 2004 08:39:31 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA27191 Thu, 5 Feb 2004 11:01:44 -0500 (EST) From: Pasi.Eronen@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: One more thing about IKEv2 and EAP... Date: Thu, 5 Feb 2004 18:13:06 +0200 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612237B@esebe023.ntc.nokia.com> Thread-Topic: One more thing about IKEv2 and EAP... Thread-Index: AcPsAvBcas6j/aPHSBuuOfm2ttVfdQ== To: , X-OriginalArrivalTime: 05 Feb 2004 16:13:12.0067 (UTC) FILETIME=[F3C99530:01C3EC02] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA27177 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, While discussing IKEv2 and EAP with Hannes Tschofenig, we noticed some strangeness in IKEv2 handling of EAP keys and AUTH payloads. The -12 version says: "In such an extended exchange, the EAP AUTH payloads MUST be included in the first message each end sends after having sufficient information to compute the key. This will usually be in the last two messages of the exchange." The part I'm a bit worried about is "after having sufficient information to compute the key". EAP State Machine document currently specifies that the key is made available to the "lower layer protocol" outside EAP (in this case, IKEv2) only after an EAP-Success message has been sent (authenticator) or received (peer). This practise is also reflected in AAA protocols such as RADIUS and Diameter. The backend authentication server sends the key together with EAP-Success (e.g. in RADIUS Access-Accept packet). Furthermore, the last sentence is not correct: in most commonly used EAP methods, the key can be calculated well before the last two messages (e.g. EAP-TLS, PEAP, EAP-SIM, EAP-AKA, ...). For instance, a typical EAP-TLS exchange (with TLS_RSA_WITH_RC4_128_SHA ciphersuite) has 7 messages (including EAP-Success). The peer could include the AUTH payload already with message #4 and authenticator with message #5. There are other complications as well: - In some methods the peer can compute the key first (e.g. EAP-TLS), in others the authenticator (e.g. EAP-SIM). - It would be possible to have an EAP method where the authenticator has enough information to compute the key already in the first message (e.g. "key transport type" stuff); in this case, message #4 would contain two AUTH payloads (and that probably complicates things). - In some EAP methods the peer does not know in advance which is the last EAP-Response it will send. It would be possible to have a method where the final key depends on all messages exchanged, so the peer would not have enough information to calculate the key until receiving EAP-Success. - In some methods (e.g. PEAPv2) it is not always trivial to even determine when the necessary information is present, since this can depend on local policy about what methods can be run inside the "PEAP tunnel". I think this is likely to lead to problems, interoperability and otherwise. However, using the normal EAP practise (key becomes available only after EAP Success) would mean one additional round-trip, either: HDR, SK { EAP(...last response...) } --> <-- HDR, SK { EAP(Success), AUTH } HDR, SK { AUTH } --> <-- HDR, SK { SAr2, TSi, TSr } Or alternatively: HDR, SK { EAP(...last response...) } --> <-- HDR, SK { EAP(Success) } HDR, SK { AUTH } --> <-- HDR, SK { AUTH, SAr2, TSi, TSr } Any comments on how to best handle this? Is an extra roundtrip necessary (it is if EAP state machine is followed), or could this be handled in some other way? Best regards, Pasi From owner-ipsec@lists.tislabs.com Thu Feb 5 11:52:46 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i15Jqjvf047482; Thu, 5 Feb 2004 11:52:46 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16454 Thu, 5 Feb 2004 14:14:16 -0500 (EST) Date: Thu, 05 Feb 2004 11:04:45 -0800 From: Yoshihiro Ohba Subject: [Q] AUTHENTICATION_FAILED Notification To: ipsec@lists.tislabs.com Message-id: <20040205190445.GG17931@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have a question about the usage of AUTHENTICATION_FAILED Notification of IKEv2. draft-ietf-ipsec-ikev2-12.txt says: AUTHENTICATION_FAILED 24 Sent in the response to an IKE_AUTH message when for some reason the authentication failed. There is no associated data. Is the Notify payload of this type cryptographycally protected with IKE_SA? Regards, Yoshihiro Ohba From owner-ipsec@lists.tislabs.com Thu Feb 5 15:37:00 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i15NawTA061244; Thu, 5 Feb 2004 15:37:00 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04116 Thu, 5 Feb 2004 17:53:25 -0500 (EST) 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: RE: [Q] AUTHENTICATION_FAILED Notification Date: Thu, 5 Feb 2004 15:04:25 -0800 Message-ID: Thread-Topic: [Q] AUTHENTICATION_FAILED Notification thread-index: AcPsHuxbfAkE7zXmSGWDl5dvccFyigAHR9hA From: "Charlie Kaufman" To: "Yoshihiro Ohba" , X-OriginalArrivalTime: 05 Feb 2004 23:04:21.0278 (UTC) FILETIME=[63C873E0:01C3EC3C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id RAA04113 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, all messages except for the first two are cryptographically protected with the IKE SA. Of course, since authentication has not occurred, the cryptographic protection may not in practice provide much assurance to the transaction. --Charlie -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Yoshihiro Ohba Sent: Thursday, February 05, 2004 11:05 AM To: ipsec@lists.tislabs.com Subject: [Q] AUTHENTICATION_FAILED Notification Hi, I have a question about the usage of AUTHENTICATION_FAILED Notification of IKEv2. draft-ietf-ipsec-ikev2-12.txt says: AUTHENTICATION_FAILED 24 Sent in the response to an IKE_AUTH message when for some reason the authentication failed. There is no associated data. Is the Notify payload of this type cryptographycally protected with IKE_SA? Regards, Yoshihiro Ohba From owner-ipsec@lists.tislabs.com Thu Feb 5 16:38:59 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i160cwUs065111; Thu, 5 Feb 2004 16:38:58 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08211 Thu, 5 Feb 2004 18:54:47 -0500 (EST) From: chris stillson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16418.55749.338846.844182@gargle.gargle.HOWL> Date: Thu, 5 Feb 2004 16:03:17 -0800 To: vincent.murphy@sun.com Cc: ipsec@lists.tislabs.com Subject: Certicom IP Statement Regarding IKE In-Reply-To: <5.2.0.9.2.20040204133321.04559b08@mail.binhost.com> References: <5.2.0.9.2.20040204133321.04559b08@mail.binhost.com> X-Mailer: VM 7.07 under 21.1 (patch 3) "Acadia" XEmacs Lucid Reply-To: chris.stillson@sun.com X-Face: ;>?o+t66!z`OvpX.6T'j.4l4Gi+L*?8ZnU3L[G/^R,ELl3.Stln=12L+t|hsa*<{/D<{OS( ybD%5 Dear IPsec WG: > > The attached note was just sent to statements@ietf.org, and it should > appear on the IPR web page shortly. > > Russ > > = = = = = = = = = = > > Dear Sir or Madam: > > We wish to advise the IETF that Certicom believes it has rights > under patents and pending applications that relate to RFC 3526 > "More Modular Exponential (MODP) Diffie-Hellman Groups for > Internet Key Exchange (IKE)", RFC 2409 "Internet Key Exchange", > Internet Draft (draft-ietf-ipsec-ikev2-12.txt) "Internet Key > Exchange (IKEv2) Protocol" and other IETF specifications using > MODP Groups (individually and collectively the "IKE > Specifications"). The applicable patents and applications > include, but are not limited to, US Patents #5,933,504, > #6,563,928, #6,078,667, #6,178,507, #6,195,433, US Patent > Application Publications #2001/0014153, #2002/0090085, > #2001/0021256, and any corresponding foreign applications. > > Certicom will, upon written request, provide a nonexclusive, > royalty-free patent license, with reasonable terms and > conditions, under those patents issued to Certicom that contain > claims essential to the IKE Specifications and for which > Certicom is able to provide patent licenses, within the limited > field of use of MODP public key cryptography implemented using > the well known Groups 1 and 2 as defined in RFC 2409. This > patent license is available to all entities willing to grant > Certicom a reciprocal license. > > Any party wishing to request a patent license should write to: > > Tony Rosati > VP of Intellectual Property & Licensing > Certicom Corp. > 5520 Explorer Drive, 4th Floor > Mississauga, ON L4W 5L1 > Tel:(613) 254-9265 > > email: trosati@certicom.com > -- chris stillson IPSEC crypto monkey x82477 Note: Preceding comments written by an engineer. There is nothing to read into them. He really has no hidden motives or agendas. 1.Right Understanding 2.Right Thoughts 3.Right Speech 4.Right Action 5.Right Livelihood 6.Right Effort 7.Right Mindfulness 8.Right Concentration --Please inform author if he has forgotten about any of these From owner-ipsec@lists.tislabs.com Thu Feb 5 17:28:56 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i161Suj2067610; Thu, 5 Feb 2004 17:28:56 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA13193 Thu, 5 Feb 2004 19:51:51 -0500 (EST) From: chris stillson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16418.59090.584111.92639@gargle.gargle.HOWL> Date: Thu, 5 Feb 2004 16:58:58 -0800 To: ipsec@lists.tislabs.com Subject: Certicom IP Statement Regarding IKE In-Reply-To: <16418.55749.338846.844182@gargle.gargle.HOWL> References: <5.2.0.9.2.20040204133321.04559b08@mail.binhost.com> <16418.55749.338846.844182@gargle.gargle.HOWL> X-Mailer: VM 7.07 under 21.1 (patch 3) "Acadia" XEmacs Lucid Reply-To: chris.stillson@sun.com X-Face: ;>?o+t66!z`OvpX.6T'j.4l4Gi+L*?8ZnU3L[G/^R,ELl3.Stln=12L+t|hsa*<{/D<{OS( ybD%5 > This doesn't currently apply to us, just to future use of elliptic > curve crypto in our IKE.... Sorry about that. just forwarding a bit of mail and missed a to.... chris stillson IPSEC crypto monkey x82477 Note: Preceding comments written by an engineer. There is nothing to read into them. He really has no hidden motives or agendas. 1.Right Understanding 2.Right Thoughts 3.Right Speech 4.Right Action 5.Right Livelihood 6.Right Effort 7.Right Mindfulness 8.Right Concentration --Please inform author if he has forgotten about any of these From owner-ipsec@lists.tislabs.com Thu Feb 5 23:40:04 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i167e3YM056120; Thu, 5 Feb 2004 23:40:03 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA07975 Fri, 6 Feb 2004 01:54:26 -0500 (EST) From: Black_David@emc.com Message-ID: X-Sybari-Trust: d8fb10c9 b1a25add bdf41840 0000013d To: ipsec@lists.tislabs.com Subject: Non-ipsec IANA allocations for IKEv2 needed Date: Fri, 6 Feb 2004 02:05:26 -0500 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 About a month ago, Tero Kivinen wrote: > > IKEv2 Security Protocol Identifiers may be allocated by Standards Action. > Again same as with proposal substructure protocol-IDs, I think > specification required would be enough. I can see that someone might > want to use IKE as a key exchange method for non-ipsec cases, where > the easiest way would be to use new protocol number for that, and if > it is not IP related protocol, then its documents might not be > standard track documents, or RFCs at all. Preventing duplicate numbers > in those cases might still be usefull, in case someone sometime define > way to transport that stuff on the internet too... In fact someone does want to use IKEv2 for a non-ipsec case - Technical Committee T11 (www.t11.org) is planning to use IKEv2 as the key exchange and SA-setup protocol for Fibre Channel (FC). Since IP runs over Fibre Channel (RFC 2625) and Fibre Channel runs over IP (RFC 3643 + additional IPS WG drafts in the RFC Editor's queue), there is ample opportunity for confusion, and hence preventing duplicate numbers is highly desirable. Fibre Channel will want new IKEv2 values for the following: - IKEv2 Security Protocol Identifiers. There's at least one existing FC security encapsulation that is neither ESP nor AH. - IKEv2 Integrity Algorithm Transform IDs. The existing FC security encapsulation uses HMACs without truncation instead of the 96-bit truncated HMACs used by ESP and AH. - IKEv2 Identification Payload ID Types. Needless to say, in the absence of IP addresses, FC needs to use other sorts of addresses for identification. - IKEv2 Traffic Selector Types. Since FC native traffic doesn't have an IP header, different traffic selectors are needed. There should be no problem in principle with producing specifications for these and publishing them as RFCs (probably informational), so Expert Review an Specification Required allocation processes are fine. This does raise a couple of concerns: - There are no private use values defined for either security protocol IDs or traffic selector types, making it difficult to experiment with implementations prior to allocation of values. - My reading of the list discussion is that the security protocol identifiers should only be allocated by standards action, whereas Specification Required or Expert Review is ok for the traffic selector types. This makes it difficult to allocate a security protocol ID. The upshot is that in order to get a security protocol ID for non-ipsec usage, one has to publish a standards track RFC defining a security encapsulation that MUST NOT be used for ipsec. That doesn't sound right due to both the "standards track" requirement (informational RFC would be ok), and the inability to legitimately use any value in a non-ipsec context prior to the RFC publication. This echoes Tero's concern from above. As an alternative, could we set aside a range of Security Protocol IDs in IKEv2 that MUST NOT be used with IPsec for IP traffic, and allow allocation of IDs for non-IPsec usage via Specification Required (or even an Informational RFC)? Security Protocol ID is a 1 byte field (256 values) of which only 3 (IKE, AH, ESP) are used now. Reserving the largest 32 or 64 values for non-ipsec usage shouldn't cause any problems for future IPsec security protocols, although IANA should be instructed to hand out new IPsec protocol IDs in ascending order after the existing values to retain flexibility in the future. This approach could also allow creation of non-IPsec Private Use values (e.g., split the 64 non-IPsec values into 32 Private Use and 32 to be allocated by IANA). We should also consider setting aside private use traffic selector values, with the possible restriction that they are for non-ipsec usage only. 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 Fri Feb 6 10:15:05 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i16IF0sC036406; Fri, 6 Feb 2004 10:15:05 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA18007 Fri, 6 Feb 2004 12:19:03 -0500 (EST) From: chris stillson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16419.53009.246021.788904@gargle.gargle.HOWL> Date: Fri, 6 Feb 2004 09:29:53 -0800 To: Russ Housley Cc: vincent.murphy@sun.com, ipsec@lists.tislabs.com Subject: Re: Certicom IP Statement Regarding IKE In-Reply-To: <5.2.0.9.2.20040206092203.0467c2f0@mail.binhost.com> References: <5.2.0.9.2.20040204133321.04559b08@mail.binhost.com> <5.2.0.9.2.20040206092203.0467c2f0@mail.binhost.com> X-Mailer: VM 7.07 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid X-Face: ;>?o+t66!z`OvpX.6T'j.4l4Gi+L*?8ZnU3L[G/^R,ELl3.Stln=12L+t|hsa*<{/D<{OS(ybD%5 Chris: > > I read the IPR statement differently. I am not going to take any position > about the patents. However, the second paragraph offers royalty-free use of > the 768-bit and the 1024-bit MODP groups in RFC 2409. These groups are > used with Diffie-Hellman. > > The IPS statement does not say anything about the other MODP groups, which > implies that the situation will be different. I didn't notice that. Yes they do make claim against 2409. Isn't it a bit late for them to do that? I can understand them having claims on ECC, but the modp stuff? How? The RFC is 6 1/2 years old..... chris stillson IPSEC crypto monkey x82477 Note: Preceding comments written by an engineer. There is nothing to read into them. He really has no hidden motives or agendas. 1.Right Understanding 2.Right Thoughts 3.Right Speech 4.Right Action 5.Right Livelihood 6.Right Effort 7.Right Mindfulness 8.Right Concentration --Please inform author if he has forgotten about any of these From owner-ipsec@lists.tislabs.com Fri Feb 6 11:53:32 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i16JrV06043829; Fri, 6 Feb 2004 11:53:31 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA22052 Fri, 6 Feb 2004 13:55:15 -0500 (EST) Message-Id: <5.2.0.9.2.20040206140236.028febb0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 06 Feb 2004 14:05:39 -0500 To: JianHua Feng From: Russ Housley Subject: Re: Certicom IP Statement Regarding IKE Cc: ipsec@lists.tislabs.com In-Reply-To: <20040206123507.B61574@austin.ibm.com> References: <5.2.0.9.2.20040204133321.04559b08@mail.binhost.com> <5.2.0.9.2.20040204133321.04559b08@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, I believe that Certicom is claiming rights to all of the groups in RFC 2409. At leas that is how I interpret the statement, and that is the reason I thought it appropriate to post the IPR Statement to the WG mail list.... Each implementor needs to figure out their own way forward. Russ At 12:35 PM 2/6/2004 -0600, JianHua Feng wrote: >Does that mean include group1, 2 in RFC 2409 ? They are all well-known and >have been used for years. From owner-ipsec@lists.tislabs.com Fri Feb 6 12:21:39 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i16KLc6x045371; Fri, 6 Feb 2004 12:21:38 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23388 Fri, 6 Feb 2004 14:32:04 -0500 (EST) Message-Id: <5.2.0.9.2.20040206140744.044b8948@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 06 Feb 2004 14:13:28 -0500 To: Chris.Stillson@sun.com From: Russ Housley Subject: Re: Certicom IP Statement Regarding IKE Cc: vincent.murphy@sun.com, ipsec@lists.tislabs.com In-Reply-To: <16419.53009.246021.788904@gargle.gargle.HOWL> References: <5.2.0.9.2.20040206092203.0467c2f0@mail.binhost.com> <5.2.0.9.2.20040204133321.04559b08@mail.binhost.com> <5.2.0.9.2.20040206092203.0467c2f0@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Chris: >I didn't notice that. Yes they do make claim against 2409. Isn't it a >bit late for them to do that? I can understand them having claims on >ECC, but the modp stuff? How? The RFC is 6 1/2 years old..... The IPsec WG did receive some warning in 1998! It was in a discussion on ECC, but it is pretty clear. Some of the pending patents for secure implementations of public key technologies may also cover implementations of the current mandatory portions of IKE in IPsec. The full note is below. Russ >From: "Paul Lambert" >To: ho@earth.hpc.org (Hilarie Orman) >cc: kent@bbn.com, ipsec@tis.com >Date: Mon, 20 Jul 1998 16:25:34 -0700 >Subject: Re: Patent & licence for IPSec ? > > >Hilarie, > >I assume that your note below indicates that you personally do not have any >patents filed or patents issued related to IPsec. > > >> At this time are not aware of any intellectual property issues with the > >> base IPsec protocols and algorithms, or with IKE use of D-H. Use of RSA > >> for certificate signatures, or use of ECC for key exchange does involve > >> patent issues. > > > >ECC over F[2^p] for DH key exchange does not infringe on intellectual > >property. > > > >Hilarie > > >Certicom has pending patents that cover secure and efficient >implementations of Elliptic Curve Cryptography (ECC) over both F[2^m] and >F[p]. Some of the pending patents for secure implementations of public key >technologies may also cover implementations of the current mandatory >portions of IKE in IPsec. > >A statement of our non-exclusive and nondiscriminatory patent licensing is >available at: > > http://grouper.ieee.org/groups/1363/letters/Certicom.txt > >The pending patents include some mechanisms to provide more efficient >processing of ECC based on F[2^m] with "m" being composite. Note that our >cryptographic research group invested considerable effort in composite >techniques some years ago. They are now only advocating the use of "m" >prime based on security considerations. Note that Certicom has more >patents pending on F[2^m] with m composite than for F[2^m] prime. As we >have discussed on this list before, it is strongly recommended that the >IPsec use of ECC not support composite 2^m, but rather use only prime 2^m >curves. This would provide much better security and would incorporate less >potential IPR from Certicom > > >Regards, > >Paul A. Lambert > >VP. Product Management >Certicom Corporation >San Mateo California >+1-650-312-7996 From owner-ipsec@lists.tislabs.com Fri Feb 6 14:14:54 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i16MErV0051312; Fri, 6 Feb 2004 14:14:53 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02944 Fri, 6 Feb 2004 16:22:50 -0500 (EST) Message-ID: <20040206090012.892.qmail@web21510.mail.yahoo.com> Date: Fri, 6 Feb 2004 04:00:12 -0500 (EST) From: Andrew Krywaniuk Subject: Re: SPD Syntax Example To: Stephen Kent Cc: ipsec@lists.tislabs.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > We have dramatically different views of what is or > is not on the > table for debate at this point, as well as starkly > different > perceptions of what 2401 really says, what does and > does not > contribute to interoperability, etc. > > So I will defer to the WG chairs and cognizant AD to > indicate whether > there is WG consensus to pursue this debate. Well, I very much doubt that. The number of people following the 2401bis discussion is small enough already. I think the problem is that we never had WG consensus (or even much of a debate) about what (if anything) should be in 2401bis in the first place. Admittedly, I probably should have posted this comment about 6 months ago (which I did, although it was blocked by the list's sp*m filter). I don't really have the patience to debate this subject either, but I do have the following suggestion for any implementers who still follow the list: Provide a mode of IKE in which you don't negotiate selectors (e.g. send a wildcard selector). You won't miss them, and you won't miss the interop problems either. Meanwhile, the WG can continue in the venerable tradition of standardizing edge cases that few people will implement. Andrew ===== Andrew Krywaniuk, Fortinet Technologies Please *do not* reply to this address. (I will not read it) Reply to askrywan..hotmail..com or my home address. ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From owner-ipsec@lists.tislabs.com Fri Feb 6 14:48:53 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i16Mmrhw052947; Fri, 6 Feb 2004 14:48:53 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07845 Fri, 6 Feb 2004 17:10:54 -0500 (EST) Date: Fri, 6 Feb 2004 12:35:07 -0600 From: JianHua Feng To: Russ Housley Cc: ipsec@lists.tislabs.com Subject: Re: Certicom IP Statement Regarding IKE Message-ID: <20040206123507.B61574@austin.ibm.com> Mail-Followup-To: Russ Housley , ipsec@lists.tislabs.com References: <5.2.0.9.2.20040204133321.04559b08@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <5.2.0.9.2.20040204133321.04559b08@mail.binhost.com>; from housley@vigilsec.com on Wed, Feb 04, 2004 at 01:36:05PM -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Does that mean include group1, 2 in RFC 2409 ? They are all well-known and have been used for years. Jianhua On Wed, Feb 04, 2004 at 01:36:05PM -0500, Russ Housley wrote: > Dear IPsec WG: > > The attached note was just sent to statements@ietf.org, and it should > appear on the IPR web page shortly. > > Russ > > = = = = = = = = = = > > Dear Sir or Madam: > > We wish to advise the IETF that Certicom believes it has rights > under patents and pending applications that relate to RFC 3526 > "More Modular Exponential (MODP) Diffie-Hellman Groups for > Internet Key Exchange (IKE)", RFC 2409 "Internet Key Exchange", > Internet Draft (draft-ietf-ipsec-ikev2-12.txt) "Internet Key > Exchange (IKEv2) Protocol" and other IETF specifications using > MODP Groups (individually and collectively the "IKE > Specifications"). The applicable patents and applications > include, but are not limited to, US Patents #5,933,504, > #6,563,928, #6,078,667, #6,178,507, #6,195,433, US Patent > Application Publications #2001/0014153, #2002/0090085, > #2001/0021256, and any corresponding foreign applications. > > Certicom will, upon written request, provide a nonexclusive, > royalty-free patent license, with reasonable terms and > conditions, under those patents issued to Certicom that contain > claims essential to the IKE Specifications and for which > Certicom is able to provide patent licenses, within the limited > field of use of MODP public key cryptography implemented using > the well known Groups 1 and 2 as defined in RFC 2409. This > patent license is available to all entities willing to grant > Certicom a reciprocal license. > > Any party wishing to request a patent license should write to: > > Tony Rosati > VP of Intellectual Property & Licensing > Certicom Corp. > 5520 Explorer Drive, 4th Floor > Mississauga, ON L4W 5L1 > Tel:(613) 254-9265 > > email: trosati@certicom.com From owner-ipsec@lists.tislabs.com Mon Feb 9 16:49:13 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1A0n8mB072970; Mon, 9 Feb 2004 16:49:12 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA22690 Mon, 9 Feb 2004 18:42:38 -0500 (EST) Message-ID: <40281DF2.9030402@cisco.com> Date: Mon, 09 Feb 2004 15:55:30 -0800 From: Geoffrey Huang User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Length of checksum in IKEv2 encrypted payload? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi there, First, apologies if this has already been discussed - I haven't been following this list closely lately, and I couldn't find anything in the archives. Section 3.14 of the IKEv2 draft describes the encrypted payload, showing the last field of the payload to be the integrity checksum. The text doesn't describe how long the field is. From the diagram, it looks variable, but there is no length field describing the value. Is this an oversight? -g From owner-ipsec@lists.tislabs.com Wed Feb 11 01:57:46 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1B9vjrQ036274; Wed, 11 Feb 2004 01:57:46 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA14724 Wed, 11 Feb 2004 03:52:44 -0500 (EST) From: Pasi.Eronen@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Length of checksum in IKEv2 encrypted payload? Date: Wed, 11 Feb 2004 11:04:13 +0200 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122383@esebe023.ntc.nokia.com> Thread-Topic: Length of checksum in IKEv2 encrypted payload? Thread-Index: AcPvcS9JaaCTjXlhSOeUqJ6EfyoeqABC1vjg To: , X-OriginalArrivalTime: 11 Feb 2004 09:04:13.0179 (UTC) FILETIME=[04B174B0:01C3F07E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id DAA14713 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, The length of this field depends on what integrity algorithm was negotiated. IKEv2 assumes that all integrity algorithms have a fixed checksum length; this length is given in the specification for that algorithm (e.g. 96 bits for AUTH_HMAC_SHA1_96). Therefore, it's not necessary to have a length field in each packet. Best regards, Pasi > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of ext Geoffrey Huang > Sent: Tuesday, February 10, 2004 1:56 AM > To: ipsec@lists.tislabs.com > Subject: Length of checksum in IKEv2 encrypted payload? > > Hi there, > > First, apologies if this has already been discussed - I > haven't been following this list closely lately, and I > couldn't find anything in the archives. > > Section 3.14 of the IKEv2 draft describes the encrypted > payload, showing the last field of the payload to be the > integrity checksum. The text doesn't describe how long the > field is. From the diagram, it looks variable, but there is > no length field describing the value. Is this an oversight? > > -g From owner-ipsec@lists.tislabs.com Wed Feb 11 11:01:12 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1BJ1BnE081706; Wed, 11 Feb 2004 11:01:11 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06372 Wed, 11 Feb 2004 13:12:43 -0500 (EST) Message-ID: <402A7309.4070005@cisco.com> Date: Wed, 11 Feb 2004 10:23:05 -0800 From: Geoffrey Huang User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com CC: ipsec@lists.tislabs.com Subject: Re: Length of checksum in IKEv2 encrypted payload? References: <052E0C61B69C3741AFA5FE88ACC775A6122383@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122383@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Pasi.Eronen@nokia.com wrote: > Hi, > > The length of this field depends on what integrity algorithm > was negotiated. IKEv2 assumes that all integrity algorithms have > a fixed checksum length; this length is given in the specification > for that algorithm (e.g. 96 bits for AUTH_HMAC_SHA1_96). > Therefore, it's not necessary to have a length field in > each packet. Yes, that's what I thought. It would be nice if the draft spelled this out. -g > Best regards, > Pasi > > >>-----Original Message----- >>From: owner-ipsec@lists.tislabs.com >>[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of ext Geoffrey Huang >>Sent: Tuesday, February 10, 2004 1:56 AM >>To: ipsec@lists.tislabs.com >>Subject: Length of checksum in IKEv2 encrypted payload? >> >>Hi there, >> >>First, apologies if this has already been discussed - I >>haven't been following this list closely lately, and I >>couldn't find anything in the archives. >> >>Section 3.14 of the IKEv2 draft describes the encrypted >>payload, showing the last field of the payload to be the >>integrity checksum. The text doesn't describe how long the >>field is. From the diagram, it looks variable, but there is >>no length field describing the value. Is this an oversight? >> >>-g > > From owner-ipsec@lists.tislabs.com Thu Feb 12 10:09:56 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CI9tnc051843; Thu, 12 Feb 2004 10:09:56 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00500 Thu, 12 Feb 2004 12:15:06 -0500 (EST) Subject: NAT traversal and refreshes To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: David Wierbowski Date: Thu, 12 Feb 2004 12:26:38 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 6.0.2CF2 HFB2 IGS HF12G|February 9, 2004) at 02/12/2004 12:26:40 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have a question about the "Negotiation of NAT-Traversal in IKE" draft. Should the NAT vendor ID, NAT-D payloads, and NAT-OA payloads documented in draft-ietf-ipsec-nat-t-ike-07 be exchanged during refreshes of a phase 1 and phase 2 SAs or should they only be exchanged in the initial negotiation of a phase 1/2 SA? It seems as if once you've detected a NAT in the initial negotiation there's not much value in checking if it is still there on a refresh. Thanks in advance for your help. Dave Wierbowski z/OS Comm Server Development From owner-ipsec@lists.tislabs.com Thu Feb 12 12:09:14 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CK9DfZ060715; Thu, 12 Feb 2004 12:09:13 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA17535 Thu, 12 Feb 2004 14:24:47 -0500 (EST) Date: Thu, 12 Feb 2004 14:36:05 -0500 From: Radia Perlman Subject: Re: NAT traversal and refreshes To: David Wierbowski Cc: ipsec@lists.tislabs.com Message-id: <1e8f6961.69611e8f@bur-mail2.east.sun.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.16 (built May 14 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7bit Content-disposition: inline X-Accept-Language: en Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'd agree with you (that it shouldn't be rechecked on refresh of the SA). If there was a worry that things might change, then it ought to be done periodically, not just when an SA is being refreshed. And actually, I think as long as both endpoints can do the NAT traversal stuff, then it works fine even if the NAT goes away, and the design might be simpler to just always work in NAT traversal mode. But at any rate, I don't think there's any downside in, once noticing a NAT, continuing in NAT traversal mode. Radia ----- Original Message ----- From: David Wierbowski Date: Thursday, February 12, 2004 12:26 pm Subject: NAT traversal and refreshes > > > > > I have a question about the "Negotiation of NAT-Traversal in IKE" > draft.Should the NAT vendor ID, NAT-D payloads, and NAT-OA > payloads documented in > draft-ietf-ipsec-nat-t-ike-07 be exchanged during refreshes of a > phase 1 > and phase 2 SAs or should they only be exchanged in the initial > negotiationof a phase 1/2 SA? It seems as if once you've detected > a NAT in the > initial negotiation there's not much value in checking if it is > still there > on a refresh. Thanks in advance for your help. > > Dave Wierbowski > > z/OS Comm Server Development > > > From owner-ipsec@lists.tislabs.com Thu Feb 12 21:39:11 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1D5dApB093755; Thu, 12 Feb 2004 21:39:10 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA05076 Fri, 13 Feb 2004 00:01:14 -0500 (EST) To: ipsec@lists.tislabs.com Subject: IANA assignment policies From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Fri, 13 Feb 2004 00:08:35 -0500 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 There has been no further activity on the mailing list about IANA assignment policies for IKEv2, and we need to somehow make progress. So I'm going to make a set of proposals given the discussion which we've had on the subject: 1) All numberspaces should have at least some (perhaps a very small) Private Use, per David Black's concerns about being able to do private experiments. 2) All 16-bit and greater number spaces will have a policy of Specification Required for the portion of the space which is reserved for IANA assignment. 3) All 8-bit number spaces shall have the following policy for the portion of the space which is reserved for IANA assignment. A number may be assigned EITHER via a standards-track RFC OR by satisfying both of the following policies: Specification Required and Expert Review. Furthermore, the review by the expert must follow a two-week public discussion on a mailing list. As always, the decision of the expert may be appealed to the IESG who may decide to affirm or override the Expert's decision. Does this satisfy everyone's concerns? I'd like to call the question and come to a decision within a week. - Ted From owner-ipsec@lists.tislabs.com Thu Feb 12 22:53:05 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1D6r458016479; Thu, 12 Feb 2004 22:53:05 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA14998 Fri, 13 Feb 2004 01:10:56 -0500 (EST) To: ipsec@lists.tislabs.com cc: mcgrew@cisco.com, canetti@watson.ibm.com, hugo@ee.technion.ac.il Subject: Changing the key deriveration From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Fri, 13 Feb 2004 01:18:09 -0500 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 In a recent message, Steve Kent made the following statement: >When I last spoke with Russ, he indicated that he was prepared to >tolerate another delay on the IKE v2 document to incorporate the >change that Hugo suggested, to incorporate bits from an key-based EAP >method into the PRF for the keys used for encryption & integrity. This presumably is referring to Hugo's proposal of January 13th, which I've included below. On a recent concall of the IPSEC management team, we discussed on how to handle this, given that (a) there has been no response or discussion to Hugo's proposal on the mailing list to date, and (b) a number of us get hives with the thought of making changes to something as critical as IKEv2's cryptographic core at the last minute without some adequate and thoughtful review. So we propose the following path forward. First, that we ask the Hugo to clarify his objection. It appears to be mainly a certificational weakness in that it may make it harder to prove correctness at least when using normal crypto algorithms. Is this a fair characterization, or is there a fundamental problem in normal usage? Secondly, we'd like to ask the Crypto Forum Research Group in the IRTF, whose charter it is to provide a resource to IETF working group to review uses of cryptographic mechanisms if they might be willing to give us review of the current key agreement mechanisms found in sections 2.14, 2.15, and 2.16 of draft-ietf-ipsec-ikev2-12.txt as well as the proposed change by Hugo. Ran and David: Is this a good use of the CFRG, and would you be willing to ask them to engage in this review? Based on the answers from Hugo and the CFRG, the working group will hopefully have sufficient information in order to quickly come to consensus about whether we need to make any changes to ikev2-12. Does this seem a reasonable way forward? I don't want to unduly prolong an already very long process, but it seems to us that it is better to put examine this issue and put it to rest now, instead of waiting until Russ finishes reviewing the document (it is in his queue) and starts IETF last call. - Ted ------------------ Date: Tue, 13 Jan 2004 22:10:50 +0200 (IST) From: Hugo Krawczyk Subject: Keing the prf To: Theodore Ts'o cc: Russ Housley , byfraser@cisco.com, Charlie Kaufman , IPsec WG There is one issue that was subject of discussion in the last weeks and I believe requires a better resolution. I refer to the problem that ikev2 (including -12) defines two uses of the prf function (in sections 2.15 and 2.16) where the prf is keyed with SK_a. This is problematic since SK_a is defined as a key to the "integrity algorithm" which may be different than the prf. Indeed the integrity algorithm and prf have different transform types (#3 and #2) respectively, and then are negotiated independetly (in particular they may use different algorihms). Why is this a problem? First, because the two transforms may require keys of different lengths, in particular SK_a may be too short to key the prf. Second, it is a wrong cryptographic practice to use the same key with two different algorithms. This may or may not translate into actual attacks, but it certainly spoils the otherwise sound design of the protocol. It will also invite "attacks" from future formal analysts (beyond the operational issues referred to in the first item). I believe that the problem is best solved by deriving an additional pair of keys from SKEYSEED (call them SK_pi and SK_pr) for keying the prf in the above two cases. It is certainly easy to specify and to implement (and easier than to justify why this wasn't done). Specifically add the pair SK_pi, SK_pr to the key derivation formula in 2.14. Change prf(SK_ar,IDr') to prf(SK_pr,IDr') and prf(SK_ai,IDr') to prf(SK_pi,IDr') in section 2.15. Change "SK_ai and SK_ar" in the next to last paragraph of section 2.16 with "SK_pi and SK_pr" I suggest that this be solved before the official last call (otherwise you can see this as a comment provided in the last call phase). Hugo From owner-ipsec@lists.tislabs.com Fri Feb 13 08:27:55 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DGRsF9004543; Fri, 13 Feb 2004 08:27:55 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21636 Fri, 13 Feb 2004 10:33:06 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Fri, 13 Feb 2004 07:44:40 -0800 To: "Theodore Ts'o" , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: IANA assignment policies Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:08 AM -0500 2/13/04, Theodore Ts'o wrote: >There has been no further activity on the mailing list about IANA >assignment policies for IKEv2, and we need to somehow make progress. > >So I'm going to make a set of proposals given the discussion which we've >had on the subject: > >1) All numberspaces should have at least some (perhaps a very small) > Private Use, per David Black's concerns about being able to do > private experiments. > >2) All 16-bit and greater number spaces will have a policy of > Specification Required for the portion of the space which is reserved > for IANA assignment. > >3) All 8-bit number spaces shall have the following policy for the > portion of the space which is reserved for IANA assignment. A number > may be assigned EITHER via a standards-track RFC OR by satisfying > both of the following policies: Specification Required and Expert > Review. Furthermore, the review by the expert must follow a two-week > public discussion on a mailing list. As always, the decision of the > expert may be appealed to the IESG who may decide to affirm or > override the Expert's decision. > >Does this satisfy everyone's concerns? No. The private use proposal is fine. However, as Michael Richardson said on the list over a week ago, "I think that the consensus of the WG list is that all values should be a consistent "Expert Review"." This is an easy-to-understand policy on IANA assignments. There were people in favor, one concerned, and I believe his concerns were allayed. Splitting the decision by size of field will not be easy to figure out for implementers, yet they are the main users of the IANA registry. The proposal of having some numbers be "Specification Required" for some spaces but Specification Required or expert review for other spaces means that proposals that include some of both have to deal with different requirements for a single proposal. Worse yet, "Specification Required" forces IANA to decide if a non-RFC document is "permanent and readily available". Knowing that has proven to be something that is well outside of IANA's skill set. Please go with the earlier WG consensus, which is to make all values "Expert Review" instead of creating a new and more difficult to understand one. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Feb 13 10:59:32 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DIxVh6012788; Fri, 13 Feb 2004 10:59:32 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11956 Fri, 13 Feb 2004 13:16:53 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 13 Feb 2004 13:11:47 -0500 To: "Theodore Ts'o" From: Stephen Kent Subject: Re: Changing the key deriveration Cc: ipsec@lists.tislabs.com, mcgrew@cisco.com, canetti@watson.ibm.com, hugo@ee.technion.ac.il 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, I think this is a good proposal on how to proceed. Steve From owner-ipsec@lists.tislabs.com Fri Feb 13 16:10:21 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1E0AKnX030735; Fri, 13 Feb 2004 16:10:21 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA21706 Fri, 13 Feb 2004 18:28:40 -0500 (EST) Message-ID: <402D5FF2.9070206@kolumbus.fi> Date: Sat, 14 Feb 2004 01:38:26 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Theodore Ts'o" Cc: ipsec@lists.tislabs.com Subject: Re: IANA assignment policies 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 Theodore Ts'o wrote: > There has been no further activity on the mailing list about IANA > assignment policies for IKEv2, and we need to somehow make progress. > > So I'm going to make a set of proposals given the discussion which we've > had on the subject: > > 1) All numberspaces should have at least some (perhaps a very small) > Private Use, per David Black's concerns about being able to do > private experiments. > > 2) All 16-bit and greater number spaces will have a policy of > Specification Required for the portion of the space which is reserved > for IANA assignment. > > 3) All 8-bit number spaces shall have the following policy for the > portion of the space which is reserved for IANA assignment. A number > may be assigned EITHER via a standards-track RFC OR by satisfying > both of the following policies: Specification Required and Expert > Review. Furthermore, the review by the expert must follow a two-week > public discussion on a mailing list. As always, the decision of the > expert may be appealed to the IESG who may decide to affirm or > override the Expert's decision. > > Does this satisfy everyone's concerns? I'd like to call the question > and come to a decision within a week. I think this is reasonable. I'd also be satisfied by a simpler standards track only policy for #3. --Jari From owner-ipsec@lists.tislabs.com Fri Feb 13 17:42:08 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1E1g8tL034868; Fri, 13 Feb 2004 17:42:08 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA04983 Fri, 13 Feb 2004 20:08:00 -0500 (EST) Date: Sat, 14 Feb 2004 03:21:00 +0200 (IST) From: Hugo Krawczyk To: "Theodore Ts'o" Cc: IPsec WG , , , Ran Canetti Subject: Re: Changing the key deriveration In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at technion.ac.il Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This msg is being sent to both ipsec and cfrg (apologies for all those -- like me -- that will get this by duplicate) Some background (for the cfrg audience): In a msg from earlier today (appended below) to the ipsec WG and cfrg chairs (David and Ran), Ted Tso (IPsec WG chair) proposed to bring up before the cfrg forum a crypto design issue in ikev2 that was raised over the ipsec list. I recommend that you read Ted's note. David (McGrew) answered that I should send this note to cfrg with an explanation of the issues. So this is what I am doing. "Executive summary:" ikev2 currently specifies the use of two different algorithms (or "transforms") with the same key. The IPsec chairs ask the cfrg to provide expert opinion on the need to change this specification (as I propose below). Now, a page long expansion of this summary for those who want more details. But before, let me say that I am really glad to see that this issue is being brought to the attention of the cfrg. I hope this is the first of an eventually long tradition of using this forum for validating (or de-validating) cryptographic designs needed/proposed/used by other WGs in the ietf. Specifically, Ted refers to a point I raised, in a msg to the ipsec list from Jan 13th, regarding a specification issue in ikev2. That msg is appended at the end of Ted's note (below). I consider the problem a no-brainer but the fact that it was not immediately accepted as an obvious and easy fix requires some explanation. Here is a succint statement of the problem. The current IKEv2 draft (ready for last call draft-ietf-ipsec-ikev2-12.txt) specifies the use of two DIFFERENT transforms, prf and integrity-algorithm, but also specifies keying them with the SAME key! The prf is used for key derivation as well as for the "mac" that the SIGMA design (SIGn-and-MAc) requires and for an additional mac in ikev2's password-based (or EAP-based) protocol. The second transform, the integrity-algorithm, is used for integrity purposes and is always computed on top of encrypted data (ciphertext); its functionality is to provide authenticated encryption (and CCA security). The obvious fix to this problem is to derive different keys for the different algorithms. Fortunately, this is easy in ikev2 which has a very modular key derivation procedure. All is needed is to derive two more keys (in addition to the 5 derived now) which will be used to key the prf (two keys to be consistent with "uni-directionality" of other keys in ikev2). This frees the already specified "authentication keys" (SK_ai and SK_ar) for exclusive use by the integrity algorithm. I am sure that I do not need to explain to the cfrg-fans the dangers of the (fundamentally wrong) practice of using the same key for two different algorithms. Nor do I think that the ipsec audience will disagree with that either. So the only question is whether there is any real cost associated with the proposed change. In this case, however, there is zero cost. No real specification or implementation complexity. No performance issue at all. No delay in advancing the document (a two-minute change to the draft). And no damage to implementations of ikev2 running in the marketplace since there are none (certainly not "standard-compliant" ones as this standard is not finalized). Finally, other solutions (such as unifying the prf and mac into a single transform) have more drawbacks than the trivial solutions of extracting two more keys in the key derivation process (currently there are 5 keys derived by this process). I do buy, however, Ted's argument that making last minute changes, especially to the cryptography is dangerous. This is why I welcome this request for advise from the cfrg. For those that follow the ipsec discussions there is enough material in that list about the issue. And for those that do not follow ipsec, then the problem does not require more description than what I wrote above (and further described in the appended message). In any case, just to make the point clear let me re-re-iterate the issue with some more detail: (1) The "integrity algorithm" and "prf" are different transforms in ikev2 (see section 3.3 of ikev2), and as such they are negotiated separately and therefore may be set to different algorithms. (2) In two applications of the prf function in ikev2 (sections 2.14 and 2.16) the prf function is keyed with a key (called SK_a) that is defined as a key to the integrity algorithm, not to the prf algorithm. (3) I propose that in addition to the 5 keys currently derived by the protocol (see sec 2.14), namely SK_d,SK_ai,SK_ar,SK_ei,SK_er, two more keys will be derived (called SK_pi,SK_pr) that will be used exclusively to key the prf in the above two applications. Let me also add: not only is the use of different algorithms with the same key an obvious cryptographic flaw, but also raises an operational issue since the keys required by the integrity and prf algorithms may have different size. FOR those who care: If all you have to say is that the need for this change is OBVIOUS, it may still be worth saying it (over the list). Hugo On Fri, 13 Feb 2004, Theodore Ts'o wrote: > > In a recent message, Steve Kent made the following statement: > > >When I last spoke with Russ, he indicated that he was prepared to > >tolerate another delay on the IKE v2 document to incorporate the > >change that Hugo suggested, to incorporate bits from an key-based EAP > >method into the PRF for the keys used for encryption & integrity. > > This presumably is referring to Hugo's proposal of January 13th, which > I've included below.On a recent concall of the IPSEC management team, > we discussed on how to handle this, given that (a) there has been no > response or discussion to Hugo's proposal on the mailing list to date, > and (b) a number of us get hives with the thought of making changes to > something as critical as IKEv2's cryptographic core at the last minute > without some adequate and thoughtful review. > > So we propose the following path forward.First, that we ask the Hugo > to clarify his objection.It appears to be mainly a certificational > weakness in that it may make it harder to prove correctness at least > when using normal crypto algorithms.Is this a fair characterization, > or is there a fundamental problem in normal usage? > > Secondly, we'd like to ask the Crypto Forum Research Group in the IRTF, > whose charter it is to provide a resource to IETF working group to > review uses of cryptographic mechanisms if they might be willing to give > us review of the current key agreement mechanisms found in sections > 2.14, 2.15, and 2.16 of draft-ietf-ipsec-ikev2-12.txt as well as the > proposed change by Hugo.Ran and David: Is this a good use of the CFRG, > and would you be willing to ask them to engage in this review? > > Based on the answers from Hugo and the CFRG, the working group will > hopefully have sufficient information in order to quickly come to > consensus about whether we need to make any changes to ikev2-12. > > Does this seem a reasonable way forward?I don't want to unduly prolong > an already very long process, but it seems to us that it is better to > put examine this issue and put it to rest now, instead of waiting until > Russ finishes reviewing the document (it is in his queue) and starts > IETF last call. > > - Ted > > ------------------ > > Date: Tue, 13 Jan 2004 22:10:50 +0200 (IST) > From: Hugo Krawczyk > Subject: Keing the prf > To: Theodore Ts'o > cc: Russ Housley , byfraser@cisco.com, > Charlie Kaufman , > IPsec WG > > There is one issue that was subject of discussion in the last weeks and I > believe requires a better resolution. I refer to the problem that ikev2 > (including -12) defines two uses of the prf function (in sections 2.15 and > 2.16)where the prf is keyed with SK_a. This is problematic since SK_a is > defined as a key to the "integrity algorithm" which may be different than > the prf. Indeed the integrity algorithm and prf have different transform > types (#3 and #2) respectively, and then are negotiated independetly (in > particular they may usedifferent algorihms). > > Why is this a problem? > > First, because the two transforms may require keys of different lengths, > in particular SK_a may be too short to key the prf. > > Second, it is a wrong cryptographic practice to use the same key with two > different algorithms. This may or may not translate into actual attacks, > but it certainly spoils the otherwise sound design of the protocol. > It will also invite "attacks" from future formal analysts (beyond the > operational issues referred to in the first item). > > I believe that the problem is best solved by deriving an additional pair > of keys from SKEYSEED (call them SK_pi and SK_pr) for keying the prf in the > above two cases. It is certainly easy to specify and to implement > (and easier than to justify why this wasn't done). > > Specifically add the pair SK_pi, SK_pr to the key derivation formula in > 2.14. Change prf(SK_ar,IDr') to prf(SK_pr,IDr') and prf(SK_ai,IDr') to > prf(SK_pi,IDr') in section 2.15. Change "SK_ai and SK_ar" in the next to > last paragraph of section 2.16 with "SK_pi and SK_pr" > > I suggest that this be solved before the official last call (otherwise you > can see this as a comment provided in the last call phase). > > Hugo > From owner-ipsec@lists.tislabs.com Wed Feb 18 13:39:18 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1ILdHXj015484; Wed, 18 Feb 2004 13:39:17 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20471 Wed, 18 Feb 2004 15:58:54 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16435.54420.9150.565275@fireball.acr.fi> Date: Wed, 18 Feb 2004 23:09:40 +0200 From: Tero Kivinen To: Charles Lynn Cc: ipsec@lists.tislabs.com Subject: Re: Some IKEv2 issues In-Reply-To: <20040217200214.A42B020520@wolfe.bbn.com> References: <16434.27900.199285.136682@fireball.acr.fi> <20040217200214.A42B020520@wolfe.bbn.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 4 min X-Total-Time: 4 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charles Lynn writes: > > 2) Say how OPAQUE is encoded (start = max, end = min ???) > > > in point 2, I think it should be start = min, end = max, not other > > way around > > start = min, end = max is the encoding for ANY. OPAQUE and ANY are > not the same. OPAQUE means the value of a field cannot be determined, > either because the protocol does not have it, or it is hidden by > encryption or fragmentation. >From the responder side of view, what is the actual implemenation difference between OPAQUE and ANY? I think they will be processed identically in the implementations. There are semantic differences in some cases, but I do not think that any implementations actually need to know the difference on the packet processing level, thus I think we should simply have one format of expressing that instead of having special case for OPAQUE. The IKEv2 draft does not make difference between any and opaque, and I think that is fine. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Wed Feb 18 13:39:35 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1ILdYnm015502; Wed, 18 Feb 2004 13:39:34 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19999 Wed, 18 Feb 2004 15:54:00 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16435.54169.842058.268157@fireball.acr.fi> Date: Wed, 18 Feb 2004 23:05:29 +0200 From: Tero Kivinen To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: Re: IANA assignment policies In-Reply-To: <15123.1077047999@marajade.sandelman.ottawa.on.ca> References: <16434.22666.257287.681344@fireball.acr.fi> <15123.1077047999@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 2 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson writes: > Tero> For the "IKEv2 Extended Sequence Numbers Transform IDs" registry > Tero> the base ikev2 draft says that 2-65536 is reserved, but initial > Tero> iana registry document says reserved to IANA (and no private use > Tero> range). > "Reserved" means what vs "Reserved to IANA" ? I think if it says Reserved to IANA, then IANA can allocate entries from that area, but if it simply says Reserved (as it says for most tables for value 0), it means that numbers are reserved and cannot be allocated. I was mostly pointing out that in other places it says Reserved for IANA and here it didn't (i.e. the documents are inconsistent), so the base document should be fixed to have Reserved for IANA too. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Wed Feb 18 13:54:32 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1ILsVsj016028; Wed, 18 Feb 2004 13:54:32 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA22548 Wed, 18 Feb 2004 16:18:16 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16435.55623.26827.859229@fireball.acr.fi> Date: Wed, 18 Feb 2004 23:29:43 +0200 From: Tero Kivinen To: Charles Lynn Cc: ipsec@lists.tislabs.com Subject: SAs that carry fragments Was: Re: Some IKEv2 issues In-Reply-To: <20040218161436.9707F2051E@wolfe.bbn.com> References: <16434.27900.199285.136682@fireball.acr.fi> <20040218161436.9707F2051E@wolfe.bbn.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 7 min X-Total-Time: 7 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charles Lynn writes: > > 4) Fragment only SA, and non-initial fragments > > point 4 should be left out, as fragment only SAs (issue 81 and 49) > > in RFC 2401 was rejected, i.e. there is no need to change anything > > in the IKEv2 document because of that] > > My understanding was that the WG rejected the proposal of creating a > special SA that *only* carried non-initial fragments, not that the > WG rejected affording fragments (other than IPv4 in transport mode) > IPsec protection. True, but there is no need to have any special handing for them, if the IP addresses of fragment match the traffic selectors of the SA, then the packet can be sent there. I.e the first fragments, non-first fragments and full packets all share the same SA. > The issue that has to be resolved is how fragments are identified (a > local issue) and communicated using IKEv2's Traffic Selector > mechanism. Fragments can then be directed to *an appropriate SA* that > is, or may be, carrying other, not-fragmented, traffic. > > Since the transport layer selectors are not available in fragments, > they are OPAQUE. Thus fragments of TCP packets between A and B could > be specified as: Or, it can be said that those packets can only be sent to the SA having transport layer selectors of ANY (i.e. if it takes any port range, then it should also accept fragments which match the protocol even when they actual packet does not have the port numbers in it). > I think that the IKEv2 document needs to specify which encoding, one > of the above or something someone else suggests, MUST be used to > enable interoperability. I think it should use: TS { TSi { ... {IP=A, Protocol=TCP, Port=ANY(start=0,end=65535)} ... } TSr { ... {IP=B, Protocol=TCP, Port=ANY} ... } } -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Wed Feb 18 14:12:39 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1IMCctI017055; Wed, 18 Feb 2004 14:12:39 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24003 Wed, 18 Feb 2004 16:38:08 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <16435.54169.842058.268157@fireball.acr.fi> References: <16434.22666.257287.681344@fireball.acr.fi> <15123.1077047999@marajade.sandelman.ottawa.on.ca> <16435.54169.842058.268157@fireball.acr.fi> Date: Wed, 18 Feb 2004 13:49:53 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: IANA assignment policies Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Reserved for IANA" is a silly and confusing convention that early IPsec documents used. Everything is reserved for IANA that is not allocated, yes? Having "reserved" meaning "IANA should never allocate" and "reserved for IANA" meaning "IANA should allocate" is bound to end up in tears. Drop all the "reserved for IANA" strings. Any developer who really cares can figure out what the last available number in a range is. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Feb 19 08:41:20 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1JGfJ2O062828; Thu, 19 Feb 2004 08:41:20 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA29753 Thu, 19 Feb 2004 10:58:00 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16435.55623.26827.859229@fireball.acr.fi> References: <16434.27900.199285.136682@fireball.acr.fi> <20040218161436.9707F2051E@wolfe.bbn.com> <16435.55623.26827.859229@fireball.acr.fi> Date: Thu, 19 Feb 2004 11:09:20 -0500 To: Tero Kivinen From: Stephen Kent Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues Cc: Charles Lynn , 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 Tero, In 2401, and so far in 2401bis, we have distinguished between ANY and OPAQUE. if we decide to continue to do that, then at a minimum, we would not consider a fragment with no port fields to match an SA that allowed traffic with ANY as the value for port fields. Also, If an IPsec implementation has two SA between the same source/dest address pairs, and with the same protocol value(s), but distinguished traffic based on specific (vs. ANY) port fields, then a non-initial fragment cannot be mapped to either SA unambiguously. An analogous problem arises if there is just one, extant SA that matches the addresses and protocol, and we are forced to search the SPD to see if another SA might be appropriate. These observations motivate use of a separate SA to carry fragments, right? Steve From owner-ipsec@lists.tislabs.com Thu Feb 19 09:19:06 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1JHJ5tU064916; Thu, 19 Feb 2004 09:19:05 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05054 Thu, 19 Feb 2004 11:43:13 -0500 (EST) From: Charles Lynn To: Tero Kivinen Cc: ipsec@lists.tislabs.com, Charles Lynn Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues In-Reply-To: <16435.55623.26827.859229@fireball.acr.fi> Message-Id: <20040219165444.DA6FB2051E@wolfe.bbn.com> Date: Thu, 19 Feb 2004 11:54:44 -0500 (EST) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero, > > I think that the IKEv2 document needs to specify which encoding, one > > of the above or something someone else suggests, MUST be used to > > enable interoperability. > > I think it should use: > > TS { > TSi { ... > {IP=A, Protocol=TCP, Port=ANY(start=0,end=65535)} > ... > } > TSr { ... > {IP=B, Protocol=TCP, Port=ANY} > ... > } > } Is the consequence of such an encoding, i.e., that the default "DROP" rule at the end of the SPD, loses much of its usefulness intentional? I.e., such a rule would let any TCP packets go through. Thus if one anted to only allow, say TCP to port 22, including any fragments, then the admin would have to insert a rule explicitly saying that ports 0 to 21 and 23 to 65535 should be DROP'ed. It gets a lot worse if multiple ports are allowed. I think that the encoding you propose will result in more SPD configuration errors and make IPsec harder to manage. Charlie From owner-ipsec@lists.tislabs.com Thu Feb 19 09:24:48 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1JHOlMV065155; Thu, 19 Feb 2004 09:24:48 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05420 Thu, 19 Feb 2004 11:45:21 -0500 (EST) From: "Bora Akyol" To: "'Tero Kivinen'" , "'Stephen Kent'" Cc: "'Theodore Ts'o'" , Subject: RE: Issue #83: Generation of ICMP responses for inbound packet requiring IPSEC protection Date: Thu, 19 Feb 2004 08:56:38 -0800 Message-ID: <00b401c3f709$579c4010$060a0a0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <16434.24291.254422.111128@fireball.acr.fi> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If such an ICMP message is added, then the rate limiting feature for this message must be a MUST requirement and should not be left to the administrator. One can not expect people that do not update virus definitions to configure IPSEC related ICMP message rates. Regards, Bora From owner-ipsec@lists.tislabs.com Thu Feb 19 11:09:39 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1JJ9cJJ072816; Thu, 19 Feb 2004 11:09:39 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12745 Thu, 19 Feb 2004 13:29:55 -0500 (EST) From: "Bora Akyol" To: "'Stephen Kent'" , "'Tero Kivinen'" , "Barbara Fraser" Cc: "'Charles Lynn'" , Subject: RE: SAs that carry fragments Was: Re: Some IKEv2 issues Date: Thu, 19 Feb 2004 10:41:38 -0800 Message-ID: <00b901c3f718$02aaa740$060a0a0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve How often do we see multiple IPSEC Sas between the same two peers protecting different ports (or in general different selector sets)? There are better and straightforward ways of getting around the issue of fragmented packets in the implementation without requiring a separate SA for fragments. As a side-note, configuring even the most basic traffic selectors in some host OS that are widely-deployed is a big chore (really hit-and-miss). The most deployed IPSEC scenarios supporting road warriors don't even use a traffic selector at the head-end. Regards, Bora > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Stephen Kent > Sent: Thursday, February 19, 2004 8:09 AM > To: Tero Kivinen > Cc: Charles Lynn; ipsec@lists.tislabs.com > Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues > > > Tero, > > In 2401, and so far in 2401bis, we have distinguished between ANY and > OPAQUE. if we decide to continue to do that, then at a minimum, we > would not consider a fragment with no port fields to match an SA that > allowed traffic with ANY as the value for port fields. > > Also, If an IPsec implementation has two SA between the same > source/dest address pairs, and with the same protocol value(s), but > distinguished traffic based on specific (vs. ANY) port fields, then a > non-initial fragment cannot be mapped to either SA unambiguously. An > analogous problem arises if there is just one, extant SA that matches > the addresses and protocol, and we are forced to search the SPD to > see if another SA might be appropriate. These observations motivate > use of a separate SA to carry fragments, right? > > > Steve > From owner-ipsec@lists.tislabs.com Thu Feb 19 11:32:44 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1JJWcew073951; Thu, 19 Feb 2004 11:32:44 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15279 Thu, 19 Feb 2004 13:53:58 -0500 (EST) Date: Thu, 19 Feb 2004 13:04:40 -0600 From: Nicolas Williams To: Bora Akyol Cc: "'Stephen Kent'" , "'Tero Kivinen'" , Barbara Fraser , "'Charles Lynn'" , ipsec@lists.tislabs.com Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues Message-ID: <20040219190440.GB5175@binky.central.sun.com> Mail-Followup-To: Bora Akyol , 'Stephen Kent' , 'Tero Kivinen' , Barbara Fraser , 'Charles Lynn' , ipsec@lists.tislabs.com References: <00b901c3f718$02aaa740$060a0a0a@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00b901c3f718$02aaa740$060a0a0a@amer.cisco.com> User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Feb 19, 2004 at 10:41:38AM -0800, Bora Akyol wrote: > Steve > > How often do we see multiple IPSEC Sas between the same two peers > protecting different ports (or in general different selector sets)? Consider cases where one peer is a multi-user system and different connections are protected by [likely transport-mode] SAs with different IDs for different users. I would not want such scenarios to be precluded. > There are better and straightforward ways of getting around the > issue of fragmented packets in the implementation > without requiring a separate SA for fragments. Delay policy evaluation until fragmented packets are reassembled? This might be fine for transport mode SAs [but not for tunnel mode SAs?]. Queue fragmented packets for reassembly remembering what SA protected each fragment, then when the packet is reassembled, and if all fragments were protected by the same or congruent SAs check SPD, otherwise drop. Nico -- From owner-ipsec@lists.tislabs.com Thu Feb 19 11:44:53 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1JJiqgq074592; Thu, 19 Feb 2004 11:44:52 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA17091 Thu, 19 Feb 2004 14:10:38 -0500 (EST) From: "Bora Akyol" To: "'Nicolas Williams'" Cc: "'Stephen Kent'" , "'Tero Kivinen'" , "'Barbara Fraser'" , "'Charles Lynn'" , Subject: RE: SAs that carry fragments Was: Re: Some IKEv2 issues Date: Thu, 19 Feb 2004 11:22:22 -0800 Message-ID: <00c101c3f71d$b34fa780$060a0a0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <20040219190440.GB5175@binky.central.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks for the comments, please see inline. > -----Original Message----- > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com] > Sent: Thursday, February 19, 2004 11:05 AM > To: Bora Akyol > Cc: 'Stephen Kent'; 'Tero Kivinen'; Barbara Fraser; 'Charles > Lynn'; ipsec@lists.tislabs.com > Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues > > > On Thu, Feb 19, 2004 at 10:41:38AM -0800, Bora Akyol wrote: > > Steve > > > > How often do we see multiple IPSEC Sas between the same two peers > > protecting different ports (or in general different selector sets)? > > Consider cases where one peer is a multi-user system and > different connections are protected by [likely > transport-mode] SAs with different IDs for different users. > I would not want such scenarios to be precluded. > And they don't need to be, I just think that creating a separate SA for the fragments is unnecessary. How to handle fragments is a topic better left to the implementer. Current IKE semantics allow this granularity BTW. OTOH, I think implementing the functionality you specify above in a multi-user kernel would be quite the challenge :-) Sounds like an excellent project indeed. Bora From owner-ipsec@lists.tislabs.com Thu Feb 19 12:16:33 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1JKGVQa076901; Thu, 19 Feb 2004 12:16:33 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21273 Thu, 19 Feb 2004 14:39:59 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <00b901c3f718$02aaa740$060a0a0a@amer.cisco.com> References: <00b901c3f718$02aaa740$060a0a0a@amer.cisco.com> Date: Thu, 19 Feb 2004 14:39:33 -0500 To: "Bora Akyol" From: Stephen Kent Subject: RE: SAs that carry fragments Was: Re: Some IKEv2 issues Cc: "'Tero Kivinen'" , "Barbara Fraser" , "'Charles Lynn'" , 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 10:41 -0800 2/19/04, Bora Akyol wrote: >Steve > >How often do we see multiple IPSEC Sas between the same two peers >protecting different ports (or in general different selector sets)? I don't know, but I do know that we have mandated the ability to support this for over 5 years. >There are better and straightforward ways of getting around the >issue of fragmented packets in the implementation >without requiring a separate SA for fragments. what are they and why are they better? >As a side-note, configuring even the most basic traffic selectors in >some host OS that are widely-deployed is a big chore (really >hit-and-miss). >The most deployed IPSEC scenarios supporting road warriors don't even >use a traffic >selector at the head-end. I am aware of at least one very poor, definitely non-conforming, management UI for a widely deployed IPsec implementation. But I don't think that a vendor's failures in this area ought to dictate our standards going forward. Steve From owner-ipsec@lists.tislabs.com Thu Feb 19 12:32:29 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1JKWSxn077609; Thu, 19 Feb 2004 12:32:29 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21783 Thu, 19 Feb 2004 14:56:38 -0500 (EST) From: "Bora Akyol" To: "'Stephen Kent'" Cc: "'Tero Kivinen'" , "'Barbara Fraser'" , "'Charles Lynn'" , Subject: RE: SAs that carry fragments Was: Re: Some IKEv2 issues Date: Thu, 19 Feb 2004 12:07:17 -0800 Message-ID: <00c301c3f723$fa3577f0$060a0a0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thank you for your comments, please see inline > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Thursday, February 19, 2004 11:40 AM > To: Bora Akyol > Cc: 'Tero Kivinen'; Barbara Fraser; 'Charles Lynn'; > ipsec@lists.tislabs.com > Subject: RE: SAs that carry fragments Was: Re: Some IKEv2 issues > > > At 10:41 -0800 2/19/04, Bora Akyol wrote: > >Steve > > > >How often do we see multiple IPSEC Sas between the same two peers > >protecting different ports (or in general different selector sets)? > > I don't know, but I do know that we have mandated the ability to > support this for over 5 years. > Yes, and people have figured ways of supporting this without needing separate SAs for fragments. > >There are better and straightforward ways of getting around > the issue > >of fragmented packets in the implementation without requiring a > >separate SA for fragments. > > what are they and why are they better? > I think in an earlier email Nicolas gave some examples of how this can be achieved and it can achieved efficiently without actually doing copies etc. Oh, they are better because they don't double the effective number of SAs that will be used for communication. For example, if I can currently support 1,000,000 IPSEC SA pairs (tunnels), then by having a separate SA pair for fragments is going to cut my capacity in half. This is a big loss. > >As a side-note, configuring even the most basic traffic selectors in > >some host OS that are widely-deployed is a big chore (really > >hit-and-miss). The most deployed IPSEC scenarios supporting road > >warriors don't even use a traffic > >selector at the head-end. > > I am aware of at least one very poor, definitely non-conforming, > management UI for a widely deployed IPsec implementation. But I > don't think that a vendor's failures in this area ought to dictate > our standards going forward. > No, but the standards should be simple, clear and easy to implement. Adding features that improve the protocol coverage by 0.01% while increasing code complexity by 1-3% is hardly worth the effort. Speaking from an implementor's perspective, I think we should aim to cut rarely used features off existing IPSEC standards as opposed to adding to the feature set. Generality is good but it comes at a cost of implementation complexity, interoperability problems and deployment headaches. I think the traffic selectors and their broad flexibility is one of these features. For example just by cutting port based selectors for TCP and UDP, cost of doing security policy checks goes down exponentially for most software and linearly for most HW. This has huge scalability benefits if ever IPSEC is going to get widely deployed. I am sure at some point before the 2401bis and IKE V2 efforts were under way, there must have been a deployment survey performed. If that is the case, then we should look at that and cut the features that are not used at all, cut features that are rarely used and agree on a core set of features and specify these clearly from both protocol and management perspectives. Regards, Bora From owner-ipsec@lists.tislabs.com Thu Feb 19 13:01:03 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1JL12qE079164; Thu, 19 Feb 2004 13:01:02 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23000 Thu, 19 Feb 2004 15:27:17 -0500 (EST) From: Charles Lynn To: "Bora Akyol" Cc: kent@bbn.com, kivinen@iki.fi, byfraser@cisco.com, clynn@bbn.com, ipsec@lists.tislabs.com Subject: RE: SAs that carry fragments Was: Re: Some IKEv2 issues In-Reply-To: <00c301c3f723$fa3577f0$060a0a0a@amer.cisco.com> Message-Id: <20040219203858.137382051E@wolfe.bbn.com> Date: Thu, 19 Feb 2004 15:38:58 -0500 (EST) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Bora, Maybe you missed some of the earlier emails... > >There are better and straightforward ways of getting around the issue > >of fragmented packets in the implementation without requiring a > >separate SA for fragments. The WG rejected the idea of a *separate* SA for fragments. We are now talking about how to indicate that an existing SA should be used to carry fragments, that is interoperable (can be communicated via IKEv2) so that the packets the sending implementation puts into the SA will be consistent with the receiver's access control policy (SA). How the sending implementation figures out that a packet is a fragment is a local matter. > I think in an earlier email Nicolas gave some examples of how this > can be achieved ... > > There are better and straightforward ways of getting around the > > issue of fragmented packets in the implementation > > without requiring a separate SA for fragments. > Delay policy evaluation until fragmented packets are reassembled? This > might be fine for transport mode SAs [but not for tunnel mode SAs?]. It requires memory in, e.g., a security gateway, code to do fragmentation and reassembly, and makes it harder to keep up with line rate. > Queue fragmented packets for reassembly remembering what SA protected > each fragment, then when the packet is reassembled, and if all fragments > were protected by the same or congruent SAs check SPD, otherwise drop. Is this at the sending end of the IPsec channel or the receiving? I.e., "what SA protected each fragment" sounds like the receiver. If the fragments got that far, a solution that protects fragments is assumed, but not identified. > and it can achieved efficiently without actually doing copies etc. > they are better because they don't double the effective number of > SAs that will be used for communication. For example, if I can > currently support 1,000,000 IPSEC SA pairs (tunnels), then by having > a separate SA pair for fragments is going to cut my capacity in > half. This is a big loss. The suggestion I made does not require any copies, and dos not double the number of SAs. > No, but the standards should be simple, clear and easy to > implement. Agreed. > Adding features that improve the protocol coverage by 0.01% while > increasing code complexity by 1-3% is hardly worth the effort. Where did you get these numbers? > I think we should aim to cut rarely used features off existing IPSEC > standards as opposed to adding to the feature set. Generality is > good but it comes at a cost of implementation complexity, > interoperability problems and deployment headaches. Not always. > I think the traffic selectors and their broad flexibility is one of > these features. For example just by cutting port based selectors > for TCP and UDP, cost of doing security policy checks goes down > exponentially for most software and linearly for most HW. This has > huge scalability benefits if ever IPSEC is going to get widely > deployed. Well, not using port selectors might make sense for VPNs, but IPsec is designed for more than just VPNs. > I am sure at some point before the 2401bis and IKE V2 efforts were > under way, there must have been a deployment survey performed. If > that is the case, then we should look at that and cut the features > that are not used at all, cut features that are rarely used and > agree on a core set of features and specify these clearly from both > protocol and management perspectives. That sort of assumes that past usage is a good predictor of future use. I think that the Internet has proven that not to be the case more than once. Charlie From owner-ipsec@lists.tislabs.com Thu Feb 19 13:22:40 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1JLMdWa081233; Thu, 19 Feb 2004 13:22:40 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA25524 Thu, 19 Feb 2004 15:48:08 -0500 (EST) Message-Id: <200402192018.i1JKIc74004738@thunk.east.sun.com> From: Bill Sommerfeld To: "Bora Akyol" cc: "'Stephen Kent'" , "'Tero Kivinen'" , "'Barbara Fraser'" , "'Charles Lynn'" , ipsec@lists.tislabs.com Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues In-Reply-To: Your message of "Thu, 19 Feb 2004 12:07:17 PST." <00c301c3f723$fa3577f0$060a0a0a@amer.cisco.com> Reply-to: sommerfeld@east.sun.com Date: Thu, 19 Feb 2004 15:18:38 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > For example just by cutting port based selectors for TCP and UDP, > cost of doing security policy checks goes down exponentially for > most software and linearly for most HW. say what? not in all implementations it doesn't.. - Bill From owner-ipsec@lists.tislabs.com Thu Feb 19 13:26:42 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1JLQfPJ081583; Thu, 19 Feb 2004 13:26:42 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26346 Thu, 19 Feb 2004 15:54:53 -0500 (EST) Date: Thu, 19 Feb 2004 15:06:08 -0600 From: Nicolas Williams To: Charles Lynn Cc: Bora Akyol , kent@bbn.com, kivinen@iki.fi, byfraser@cisco.com, ipsec@lists.tislabs.com Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues Message-ID: <20040219210608.GF5175@binky.central.sun.com> Mail-Followup-To: Charles Lynn , Bora Akyol , kent@bbn.com, kivinen@iki.fi, byfraser@cisco.com, ipsec@lists.tislabs.com References: <00c301c3f723$fa3577f0$060a0a0a@amer.cisco.com> <20040219203858.137382051E@wolfe.bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040219203858.137382051E@wolfe.bbn.com> User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Feb 19, 2004 at 03:38:58PM -0500, Charles Lynn wrote: > > Delay policy evaluation until fragmented packets are reassembled? This > > might be fine for transport mode SAs [but not for tunnel mode SAs?]. > > It requires memory in, e.g., a security gateway, code to do > fragmentation and reassembly, and makes it harder to keep up with line > rate. Which is why I thought this would be fine for transport-mode scenarios but maybe not for tunnel-mode. Of course, in the case of SGs there's likely to be very few live SAs per client, so this may be a non-issue. I'm not up on the whole thread, so I'll go back to lurking now. I just wanted to make sure that multi-user peers w/ transport mode SAs remained workable. Nico -- From owner-ipsec@lists.tislabs.com Thu Feb 19 13:29:12 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1JLTBVg081710; Thu, 19 Feb 2004 13:29:11 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26500 Thu, 19 Feb 2004 15:56:20 -0500 (EST) From: "Bora Akyol" To: "'Charles Lynn'" Cc: Subject: RE: SAs that carry fragments Was: Re: Some IKEv2 issues Date: Thu, 19 Feb 2004 13:07:57 -0800 Message-ID: <00c801c3f72c$733ac940$060a0a0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <20040219203858.137382051E@wolfe.bbn.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks Charlie, please see in-line. > The WG rejected the idea of a *separate* SA for fragments. > > We are now talking about how to indicate that an existing SA > should be used to carry fragments, that is interoperable (can > be communicated via IKEv2) so that the packets the sending > implementation puts into the SA will be consistent with the > receiver's access control policy (SA). Just like the sender can handle the fragments without requiring a separate SA, the receiver can also handle the fragments without a flag that says this SA carries fragments, please let them pass without checking SP. This IMHO, looks too much like a hole that someone will eventually exploit for some reason. Is this what the opaque stuff is about? And isn't all of this stuff considered unnecessary with IPv6? > > It requires memory in, e.g., a security gateway, code to do > fragmentation and reassembly, and makes it harder to keep up > with line rate. > Yes, more buffers may be required, but not that much harder to keep up with line rate at the sender or receiver. Especially in the scenarios that have been given on this thread which are mostly host, this should not be an issue. > > Queue fragmented packets for reassembly remembering what SA > protected > > each fragment, then when the packet is reassembled, and if all > > fragments were protected by the same or congruent SAs check SPD, > > otherwise drop. > > Is this at the sending end of the IPsec channel or the > receiving? I.e., "what SA protected each fragment" sounds > like the receiver. If the fragments got that far, a solution > that protects fragments is assumed, but not identified. > I noticed this too, the conversation that I am interested in is in the sender. > > The suggestion I made does not require any copies, and dos > not double the number of SAs. > > > No, but the standards should be simple, clear and easy to implement. > > Agreed. > Thanks. > > Adding features that improve the protocol coverage by 0.01% while > > increasing code complexity by 1-3% is hardly worth the effort. > > Where did you get these numbers? > The numbers were an example based on my software engineering expertise. Most bugs that I have seen come from corner cases or rarely used features that one almost never sees in the field. In order to support these features, the code bloats, ... I can go on and on about this. > > I think we should aim to cut rarely used features off > existing IPSEC > > standards as opposed to adding to the feature set. > Generality is good > > but it comes at a cost of implementation complexity, > interoperability > > problems and deployment headaches. > > Not always. > > > I think the traffic selectors and their broad flexibility is one of > > these features. For example just by cutting port based > selectors for > > TCP and UDP, cost of doing security policy checks goes down > > exponentially for most software and linearly for most HW. This has > > huge scalability benefits if ever IPSEC is going to get widely > > deployed. > > Well, not using port selectors might make sense for VPNs, but > IPsec is designed for more than just VPNs. > How does a policy maker (say an IT mgr) decides that port 8001 is more valuable than port 8002. And what happens to the renagade user that runs a web server on port 16032? This is precisely why the TCP/UDP port based selector spefication is more eye candy than anything. The kernels today allow so much flexibility on what application can bind to what ports that it does not make sense to secure one application in a different manner than another. They should ALL be equally secure. Otherwise, this one clueless insider will find the port that is being secured by DES and set-up the most critical infrastructure on that port. > > I am sure at some point before the 2401bis and IKE V2 efforts were > > under way, there must have been a deployment survey > performed. If that > > is the case, then we should look at that and cut the > features that are > > not used at all, cut features that are rarely used and > agree on a core > > set of features and specify these clearly from both protocol and > > management perspectives. > > That sort of assumes that past usage is a good predictor of > future use. I think that the Internet has proven that not to > be the case more than once. > OTOH, IETF requires a deployment study before an RFC becomes an STD, if I remember correctly. I always find it worthwhile to look at what's in the field and then prioritize work accordingly. So if I were writing the traffic selector spefications, I would write them in an extensible format based on the following: IP DA, SA, IP proto are on by default for v4 and v6. Then there are optional selectors defined by offset from the end of a well known field (say IP version number) and field length. They could mean anything. This way one can get as specific as they want, but most common uses will get the simplest possible implementation. This type of field selector specification is used frequently in network processor designs where such a lookup would be a single instruction. Bora From owner-ipsec@lists.tislabs.com Thu Feb 19 14:48:40 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1JMmdfm087509; Thu, 19 Feb 2004 14:48:39 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA05178 Thu, 19 Feb 2004 17:10:13 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <00c301c3f723$fa3577f0$060a0a0a@amer.cisco.com> References: <00c301c3f723$fa3577f0$060a0a0a@amer.cisco.com> Date: Thu, 19 Feb 2004 17:16:51 -0500 To: "Bora Akyol" From: Stephen Kent Subject: RE: SAs that carry fragments Was: Re: Some IKEv2 issues Cc: "'Tero Kivinen'" , "'Barbara Fraser'" , "'Charles Lynn'" , 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:07 -0800 2/19/04, Bora Akyol wrote: >Thank you for your comments, please see inline > >> -----Original Message----- >> From: Stephen Kent [mailto:kent@bbn.com] >> Sent: Thursday, February 19, 2004 11:40 AM >> To: Bora Akyol >> Cc: 'Tero Kivinen'; Barbara Fraser; 'Charles Lynn'; >> ipsec@lists.tislabs.com >> Subject: RE: SAs that carry fragments Was: Re: Some IKEv2 issues >> >> >> At 10:41 -0800 2/19/04, Bora Akyol wrote: >> >Steve >> > >> >How often do we see multiple IPSEC Sas between the same two peers >> >protecting different ports (or in general different selector sets)? >> >> I don't know, but I do know that we have mandated the ability to >> support this for over 5 years. >> > >Yes, and people have figured ways of supporting this >without needing separate SAs for fragments. your said "ways" which is plural. It's not enough for a vendor to decide how to map a fragment to an SA, since the receiver is supposed to check each received packet against the selectors for the SA via which it is received. So, if there is ONE way to do this, and everybody already does it, and if it accommodates all the possible SA configurations that a compliant implementation MUST support, then we should just describe that way in 2401bis. But, what I fear you are indicating is that different vendors have different ways of accommodating fragments, and that these may not be common, which means that interoperability problems may (will) occur, OR that not all possible SA configurations will work. if so, then we need to fix this situation. > >> >There are better and straightforward ways of getting around >> the issue >> >of fragmented packets in the implementation without requiring a >> >separate SA for fragments. >> >> what are they and why are they better? >> > >I think in an earlier email Nicolas gave some examples of how this can >be achieved and it can achieved efficiently without actually >doing copies etc. Oh, they are better because they don't double the >effective number >of SAs that will be used for communication. >For example, if I can currently support 1,000,000 IPSEC SA pairs >(tunnels), >then by having a separate SA pair for fragments is going to cut my >capacity >in half. This is a big loss. your example seems a bit vague in some details, but I refer you to Charlie's message for this discussion. > > >As a side-note, configuring even the most basic traffic selectors in >> >some host OS that are widely-deployed is a big chore (really >> >hit-and-miss). The most deployed IPSEC scenarios supporting road >> >warriors don't even use a traffic >> >selector at the head-end. >> >> I am aware of at least one very poor, definitely non-conforming, >> management UI for a widely deployed IPsec implementation. But I >> don't think that a vendor's failures in this area ought to dictate >> our standards going forward. >> > >No, but the standards should be simple, clear and easy to implement. >Adding >features that improve the protocol coverage by 0.01% while increasing >code >complexity by 1-3% is hardly worth the effort. it's easy to make a contrast like that, but it's harder to justify the numbers. >Speaking from an implementor's perspective, >I think we should aim to cut rarely used features off existing IPSEC >standards >as opposed to adding to the feature set. Generality is good but it comes >at >a cost of implementation complexity, interoperability problems and >deployment headaches. >I think the traffic selectors and their broad flexibility is one of >these features. >For example just by cutting port based selectors for TCP and UDP, >cost of doing security policy checks goes down exponentially for most >software >and linearly for most HW. This has huge scalability benefits if ever >IPSEC is >going to get widely deployed. >I am sure at some point before the 2401bis and IKE V2 efforts were under >way, >there must have been a deployment survey performed. If that is the case, >then we should look at that and cut the features that are not used at >all, >cut features that are rarely used and agree on a core set of features >and >specify these clearly from both protocol and management perspectives. > >Regards, > >Bora Sorry, but I cannot agree with your suggested approach to deciding what is and is not important for any standard. What is and is not used in current deployments may be a good measure of what folks need, or is may be an artifact of limits imposed by current implementations, etc. We have removed some features from IPsec that were complex and not widely used. in the selector area we have added support for ICMP because folks asked for it. we added the ability to map multiple distinct protocols to an SA to reduce the number of SAs, without loosing security functionality. Steve From owner-ipsec@lists.tislabs.com Fri Feb 20 05:07:21 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KD7K00001224; Fri, 20 Feb 2004 05:07:21 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA21272 Fri, 20 Feb 2004 07:29:39 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16438.75.875878.718798@fireball.acr.fi> Date: Fri, 20 Feb 2004 14:40:43 +0200 From: Tero Kivinen To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: Re: Issue #83: Generation of ICMP responses for inbound packet requiring IPSEC protection In-Reply-To: References: <20040130232243.GA6423@thunk.org> <16434.24291.254422.111128@fireball.acr.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 14 min X-Total-Time: 18 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > So, if we don't adopt this proposal, each inbound, non-IPsec packet > that does not match an explicit bypass OR drop entry in the SPI-I > cache, triggers a check of the SPD-I. But if we adopt the proposal, > then every packet that is dropped, even if in response to an explicit > SPD-I cache entry, requires an SPD-S search. Or the SPD-I cache entry can have information whether the ICMP will need to be sent or not. > you are right, in that I misunderstood the proposal. The searches are > triggered only for dropped traffic. But, that still imposes an > additional burden, as noted above. also, the proposed text requires > that we be prepared to send an ICMP. At this point the proposed text > has allowed an attacker to cause a receiver to do a lot more work > than we currently do, and it could even turn the receiver into a DoS > source, by having it generate ICMP messages based on bogus source IP > addresses. Yes, the text called for this to be configurable, but we > should be aware that this allows a careless admin at site A to turn > his IPsec device into an ICMP generator that will affect Site C, > which strikes me as a bad idea, in general. Thats why the sending of ICMP (or any other error messages) must be rate limited (not per entry/peer, but per gateway), and the rate limit must be configurable. The careless admin can do quite a lot of other things, he might even have boxes root password as "root" and allow attackers to use the machine as an attack box :-) I do not think we can protect the careless adminstrators compeltely. We as an implementators can but sensible defaults to those limits, and for example disallow setting the limit too high (i.e. set the maximum limit which can be configured to 10 ICMP messages / second and default to 1 ICMP message / second). > I do not understand your example. How does one specify an SPD entry > that says put this traffic on an SA IF the SA exists, but don't > create one otherwise and just send the traffic in the clear? This is the setup which is mostly used for opportunistic cases, i.e. if you have SA up you use it, if you don't you can send the traffic clear, or you can even try to create SA, and if it fails you send it in clear. This kind of setup can be used for normal web-traffic etc, where you actually do not normally need to create IPsec SAs, but if you happen to have SA up, you can use it (it does not cause any harm either). > I don't > think the SPD has ever been described in a way that would allow such > behavior. Might be true, but there are implemenations which support this kind of operations. > >If we get ICMP in those cases it will be clear from the Host B side > >that when the adminstrator sees from the logs that it have received > >ICMP telling that communication adminstratively prohibited that there > >is something wrong with setup, not in the network (which usually is > >the first one to blame in this cases). > > But the admin can't trust the source address for the ICMP messages, > so if he acts on them he is subject to spoofing. I agree that under > the right circumstances this feature could be a debugging aid, but it > also could be an attack tool. The initiator will most likely simply log the ICMP and do nothing more based on that. That will be enough to help debugging. > That's a fair suggestion. the WG should ask whether the debugging > benefits that might accrue warrant a SHOULD or a MAY, vs. the added > performance hit for dropped traffic and the potential DoS concerns I > cited. I think now that we should say it is MAY. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Fri Feb 20 05:15:11 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KDFAbg001996; Fri, 20 Feb 2004 05:15:10 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA23292 Fri, 20 Feb 2004 07:43:47 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16438.958.625838.937789@fireball.acr.fi> Date: Fri, 20 Feb 2004 14:55:26 +0200 From: Tero Kivinen To: Stephen Kent Cc: Charles Lynn , ipsec@lists.tislabs.com Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues In-Reply-To: References: <16434.27900.199285.136682@fireball.acr.fi> <20040218161436.9707F2051E@wolfe.bbn.com> <16435.55623.26827.859229@fireball.acr.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 11 min X-Total-Time: 13 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > In 2401, and so far in 2401bis, we have distinguished between ANY and > OPAQUE. if we decide to continue to do that, then at a minimum, we > would not consider a fragment with no port fields to match an SA that > allowed traffic with ANY as the value for port fields. > > Also, If an IPsec implementation has two SA between the same > source/dest address pairs, and with the same protocol value(s), but > distinguished traffic based on specific (vs. ANY) port fields, then a > non-initial fragment cannot be mapped to either SA unambiguously. An Actually it can, but it requires little bit work. For example our code does the following (I do know that this is much more than what is required by the rfc2401): 1) If it receives unknown non-first fragment, it will put it in the separate queue (queue length and number bytes consumed is limited). 2) When it receives the first-fragment it will find the SA suitable for it, and send packet forward. 3) Then it will search through the non-first fragments queue and find other fragments for the packet, and send those forward (verifying in the process that the fragments do not overwrite the fields used in selecting the SA). 4) It will create known-fragment entry to database, marking that if we see other fragments to this packet, they can be sent forward to this SA if they start after this offset. This entry will timeout after some time. This will allow selecting proper SA for each fragment (non-first or first). Of course the other end needs to do the same processing when packets are processed to verify the selectors, in this case it is easier, as the other end has already waited for the first-fragment, so it will most likely come first (not necessary, the order might have changed during transit). So it is not impossible, it simply requires some work. We do not need to do full reassembly, we simply need to mark that fragment matching this source/destination/protocol/id should be sent/received from this SA. > analogous problem arises if there is just one, extant SA that matches > the addresses and protocol, and we are forced to search the SPD to > see if another SA might be appropriate. These observations motivate > use of a separate SA to carry fragments, right? Or to do the fragment handling properly, i.e. put them to the same SA which haves the non-first fragments. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Fri Feb 20 05:22:15 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KDMEJE002271; Fri, 20 Feb 2004 05:22:15 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA24383 Fri, 20 Feb 2004 07:50:38 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16438.1376.421075.136552@fireball.acr.fi> Date: Fri, 20 Feb 2004 15:02:24 +0200 From: Tero Kivinen To: Charles Lynn Cc: ipsec@lists.tislabs.com Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues In-Reply-To: <20040219165444.DA6FB2051E@wolfe.bbn.com> References: <16435.55623.26827.859229@fireball.acr.fi> <20040219165444.DA6FB2051E@wolfe.bbn.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 6 min X-Total-Time: 6 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charles Lynn writes: > I.e., such a rule would let any TCP packets go through. Thus if one > anted to only allow, say TCP to port 22, including any fragments, then > the admin would have to insert a rule explicitly saying that ports > 0 to 21 and 23 to 65535 should be DROP'ed. It gets a lot worse if > multiple ports are allowed. But any OPAQUE rule will allow attacks against the fragmentation code for the host anyways, so what is the problem of sending any non-first fragments in the same TCP 22 SA? Are you saying that TCP 22 rule does not allow fragments of the TCP 22 packets to get through (see my previous posting of how to match fragments to the SAs). We have been earlier talking whether TCP 22 rule should also allow PMTU ICMPs etc to go through, and now we are talking to whether to allow framented packets go through. I think the TCP 22 rule should allow all traffic directly related to TCP streams to port 22 through, meaning normal packets, fragmented packets (all fragments, including non-first fragments), ICMPs related to the TCP stream (PMTU, host unreachable, etc). Creating separate SA for each of those would be quite annoying (i.e. you need to create separate SA for ICMP traffic (and you need to filter out those ICMP traffic which do not correspond to the real TCP sessions in active, like faked host unreachable messages etc), and separate SA for non-first fragments etc. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Fri Feb 20 06:02:48 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KE2mCE004474; Fri, 20 Feb 2004 06:02:48 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA29805 Fri, 20 Feb 2004 08:30:23 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16438.3734.624347.316169@fireball.acr.fi> Date: Fri, 20 Feb 2004 15:41:42 +0200 From: Tero Kivinen To: Stephen Kent Cc: "Bora Akyol" , "'Barbara Fraser'" , "'Charles Lynn'" , Subject: RE: SAs that carry fragments Was: Re: Some IKEv2 issues In-Reply-To: References: <00c301c3f723$fa3577f0$060a0a0a@amer.cisco.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 12 min X-Total-Time: 31 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > >Yes, and people have figured ways of supporting this > >without needing separate SAs for fragments. > your said "ways" which is plural. It's not enough for a vendor to > decide how to map a fragment to an SA, since the receiver is supposed > to check each received packet against the selectors for the SA via > which it is received. So, if there is ONE way to do this, and > everybody already does it, and if it accommodates all the possible SA > configurations that a compliant implementation MUST support, then we > should just describe that way in 2401bis. But, what I fear you are > indicating is that different vendors have different ways of > accommodating fragments, and that these may not be common, which > means that interoperability problems may (will) occur, OR that not > all possible SA configurations will work. if so, then we need to fix > this situation. I do not know what others do, or do they support port selectors at all. For VPN style setups (== tunnel mode) port selectors are not that usefull, I think the most used setup there is tunnel from one IP or network to network, and no port selectors at all. They might have additional firewall rules after that, checking that only allowed protocols are used (smtp, www etc). Port selectors are more usefull in the host to host case, i.e. transport mode, as there you might have per TCP/IP flow SAs (or per user SAs). In those cases the IPsec processing is done for the whole packet, thus this is non-issue (there are no fragments to be processed in the transport mode case). So we are now only talking about tunnel mode. How often do people use tunnel mode along with port selectors? Does anybody have example of real world example where it is needed? How does other implemenations process the fragmented tunnel mode packet along with SAs with port selectors. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Fri Feb 20 07:17:17 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KFHGbN008436; Fri, 20 Feb 2004 07:17:17 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09115 Fri, 20 Feb 2004 09:40:57 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16438.958.625838.937789@fireball.acr.fi> References: <16434.27900.199285.136682@fireball.acr.fi> <20040218161436.9707F2051E@wolfe.bbn.com> <16435.55623.26827.859229@fireball.acr.fi> <16438.958.625838.937789@fireball.acr.fi> Date: Fri, 20 Feb 2004 09:47:15 -0500 To: Tero Kivinen From: Stephen Kent Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues Cc: Charles Lynn , 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:55 +0200 2/20/04, Tero Kivinen wrote: >Stephen Kent writes: >> In 2401, and so far in 2401bis, we have distinguished between ANY and >> OPAQUE. if we decide to continue to do that, then at a minimum, we >> would not consider a fragment with no port fields to match an SA that >> allowed traffic with ANY as the value for port fields. >> >> Also, If an IPsec implementation has two SA between the same >> source/dest address pairs, and with the same protocol value(s), but >> distinguished traffic based on specific (vs. ANY) port fields, then a >> non-initial fragment cannot be mapped to either SA unambiguously. An > >Actually it can, but it requires little bit work. For example our code >does the following (I do know that this is much more than what is >required by the rfc2401): > > 1) If it receives unknown non-first fragment, it will put it > in the separate queue (queue length and number bytes > consumed is limited). > 2) When it receives the first-fragment it will find the SA > suitable for it, and send packet forward. > 3) Then it will search through the non-first fragments queue > and find other fragments for the packet, and send those > forward (verifying in the process that the fragments do not > overwrite the fields used in selecting the SA). > 4) It will create known-fragment entry to database, marking > that if we see other fragments to this packet, they can be > sent forward to this SA if they start after this offset. > This entry will timeout after some time. this sounds like a reasonable mechanism, though perhaps not not a very high speed context, since receipt of an initial fragment could trigger transmission of delayed non-initial fragments, which implies possible further disruption to transmission. but, under the right circumstances I can certainly see how this could work. > >This will allow selecting proper SA for each fragment (non-first or >first). Of course the other end needs to do the same processing when >packets are processed to verify the selectors, in this case it is >easier, as the other end has already waited for the first-fragment, so >it will most likely come first (not necessary, the order might have >changed during transit). right. so there is some reassembly-like processing at the receiver, e.g., per SA state to remember initial fragment data plus queuing of non-initial fragments to accommodate out or order delivery, etc. >So it is not impossible, it simply requires some work. We do not need >to do full reassembly, we simply need to mark that fragment matching >this source/destination/protocol/id should be sent/received from this >SA. you left put ports here, the crux of the problem, but I assume that was just a typo, right? > > analogous problem arises if there is just one, extant SA that matches >> the addresses and protocol, and we are forced to search the SPD to >> see if another SA might be appropriate. These observations motivate >> use of a separate SA to carry fragments, right? > >Or to do the fragment handling properly, i.e. put them to the same SA >which haves the non-first fragments. What concerns me is that the processing you describe could be a significant burden, maybe even infeasible, for very high speed operation. We have focused more on such operation in this round of revisions, e.g., support for 64-bit sequence numbers and explicit discussion of caches. Thus I would prefer a spec that works well in all cases. Steve From owner-ipsec@lists.tislabs.com Fri Feb 20 07:17:17 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KFHGAU008437; Fri, 20 Feb 2004 07:17:17 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09129 Fri, 20 Feb 2004 09:41:10 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16438.3734.624347.316169@fireball.acr.fi> References: <00c301c3f723$fa3577f0$060a0a0a@amer.cisco.com> <16438.3734.624347.316169@fireball.acr.fi> Date: Fri, 20 Feb 2004 09:50:18 -0500 To: Tero Kivinen From: Stephen Kent Subject: RE: SAs that carry fragments Was: Re: Some IKEv2 issues Cc: "Bora Akyol" , "'Barbara Fraser'" , "'Charles Lynn'" , 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 15:41 +0200 2/20/04, Tero Kivinen wrote: >Stephen Kent writes: >> >Yes, and people have figured ways of supporting this >> >without needing separate SAs for fragments. >> your said "ways" which is plural. It's not enough for a vendor to >> decide how to map a fragment to an SA, since the receiver is supposed >> to check each received packet against the selectors for the SA via >> which it is received. So, if there is ONE way to do this, and >> everybody already does it, and if it accommodates all the possible SA >> configurations that a compliant implementation MUST support, then we >> should just describe that way in 2401bis. But, what I fear you are >> indicating is that different vendors have different ways of >> accommodating fragments, and that these may not be common, which >> means that interoperability problems may (will) occur, OR that not >> all possible SA configurations will work. if so, then we need to fix >> this situation. > >I do not know what others do, or do they support port selectors at >all. For VPN style setups (== tunnel mode) port selectors are not that >usefull, I think the most used setup there is tunnel from one IP or >network to network, and no port selectors at all. They might have >additional firewall rules after that, checking that only allowed >protocols are used (smtp, www etc). > >Port selectors are more usefull in the host to host case, i.e. >transport mode, as there you might have per TCP/IP flow SAs (or per >user SAs). In those cases the IPsec processing is done for the whole >packet, thus this is non-issue (there are no fragments to be processed >in the transport mode case). > >So we are now only talking about tunnel mode. How often do people use >tunnel mode along with port selectors? Does anybody have example of >real world example where it is needed? How does other implemenations >process the fragmented tunnel mode packet along with SAs with port >selectors. We've had analogous debates on this before. IPsec is NOT just a VPN technology and our specs ought not be VPN-specific. I have certainly advised folks to use port selectors for tunnels under certain instances, e.g., to restrict traffic to a server to be traffic of the sort appropriate to that server, based on the well known ports associated with the service. Steve From owner-ipsec@lists.tislabs.com Fri Feb 20 07:18:16 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KFIFLo008469; Fri, 20 Feb 2004 07:18:15 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09113 Fri, 20 Feb 2004 09:40:56 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16438.75.875878.718798@fireball.acr.fi> References: <20040130232243.GA6423@thunk.org> <16434.24291.254422.111128@fireball.acr.fi> <16438.75.875878.718798@fireball.acr.fi> Date: Fri, 20 Feb 2004 09:38:35 -0500 To: Tero Kivinen From: Stephen Kent Subject: Re: Issue #83: Generation of ICMP responses for inbound packet requiring IPSEC protection 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:40 +0200 2/20/04, Tero Kivinen wrote: >Stephen Kent writes: >> So, if we don't adopt this proposal, each inbound, non-IPsec packet >> that does not match an explicit bypass OR drop entry in the SPI-I >> cache, triggers a check of the SPD-I. But if we adopt the proposal, >> then every packet that is dropped, even if in response to an explicit >> SPD-I cache entry, requires an SPD-S search. > >Or the SPD-I cache entry can have information whether the ICMP will >need to be sent or not. That might be a good alternative, but it's not at all what the proposed text said, and I thought your argument was that I had dismissed the proposed text without cause. This constitutes a different proposal. Not saying we can't consider it but just being clear about the scope. > >> you are right, in that I misunderstood the proposal. The searches are >> triggered only for dropped traffic. But, that still imposes an >> additional burden, as noted above. also, the proposed text requires >> that we be prepared to send an ICMP. At this point the proposed text >> has allowed an attacker to cause a receiver to do a lot more work >> than we currently do, and it could even turn the receiver into a DoS >> source, by having it generate ICMP messages based on bogus source IP >> addresses. Yes, the text called for this to be configurable, but we >> should be aware that this allows a careless admin at site A to turn >> his IPsec device into an ICMP generator that will affect Site C, >> which strikes me as a bad idea, in general. > >Thats why the sending of ICMP (or any other error messages) must be >rate limited (not per entry/peer, but per gateway), and the rate limit >must be configurable. The careless admin can do quite a lot of other >things, he might even have boxes root password as "root" and allow >attackers to use the machine as an attack box :-) yes, but assurance issues like that have always been outside the scope of what we specify in a standard. this is different in that we are creating a feature that otherwise would not be present and which can be be mismanaged to the detriment of others. again, I'm not saying the WG can't do this, but rather that the analogy you make it not quite parallel. >I do not think we can protect the careless adminstrators compeltely. >We as an implementators can but sensible defaults to those limits, and >for example disallow setting the limit too high (i.e. set the maximum >limit which can be configured to 10 ICMP messages / second and default >to 1 ICMP message / second). it's not the careless admin we are protecting, but rather protecting others from the carelessness of that admin. > > I do not understand your example. How does one specify an SPD entry >> that says put this traffic on an SA IF the SA exists, but don't >> create one otherwise and just send the traffic in the clear? > >This is the setup which is mostly used for opportunistic cases, i.e. >if you have SA up you use it, if you don't you can send the traffic >clear, or you can even try to create SA, and if it fails you send it >in clear. Sorry, but my comment still stands, i.e., I do not recall ANY way to specify such behavior via the SPD in 2401. This is something to which I do object, i.e., a fundamentally new access control behavior, not consistent with the long standing definition of what the SPD does. >This kind of setup can be used for normal web-traffic etc, where you >actually do not normally need to create IPsec SAs, but if you happen >to have SA up, you can use it (it does not cause any harm either). it makes behavior non-deterministic, which is generally a bad thing from a security perspective. > > I don't >> think the SPD has ever been described in a way that would allow such >> behavior. > >Might be true, but there are implemenations which support this kind of >operations. Then they are non-complaint. > > >If we get ICMP in those cases it will be clear from the Host B side > > >that when the adminstrator sees from the logs that it have received >> >ICMP telling that communication adminstratively prohibited that there >> >is something wrong with setup, not in the network (which usually is >> >the first one to blame in this cases). >> >> But the admin can't trust the source address for the ICMP messages, >> so if he acts on them he is subject to spoofing. I agree that under >> the right circumstances this feature could be a debugging aid, but it >> also could be an attack tool. > >The initiator will most likely simply log the ICMP and do nothing more >based on that. That will be enough to help debugging. > >> That's a fair suggestion. the WG should ask whether the debugging >> benefits that might accrue warrant a SHOULD or a MAY, vs. the added >> performance hit for dropped traffic and the potential DoS concerns I >> cited. > >I think now that we should say it is MAY. I think our discussion shows at least two things, neither of which lead me to the same conclusion :-) - the proposed text is defective in some respects - some of the supporting analysis is based on a change to the semantics of the SPD, which I think is WAY out of scope for this discussion Steve From owner-ipsec@lists.tislabs.com Fri Feb 20 08:03:43 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KG3glE011214; Fri, 20 Feb 2004 08:03:43 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15047 Fri, 20 Feb 2004 10:27:45 -0500 (EST) Date: Fri, 20 Feb 2004 17:39:23 +0200 Message-Id: <200402201539.i1KFdNlW006168@burp.tkv.asdf.org> From: Markku Savela To: ipsec@lists.tislabs.com In-reply-to: <16438.3734.624347.316169@fireball.acr.fi> (message from Tero Kivinen on Fri, 20 Feb 2004 15:41:42 +0200) Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues References: <00c301c3f723$fa3577f0$060a0a0a@amer.cisco.com> <16438.3734.624347.316169@fireball.acr.fi> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IPSEC:ing fragments? First, I really don't like the idea. But, anyway a comment to > From: Tero Kivinen > So we are now only talking about tunnel mode. In theory one could apply IPSEC to IPv6 fragments in transport mode. However, it's technically impossible to apply IPSEC to IPv4 fragments, except by tunneling (think, where do you put the fragment offset and M-bit, and how the receiver would work?). I would prefer, that if IPSEC tunneling fragments is a MUST, only the support for address selectors would be required by IPSEC. And I would still disallow applying transport mode IPSEC to IPv6 fragments, even if it technically might be possible (need to look into this, it would be somewhat weird path in my implementation, probably will not work at all). From owner-ipsec@lists.tislabs.com Fri Feb 20 08:58:13 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KGwD7J014714; Fri, 20 Feb 2004 08:58:13 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19411 Fri, 20 Feb 2004 11:16:15 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200402201539.i1KFdNlW006168@burp.tkv.asdf.org> References: <00c301c3f723$fa3577f0$060a0a0a@amer.cisco.com> <16438.3734.624347.316169@fireball.acr.fi> <200402201539.i1KFdNlW006168@burp.tkv.asdf.org> Date: Fri, 20 Feb 2004 11:25:19 -0500 To: Markku Savela From: Stephen Kent Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues 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 17:39 +0200 2/20/04, Markku Savela wrote: >IPSEC:ing fragments? First, I really don't like the idea. But, anyway >a comment to the need to support tunneling of fragments has been in IPsec for 5+ years. this is not a new issue. it is an issue that we are trying to address in a uniform way. > >> From: Tero Kivinen >> So we are now only talking about tunnel mode. > >In theory one could apply IPSEC to IPv6 fragments in transport >mode. However, it's technically impossible to apply IPSEC to IPv4 >fragments, except by tunneling (think, where do you put the fragment >offset and M-bit, and how the receiver would work?). > >I would prefer, that if IPSEC tunneling fragments is a MUST, only the >support for address selectors would be required by IPSEC. yes, it is a MUST. one can choose to configure SA so that only addresses (or addresses and protocol) are examined and the ports are OPAQUE. 2401 allows that already and it should work today. but that leaves an awkward gap when ports are not OPAQUE and fragmentation occurs. we were approached by a vendor who wanted to have a well-defined, standard way to accommodate this, over a year ago, and that motivated the "carry all fragments between two sites in one tunnel" model. the WG rejected that model, but that does not make the issue go away, and since a vendor asked for this, I think it is fair to say that at least some users want the combination to work. >And I would still disallow applying transport mode IPSEC to IPv6 >fragments, even if it technically might be possible (need to look into >this, it would be somewhat weird path in my implementation, probably >will not work at all). I'll let Charlie Lynn address the vagaries of v6 fragmentation. Steve From owner-ipsec@lists.tislabs.com Fri Feb 20 09:04:19 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KH4Jqh015422; Fri, 20 Feb 2004 09:04:19 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21088 Fri, 20 Feb 2004 11:30:43 -0500 (EST) From: "Bora Akyol" To: , "'Tero Kivinen'" Subject: Traffic Selectors (was SA fragments) Date: Fri, 20 Feb 2004 08:42:15 -0800 Message-ID: <001d01c3f7d0$7f373a90$060a0a0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think there is agreement that port based selectors do not make sense for tunnel mode. #1 use of transport mode SAs that I have seen is GRE over IPSEC which also does not require port selectors. The other application of transport mode is communication between two hosts. Nicolas brought up an excellent point of a multi-user system where each socket can require a different security protection level. Even though the current socket APIs that I am aware of are not capable of specifying a security protection grade, I am sure this can be put in with some work. There is also the security policy management issue of how does an application decide the security grade and is it better off using TLS, but that is another nest of worms. So based on this I would like to propose the following text for traffic selectors (and please feel free to edit and comment): --- All IKE implementations MUST be able to negotiate IPSEC SAs based on tuples of {IP Source Address/Mask, IP Destination Address/Mask, IP Protocol}. Additionally, an implementation MAY support any traffic selector of the form (Offset, Length, Value, Mask) where: Offset: Offset of the field from the end of the IP version field in the IP header. Length: Length of the field being compared for SPD determination Value: Value of the field Mask: A bitmask that can be used for masking the value. --- Note that range specifications are limited to bit boundaries for these fields but this should not be a significant limitation. If the word MAY is too weak for optional selectors, it can be changed to a SHOULD. Comments? Bora From owner-ipsec@lists.tislabs.com Fri Feb 20 09:24:07 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KHO7jS016066; Fri, 20 Feb 2004 09:24:07 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22451 Fri, 20 Feb 2004 11:46:18 -0500 (EST) From: "Bora Akyol" To: "'Stephen Kent'" , "'Tero Kivinen'" Cc: "'Barbara Fraser'" , "'Charles Lynn'" , Subject: RE: SAs that carry fragments Was: Re: Some IKEv2 issues Date: Fri, 20 Feb 2004 08:57:53 -0800 Message-ID: <001f01c3f7d2$aec736f0$060a0a0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > We've had analogous debates on this before. IPsec is NOT just a VPN > technology and our specs ought not be VPN-specific. I have certainly > advised folks to use port selectors for tunnels under certain > instances, e.g., to restrict traffic to a server to be traffic of the > sort appropriate to that server, based on the well known ports > associated with the service. > > Steve > Thanks for your comments, I have a few questions: 1) In the MPLS working group, there has been a lot of input from users/producers of the technology that has made critical contributions to the original set of specifications and for the better. So I think if there is input from the field and not just one vendor/person that port selectors are not widely used then the IPSEC WG may want to keep an open mind/ear. Yes, the implementation must not direct proper protocol design, OTOH, the protocol designers may benefit from the field experience. I have on a separate email submitted a definition of traffic selectors that I hope is flexible enough to accommodate both schemes. 2) Although it sounds really interesting to let applications decide which ports they want to use and how they want to secure them, there are a few issues. a) The system admin that decides the security policy may be a different person from the application author. Moreover, the application author may in fact have a hidden agenda in passing the data over a less secure channel than the system policy allows. In order to settle this difference of SP, a properly designed socket layer API needs to exist. However, even though port selectors have been in IKE/IPSEC for at least 5-6 years, is there a such a socket API? If there is no such socket API, then does this mean that the proposed application is not important enough to the field so that it should be specified as an **optional** feature. b) Even if such a socket API existed, the user environment in most OSs allows applications to be tunneled via a different port (like HTTP proxies), so it is quite easy to circumvent the system policy for a malicious user if the policy was specified for ports alone. In fact, I believe there is an implementation of IP over DNS that exists. I think based on these, one can argue that even for transport mode, the safest security configuration for hosts is one that specifies less and secures more. Thank you for reading and your comments, Regards Bora ps. As in all IETF lists, these are my opinions and not my employer's! From owner-ipsec@lists.tislabs.com Fri Feb 20 09:26:22 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KHQLrR016139; Fri, 20 Feb 2004 09:26:21 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23119 Fri, 20 Feb 2004 11:51:30 -0500 (EST) Message-Id: <200402201703.i1KH39Sj014086@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen cc: Stephen Kent , "Bora Akyol" , "'Barbara Fraser'" , "'Charles Lynn'" , ipsec@lists.tislabs.com Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues In-reply-to: Your message of Fri, 20 Feb 2004 15:41:42 +0200. <16438.3734.624347.316169@fireball.acr.fi> Date: Fri, 20 Feb 2004 18:03:09 +0100 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: Port selectors are more usefull in the host to host case, i.e. transport mode => I have a concern about this "host to host" == transport mode. So we are now only talking about tunnel mode. How often do people use tunnel mode along with port selectors? => host to host where for some reasons transport mode is not used. Regards Francis.Dupont@enst-bretagne.fr PS: I'd like the solution (if we'll get one :-) will work with IPv6 too. From owner-ipsec@lists.tislabs.com Fri Feb 20 09:36:53 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KHaqZT017103; Fri, 20 Feb 2004 09:36:53 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24506 Fri, 20 Feb 2004 12:02:30 -0500 (EST) Message-Id: <200402201714.i1KHEDSj014214@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: ipsec@lists.tislabs.com Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues In-reply-to: Your message of Fri, 20 Feb 2004 17:39:23 +0200. <200402201539.i1KFdNlW006168@burp.tkv.asdf.org> Date: Fri, 20 Feb 2004 18:14:13 +0100 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 theory one could apply IPSEC to IPv6 fragments in transport mode. => I disagree: IPv6 fragmentation is done by an extension header, this is not a "upper layer protocol" so you can't select it. So even in theory it is impossible. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Fri Feb 20 10:16:41 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KIGeD4019103; Fri, 20 Feb 2004 10:16:40 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29136 Fri, 20 Feb 2004 12:39:56 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: SAs that carry fragments Was: Re: Some IKEv2 issues Date: Fri, 20 Feb 2004 17:51:44 -0000 Message-ID: <579E83556A36E44EB2945CCE990B317401050F0C@EUR-MSG-02.europe.corp.microsoft.com> Thread-Topic: SAs that carry fragments Was: Re: Some IKEv2 issues Thread-Index: AcP3uDs1Ywn5uBNhTaewMjUtWgZhKQAHGI1g From: "Michael Roe" To: "Stephen Kent" Cc: X-OriginalArrivalTime: 20 Feb 2004 17:51:45.0019 (UTC) FILETIME=[3460B4B0:01C3F7DA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA29131 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From this discussion, it would appear that there is some disagreement about exactly which packets are matched by the "ANY" and "OPAQUE" traffic selectors. RFC 2401 and draft-ietf-ipsec-rfc2401bis-01.txt aren't very clear on this point. Perhaps rfc2401bis should be updated to be more explicit about this? It's clear that a port selector of OPAQUE will match a non-initial fragment, and a port selector of "ANY" will match an initial fragment with a cleartext port number in it. The slightly trickier cases are (a) Does "OPAQUE" match an initial fragment with a cleartext port number in it? (b) Does "ANY" match a non-initial fragment? Rfc2401bis, section 6, says 'Thus, fragments not containing port numbers may only match rules having port selectors of OPAQUE or "ANY"' - implying that the answer to question (b) is yes. I would guess that "OPAQUE" doesn't match packets in which the port numbers are visible, but the architecture document isn't very clear. draft-ietf-ipsec-ikev2-12.txt doesn't define separate traffic selectors for "ANY" and "OPAQUE", it just allows a port range of 0..65535. It looks to me as though IKEv2 is inconsistent with the architecture document. Cheers, Mike From owner-ipsec@lists.tislabs.com Fri Feb 20 10:19:11 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KIJBk9019218; Fri, 20 Feb 2004 10:19:11 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29637 Fri, 20 Feb 2004 12:44:00 -0500 (EST) Date: Fri, 20 Feb 2004 11:54:58 -0600 From: Nicolas Williams To: Stephen Kent Cc: Tero Kivinen , Charles Lynn , ipsec@lists.tislabs.com Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues Message-ID: <20040220175458.GC6177@binky.central.sun.com> Mail-Followup-To: Stephen Kent , Tero Kivinen , Charles Lynn , ipsec@lists.tislabs.com References: <16434.27900.199285.136682@fireball.acr.fi> <20040218161436.9707F2051E@wolfe.bbn.com> <16435.55623.26827.859229@fireball.acr.fi> <16438.958.625838.937789@fireball.acr.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, Feb 20, 2004 at 09:47:15AM -0500, Stephen Kent wrote: > At 14:55 +0200 2/20/04, Tero Kivinen wrote: > >Actually it can, but it requires little bit work. For example our code > >does the following (I do know that this is much more than what is > >required by the rfc2401): > > > > 1) If it receives unknown non-first fragment, it will put it > > in the separate queue (queue length and number bytes > > consumed is limited). > > 2) When it receives the first-fragment it will find the SA > > suitable for it, and send packet forward. > > 3) Then it will search through the non-first fragments queue > > and find other fragments for the packet, and send those > > forward (verifying in the process that the fragments do not > > overwrite the fields used in selecting the SA). > > 4) It will create known-fragment entry to database, marking > > that if we see other fragments to this packet, they can be > > sent forward to this SA if they start after this offset. > > This entry will timeout after some time. > > this sounds like a reasonable mechanism, though perhaps not not a > very high speed context, since receipt of an initial fragment could > trigger transmission of delayed non-initial fragments, which implies > possible further disruption to transmission. but, under the right > circumstances I can certainly see how this could work. Or just drop non-initial fragments arriving before their corresponding initial fragments (or so much later that the corresponding initial fragments have fallen off the cache). IP can lose packets. Sometimes it's good to excercise this feature. In transport mode scenarios (IPv4) this doesn't apply either since the sender won't fragment and any middle boxes would fragment protected traffic between the transport mode peers so there's no fragment protection issue. (I should have noticed this earlier instead of piping up about transport mode.) In BITW scenarios with SPDs that use port selectors this issue comes up, as it does in one side of SG/VPN scenarios, right? [...] > >Or to do the fragment handling properly, i.e. put them to the same SA > >which haves the non-first fragments. > > What concerns me is that the processing you describe could be a > significant burden, maybe even infeasible, for very high speed > operation. We have focused more on such operation in this round of > revisions, e.g., support for 64-bit sequence numbers and explicit > discussion of caches. Thus I would prefer a spec that works well in > all cases. If you remove the store-and-forward aspect of the proposal and drop non-initial fragments for which you can't find a matching initial fragment entry in the cache, then the only burden is that of keeping a small cache of initial fragment identifiers, which means: - a small computational hit on initial fragments: cache id - a small computational hit on non-initial fragments: lookup id - a fixed memory hit - plus the burden of any additional restransmitted traffic that may result from dropping some non-initial fragments; the cache should be sized accordingly The cache is indexed by selectors visible in a fragmented packet (protocol, addresses) and packet ID; collisions are irrelevant, as are fragment offsets. LRU, LFU, aging, can be used to deal with cache pressure. Cheers, Nico -- From owner-ipsec@lists.tislabs.com Fri Feb 20 10:58:03 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KIw2BX020883; Fri, 20 Feb 2004 10:58:03 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03447 Fri, 20 Feb 2004 13:21:47 -0500 (EST) Message-ID: <008b01c3f7e0$0ceab830$eb1167c0@adithya> From: "Mohan Parthasarathy" To: Subject: Traffic selectors in IKEv2 Date: Fri, 20 Feb 2004 10:33:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have a couple of questions on the Traffic selectors in IKEv2. 1) Traffic selectors allow a range of addresses. Is the range encompassing all the addresses from 0 to 255.255.255.255 valid (similarly for IPv6) ? Nothing in the spec seems to preclude it. 2) IKEv2 specifically allows multiple IPsec SAs to co-exist (and be used) for the same traffic selector between same endpoints. i would assume that multiple SAs for the selectors specifying all the addresses is still possible between the same endpoints. Is that allowed ? thanks mohan From owner-ipsec@lists.tislabs.com Fri Feb 20 12:03:21 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KK3Kth024309; Fri, 20 Feb 2004 12:03:20 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07263 Fri, 20 Feb 2004 14:19:00 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <20040220175458.GC6177@binky.central.sun.com> References: <16434.27900.199285.136682@fireball.acr.fi> <20040218161436.9707F2051E@wolfe.bbn.com> <16435.55623.26827.859229@fireball.acr.fi> <16438.958.625838.937789@fireball.acr.fi> <20040220175458.GC6177@binky.central.sun.com> Date: Fri, 20 Feb 2004 14:20:01 -0500 To: Nicolas Williams From: Stephen Kent Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues Cc: Tero Kivinen , Charles Lynn , 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:54 -0600 2/20/04, Nicolas Williams wrote: >On Fri, Feb 20, 2004 at 09:47:15AM -0500, Stephen Kent wrote: >> At 14:55 +0200 2/20/04, Tero Kivinen wrote: >> >Actually it can, but it requires little bit work. For example our code >> >does the following (I do know that this is much more than what is >> >required by the rfc2401): >> > >> > 1) If it receives unknown non-first fragment, it will put it >> > in the separate queue (queue length and number bytes >> > consumed is limited). >> > 2) When it receives the first-fragment it will find the SA >> > suitable for it, and send packet forward. >> > 3) Then it will search through the non-first fragments queue >> > and find other fragments for the packet, and send those >> > forward (verifying in the process that the fragments do not >> > overwrite the fields used in selecting the SA). >> > 4) It will create known-fragment entry to database, marking >> > that if we see other fragments to this packet, they can be >> > sent forward to this SA if they start after this offset. >> > This entry will timeout after some time. >> >> this sounds like a reasonable mechanism, though perhaps not not a >> very high speed context, since receipt of an initial fragment could >> trigger transmission of delayed non-initial fragments, which implies >> possible further disruption to transmission. but, under the right >> circumstances I can certainly see how this could work. > >Or just drop non-initial fragments arriving before their corresponding >initial fragments (or so much later that the corresponding initial >fragments have fallen off the cache). > >IP can lose packets. Sometimes it's good to excercise this feature. yes, sometimes taking advantage of this "feature" can make our lives easier as designers ;-) >In transport mode scenarios (IPv4) this doesn't apply either since the >sender won't fragment and any middle boxes would fragment protected >traffic between the transport mode peers so there's no fragment >protection issue. (I should have noticed this earlier instead of piping >up about transport mode.) In a BITS implementation the host could have fragmented prior to IPsec receiving the packet, but one would certainly expect that the first fragment would arrive at the BITS first in that case. >In BITW scenarios with SPDs that use port selectors this issue comes up, >as it does in one side of SG/VPN scenarios, right? It used to be the case that transport mode was restricted to end systems, but due to popular demand we have removed that restriction. so, this used to be just a tunnel mode issue for SG scenarios, but it might arise for transport mode too,under our new paradigm. > >[...] >> >Or to do the fragment handling properly, i.e. put them to the same SA >> >which haves the non-first fragments. >> >> What concerns me is that the processing you describe could be a >> significant burden, maybe even infeasible, for very high speed >> operation. We have focused more on such operation in this round of >> revisions, e.g., support for 64-bit sequence numbers and explicit >> discussion of caches. Thus I would prefer a spec that works well in >> all cases. > >If you remove the store-and-forward aspect of the proposal and drop >non-initial fragments for which you can't find a matching initial >fragment entry in the cache, then the only burden is that of keeping a >small cache of initial fragment identifiers, which means: > > - a small computational hit on initial fragments: cache id > - a small computational hit on non-initial fragments: lookup id > - a fixed memory hit > - plus the burden of any additional restransmitted traffic that may > result from dropping some non-initial fragments; the cache should be > sized accordingly > >The cache is indexed by selectors visible in a fragmented packet >(protocol, addresses) and packet ID; collisions are irrelevant, as are >fragment offsets. LRU, LFU, aging, can be used to deal with cache >pressure. I'm not sure how to size the cache, but otherwise I think your analysis is correct, based on dropping non-initial fragments. one also has to deal with housekeeping issues, e.g., timing out fragment IDs, to prevent possible mismatches, and one needs to specify the receiver-side algorithm too, e.g., remembering packet IDs for initial fragments so that the later fragments are treated as acceptable. but, is this easier than what Charlie Lynn described? Steve From owner-ipsec@lists.tislabs.com Fri Feb 20 12:04:01 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KK40BI024336; Fri, 20 Feb 2004 12:04:00 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07259 Fri, 20 Feb 2004 14:18:59 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <001d01c3f7d0$7f373a90$060a0a0a@amer.cisco.com> References: <001d01c3f7d0$7f373a90$060a0a0a@amer.cisco.com> Date: Fri, 20 Feb 2004 14:05:40 -0500 To: "Bora Akyol" From: Stephen Kent Subject: Re: Traffic Selectors (was SA fragments) Cc: 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 Bora, >I think there is agreement that port based selectors >do not make sense for tunnel mode. Are we reading the same mailing list? there is not agreement on this point. You may keep saying it, but that does not make it so :-) By my count, you posted one message to this list in all of 2003, three in late 2002, and four in August and September 2001. That tells me that you have been aware of the work of this WG for at least 2.5 years, but have made almost no contributions during that time. Now, 5 years after we published 2401, you propose a significant change to the use of selectors. I think you are way too late and have contributed far too little to be taken seriously in this regard. Steve From owner-ipsec@lists.tislabs.com Fri Feb 20 12:29:12 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KKTB7h027251; Fri, 20 Feb 2004 12:29:12 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10926 Fri, 20 Feb 2004 14:53:58 -0500 (EST) Date: Fri, 20 Feb 2004 14:03:36 -0600 From: Nicolas Williams To: Stephen Kent Cc: Tero Kivinen , Charles Lynn , ipsec@lists.tislabs.com Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues Message-ID: <20040220200336.GF6177@binky.central.sun.com> Mail-Followup-To: Stephen Kent , Tero Kivinen , Charles Lynn , ipsec@lists.tislabs.com References: <16434.27900.199285.136682@fireball.acr.fi> <20040218161436.9707F2051E@wolfe.bbn.com> <16435.55623.26827.859229@fireball.acr.fi> <16438.958.625838.937789@fireball.acr.fi> <20040220175458.GC6177@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, Feb 20, 2004 at 02:20:01PM -0500, Stephen Kent wrote: > At 11:54 -0600 2/20/04, Nicolas Williams wrote: > >Or just drop non-initial fragments arriving before their corresponding > >initial fragments (or so much later that the corresponding initial > >fragments have fallen off the cache). > > > >IP can lose packets. Sometimes it's good to excercise this feature. > > yes, sometimes taking advantage of this "feature" can make our lives > easier as designers ;-) :) > >In transport mode scenarios (IPv4) this doesn't apply either since the > >sender won't fragment and any middle boxes would fragment protected > >traffic between the transport mode peers so there's no fragment > >protection issue. (I should have noticed this earlier instead of piping > >up about transport mode.) > > In a BITS implementation the host could have fragmented prior to > IPsec receiving the packet, but one would certainly expect that the > first fragment would arrive at the BITS first in that case. Good point. > >In BITW scenarios with SPDs that use port selectors this issue comes up, > >as it does in one side of SG/VPN scenarios, right? > > It used to be the case that transport mode was restricted to end > systems, but due to popular demand we have removed that restriction. > so, this used to be just a tunnel mode issue for SG scenarios, but it > might arise for transport mode too,under our new paradigm. I thought that SGs were allowed to use transport mode for administrative traffic where the SG is an end-point. Is this a misunderstanding of the new paradigm? If not then no issue here. > > > >[...] > >> >Or to do the fragment handling properly, i.e. put them to the same SA > >> >which haves the non-first fragments. > >> > >> What concerns me is that the processing you describe could be a > >> significant burden, maybe even infeasible, for very high speed > >> operation. We have focused more on such operation in this round of > >> revisions, e.g., support for 64-bit sequence numbers and explicit > >> discussion of caches. Thus I would prefer a spec that works well in > >> all cases. > > > >If you remove the store-and-forward aspect of the proposal and drop > >non-initial fragments for which you can't find a matching initial > >fragment entry in the cache, then the only burden is that of keeping a > >small cache of initial fragment identifiers, which means: > > > > - a small computational hit on initial fragments: cache id > > - a small computational hit on non-initial fragments: lookup id > > - a fixed memory hit > > - plus the burden of any additional restransmitted traffic that may > > result from dropping some non-initial fragments; the cache should be > > sized accordingly > > > >The cache is indexed by selectors visible in a fragmented packet > >(protocol, addresses) and packet ID; collisions are irrelevant, as are > >fragment offsets. LRU, LFU, aging, can be used to deal with cache > >pressure. > > I'm not sure how to size the cache, but otherwise I think your Probably according to the proportion of traffic that is fragmented and which must be protected. > analysis is correct, based on dropping non-initial fragments. one > also has to deal with housekeeping issues, e.g., timing out fragment > IDs, to prevent possible mismatches, and one needs to specify the How bad would mismatches be? They may get protected with an incorrect SA, but the receiver should be the same either way (if not, that would be a bigger deal) and should then simply drop them since they wouldn't match a correct first fragment (and if they did the result would, in all likelyhood, not match various checksums and the like, leading to the full packet being dropped which, again, would be within spec). > receiver-side algorithm too, e.g., remembering packet IDs for initial > fragments so that the later fragments are treated as acceptable. but, > is this easier than what Charlie Lynn described? I'd have to re-read that. In any case, the receiver already has to track packet IDs for reassembly, so now all it has to do in addition is track the SA that was used to protect each fragment and drop any fragments that don't use an acceptable SA. Unlike an SG, the receiver here probably wouldn't want to drop non-initial fragments received before their intial counterparts, if it can avoid it, and should have the necessary buffer space, usually, so the receiver here can behave as Tero proposed -- it does not seem like this would impose much of a burden on the receiver. Nico -- From owner-ipsec@lists.tislabs.com Fri Feb 20 12:40:58 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KKevvZ027663; Fri, 20 Feb 2004 12:40:57 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA11422 Fri, 20 Feb 2004 15:08:14 -0500 (EST) From: "Bora Akyol" To: Subject: RE: Traffic Selectors (was SA fragments) Date: Fri, 20 Feb 2004 12:19:00 -0800 Message-ID: <004a01c3f7ee$c744ae30$060a0a0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I wrote several responses to this, but chose not to send them, if there is no technical merit to my proposal on traffic selectors, then be it. I will point out that the proposed offset based optional selectors work equally well for v6, v4 and any other protocol that does not use TCP/UDP. Bora -- Speechless SW engineer in San Jose > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Friday, February 20, 2004 11:06 AM > To: Bora Akyol > Cc: ipsec@lists.tislabs.com > Subject: Re: Traffic Selectors (was SA fragments) > > > Bora, > > >I think there is agreement that port based selectors > >do not make sense for tunnel mode. > > Are we reading the same mailing list? there is not agreement on this > point. You may keep saying it, but that does not make it so :-) > > By my count, you posted one message to this list in all of 2003, > three in late 2002, and four in August and September 2001. That tells > me that you have been aware of the work of this WG for at least 2.5 > years, but have made almost no contributions during that time. Now, > 5 years after we published 2401, you propose a significant change to > the use of selectors. I think you are way too late and have > contributed far too little to be taken seriously in this regard. > > Steve > From owner-ipsec@lists.tislabs.com Fri Feb 20 13:44:33 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KLiWUc030912; Fri, 20 Feb 2004 13:44:32 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17293 Fri, 20 Feb 2004 16:07:02 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <20040220200336.GF6177@binky.central.sun.com> References: <16434.27900.199285.136682@fireball.acr.fi> <20040218161436.9707F2051E@wolfe.bbn.com> <16435.55623.26827.859229@fireball.acr.fi> <16438.958.625838.937789@fireball.acr.fi> <20040220175458.GC6177@binky.central.sun.com> <20040220200336.GF6177@binky.central.sun.com> Date: Fri, 20 Feb 2004 16:15:14 -0500 To: Nicolas Williams From: Stephen Kent Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues Cc: Tero Kivinen , Charles Lynn , 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 Nicolas, > > >In BITW scenarios with SPDs that use port selectors this issue comes up, >> >as it does in one side of SG/VPN scenarios, right? >> >> It used to be the case that transport mode was restricted to end >> systems, but due to popular demand we have removed that restriction. >> so, this used to be just a tunnel mode issue for SG scenarios, but it >> might arise for transport mode too,under our new paradigm. > >I thought that SGs were allowed to use transport mode for administrative >traffic where the SG is an end-point. Is this a misunderstanding of the >new paradigm? If not then no issue here. The old model allowed SGs to use transport mode for admin traffic. The new model allows SGs to use it for any traffic, e.g., so that an overlay net that does IP-in-IP tunneling can use transport mode for the already tunneled packets. > > >> I'm not sure how to size the cache, but otherwise I think your > >Probably according to the proportion of traffic that is fragmented and >which must be protected. that's hard to do a priori, right? if I am designing a hardware Ipsec implementation and need to decide how much memory to include for this purpose, this isn't a good algorithm :-) > > analysis is correct, based on dropping non-initial fragments. one >> also has to deal with housekeeping issues, e.g., timing out fragment >> IDs, to prevent possible mismatches, and one needs to specify the > >How bad would mismatches be? They may get protected with an incorrect >SA, but the receiver should be the same either way (if not, that would >be a bigger deal) and should then simply drop them since they wouldn't >match a correct first fragment (and if they did the result would, in all >likelyhood, not match various checksums and the like, leading to the >full packet being dropped which, again, would be within spec). i agree that they would be sent to the same destination, but since an SG receiver is not required to reassemble plain text fragments, the issue is what happens at the real destination. long ago when we started discussing this issue there was a suggestion to check the offset for non-initial fragments (pardon the redundancy) to make sure that someone did not try to circumvent the receiver access control mechanism by sending a fragment with a port field that would not have been acceptable in a whole packet. this seems to be an easy check for v4, but it's apparently not feasible for v6, and thus we do have a concern re fragment reassembly attacks. I was uncomfortable with the notion that we might send over fragments that don't really belong to the same packet, but maybe that's not fatal. > > receiver-side algorithm too, e.g., remembering packet IDs for initial >> fragments so that the later fragments are treated as acceptable. but, >> is this easier than what Charlie Lynn described? > >I'd have to re-read that. In any case, the receiver already has to >track packet IDs for reassembly, an IPsec device such as an SG does not have to reassemble plain text fragments, at least not under the assumptions we have been using for the last 5+ years. >so now all it has to do in addition is >track the SA that was used to protect each fragment and drop any >fragments that don't use an acceptable SA. Unlike an SG, the receiver >here probably wouldn't want to drop non-initial fragments received >before their intial counterparts, if it can avoid it, and should have >the necessary buffer space, usually, so the receiver here can behave as >Tero proposed -- it does not seem like this would impose much of a >burden on the receiver. a receiver that is an end system could plausibly do reassembly and then subject the result to an access control check. Steve From owner-ipsec@lists.tislabs.com Fri Feb 20 14:13:01 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KMD0kQ032435; Fri, 20 Feb 2004 14:13:01 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA19705 Fri, 20 Feb 2004 16:36:02 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16438.32792.613873.117981@fireball.acr.fi> Date: Fri, 20 Feb 2004 23:46:00 +0200 From: Tero Kivinen To: Stephen Kent Cc: "Bora Akyol" , "'Barbara Fraser'" , "'Charles Lynn'" , Subject: RE: SAs that carry fragments Was: Re: Some IKEv2 issues In-Reply-To: References: <00c301c3f723$fa3577f0$060a0a0a@amer.cisco.com> <16438.3734.624347.316169@fireball.acr.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 1 min X-Total-Time: 0 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > We've had analogous debates on this before. IPsec is NOT just a VPN > technology and our specs ought not be VPN-specific. I have certainly > advised folks to use port selectors for tunnels under certain > instances, e.g., to restrict traffic to a server to be traffic of the > sort appropriate to that server, based on the well known ports > associated with the service. How have they handled the fragmentation issue in those cases, or have the simply assumed that the fragmentation will not happen, and ignored all of those packets. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Fri Feb 20 14:19:53 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KMJqJx032599; Fri, 20 Feb 2004 14:19:53 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20077 Fri, 20 Feb 2004 16:46:06 -0500 (EST) Date: Fri, 20 Feb 2004 15:56:18 -0600 From: Nicolas Williams To: Stephen Kent Cc: Tero Kivinen , Charles Lynn , ipsec@lists.tislabs.com Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues Message-ID: <20040220215617.GK6177@binky.central.sun.com> Mail-Followup-To: Stephen Kent , Tero Kivinen , Charles Lynn , ipsec@lists.tislabs.com References: <16434.27900.199285.136682@fireball.acr.fi> <20040218161436.9707F2051E@wolfe.bbn.com> <16435.55623.26827.859229@fireball.acr.fi> <16438.958.625838.937789@fireball.acr.fi> <20040220175458.GC6177@binky.central.sun.com> <20040220200336.GF6177@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, Feb 20, 2004 at 04:15:14PM -0500, Stephen Kent wrote: > Nicolas, > > > > > > > >In BITW scenarios with SPDs that use port selectors this issue comes > > up, > >> >as it does in one side of SG/VPN scenarios, right? > >> > >> It used to be the case that transport mode was restricted to end > >> systems, but due to popular demand we have removed that restriction. > >> so, this used to be just a tunnel mode issue for SG scenarios, but it > >> might arise for transport mode too,under our new paradigm. > > > >I thought that SGs were allowed to use transport mode for administrative > >traffic where the SG is an end-point. Is this a misunderstanding of the > >new paradigm? If not then no issue here. > > The old model allowed SGs to use transport mode for admin traffic. > The new model allows SGs to use it for any traffic, e.g., so that an > overlay net that does IP-in-IP tunneling can use transport mode for > the already tunneled packets. But in that case the transport mode SAs would still be end-to-end and, outside the end-point fragmentation in BITS implementations, the clear packets would not be fragmented prior to application of transport-mode protection. Right? > > > > > > >> I'm not sure how to size the cache, but otherwise I think your > > > >Probably according to the proportion of traffic that is fragmented and > >which must be protected. > > that's hard to do a priori, right? if I am designing a hardware Ipsec > implementation and need to decide how much memory to include for this > purpose, this isn't a good algorithm :-) Right, but there is a limit: assume 100% of traffic to be protected is fragmented. :) I know, assuming 100% IPv6 traffic, 100% of packets fragmented, avg. fragment size on the order of 1-2KB and 4 fragments per-packet on avg. that would make the cache size be on the order of 1GB (!) for 10Gb/s. With more reasonable assumptions (and path MTUs :) I think an SG can get by with a far smaller cache, but one fast small-MTU link could cause the SG packet drop rates to make some users miserable. But this is "just" a trade-off: if you want support for the use multiple SAs for the same SA end-points plus port selectors in VPN/BITW SG SPDs then you must configure your network with sane MTUs. I'd better read Charlie Lynn's proposal now :) > > > analysis is correct, based on dropping non-initial fragments. one > >> also has to deal with housekeeping issues, e.g., timing out fragment > >> IDs, to prevent possible mismatches, and one needs to specify the > > > >How bad would mismatches be? They may get protected with an incorrect > >SA, but the receiver should be the same either way (if not, that would > >be a bigger deal) and should then simply drop them since they wouldn't > >match a correct first fragment (and if they did the result would, in all > >likelyhood, not match various checksums and the like, leading to the > >full packet being dropped which, again, would be within spec). > > i agree that they would be sent to the same destination, but since an > SG receiver is not required to reassemble plain text fragments, the > issue is what happens at the real destination. long ago when we > started discussing this issue there was a suggestion to check the > offset for non-initial fragments (pardon the redundancy) to make sure > that someone did not try to circumvent the receiver access control > mechanism by sending a fragment with a port field that would not have > been acceptable in a whole packet. this seems to be an easy check for > v4, but it's apparently not feasible for v6, and thus we do have a > concern re fragment reassembly attacks. If all necessary selectors are not visible in the initial fragment, drop. > I was uncomfortable with the notion that we might send over fragments > that don't really belong to the same packet, but maybe that's not > fatal. Right, it makes me queasy too, but seems to be within what one can expect of IP anyways. And since the fragmented packets are coming in on a clear interface (red, black, whatever the terminology is nowadays) the SG can't really vouch for their integrity; if the clear packets are really protected with a nested SA there's going to be no issue anyways, and if they're not, well, then presumably they can be trusted, else the SG wouldn't apply IPsec to them. > > > receiver-side algorithm too, e.g., remembering packet IDs for initial > >> fragments so that the later fragments are treated as acceptable. but, > >> is this easier than what Charlie Lynn described? > > > >I'd have to re-read that. In any case, the receiver already has to > >track packet IDs for reassembly, > > an IPsec device such as an SG does not have to reassemble plain text > fragments, at least not under the assumptions we have been using for > the last 5+ years. I meant an end-point receiver. Presumably an SG wouldn't have to reassemble packets it is tunnelling -- it would apply the fragment selector/id caching approach to select an SA for fragments (and then only if the SPD has entries that use selectors that can be obscured by fragmentation) as discussed. > >so now all it has to do in addition is > >track the SA that was used to protect each fragment and drop any > >fragments that don't use an acceptable SA. Unlike an SG, the receiver > >here probably wouldn't want to drop non-initial fragments received > >before their intial counterparts, if it can avoid it, and should have > >the necessary buffer space, usually, so the receiver here can behave as > >Tero proposed -- it does not seem like this would impose much of a > >burden on the receiver. > > a receiver that is an end system could plausibly do reassembly and > then subject the result to an access control check. Exactly. Nico -- From owner-ipsec@lists.tislabs.com Fri Feb 20 14:22:14 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KMMDF0032672; Fri, 20 Feb 2004 14:22:13 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20109 Fri, 20 Feb 2004 16:46:47 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16438.33527.955215.342633@fireball.acr.fi> Date: Fri, 20 Feb 2004 23:58:15 +0200 From: Tero Kivinen To: Stephen Kent Cc: Charles Lynn , ipsec@lists.tislabs.com Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues In-Reply-To: References: <16434.27900.199285.136682@fireball.acr.fi> <20040218161436.9707F2051E@wolfe.bbn.com> <16435.55623.26827.859229@fireball.acr.fi> <16438.958.625838.937789@fireball.acr.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 12 min X-Total-Time: 12 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > > 1) If it receives unknown non-first fragment, it will put it > > in the separate queue (queue length and number bytes > > consumed is limited). > > 2) When it receives the first-fragment it will find the SA > > suitable for it, and send packet forward. > > 3) Then it will search through the non-first fragments queue > > and find other fragments for the packet, and send those > > forward (verifying in the process that the fragments do not > > overwrite the fields used in selecting the SA). > > 4) It will create known-fragment entry to database, marking > > that if we see other fragments to this packet, they can be > > sent forward to this SA if they start after this offset. > > This entry will timeout after some time. > > this sounds like a reasonable mechanism, though perhaps not not a > very high speed context, since receipt of an initial fragment could > trigger transmission of delayed non-initial fragments, which implies > possible further disruption to transmission. but, under the right > circumstances I can certainly see how this could work. In most(*) of all cases the packets are processed in order, thus the only need is to store the information that allow other fragments of this packet to go through. (*) There used to be bug in the linux kernel where it sent all fragments always in reverse order, i.e. the last fragment first and the first fragment last. This bug was fixed some time ago, and all decent implementations should send the packets in order anyways, and because we are now talking about the connection from the end host to the SGW (from the senders point of view) there are not that often reordering happening in the internal network before the SGW. From the responder's point of view the case is harder, as the connection between SGW and SGW might more easily cause reordering of packets, thus forcing the responder to store the fragments coming before first-fragment. If the current approach is to drop all fragments (or create new SA for non-first fragments), I think this proposed solution have less impact on the overall performance of the system (ok, dropping all fragments would be faster, but not very workable solution). > right. so there is some reassembly-like processing at the receiver, > e.g., per SA state to remember initial fragment data plus queuing of > non-initial fragments to accommodate out or order delivery, etc. Yep. > >So it is not impossible, it simply requires some work. We do not need > >to do full reassembly, we simply need to mark that fragment matching > >this source/destination/protocol/id should be sent/received from this > >SA. > > you left put ports here, the crux of the problem, but I assume that > was just a typo, right? No, there are no ports there in the responder side. The responder will check the ports when processing the first fragment, from the rest of the fragments of the same packet it simply needs to know that they came from the same SA, and they do not overwrite the data already checked (i.e. source-ip/destination-ip/protocol/fragment-id are used to identify the fragments). > What concerns me is that the processing you describe could be a > significant burden, maybe even infeasible, for very high speed > operation. We have focused more on such operation in this round of > revisions, e.g., support for 64-bit sequence numbers and explicit > discussion of caches. Thus I would prefer a spec that works well in > all cases. I do not think it will cause that much more processing, it is much less processing that will be required if reassembly method is used instead. I.e. reassemble the packet when getting it in, then select SA, fragment it again, send it out, reassemble the packet in the other end again, check the security policy, fragment the packet again, and send it out. The reassembly method and the method described in the beginning of the email are interoperable. Also as the fragmented packets are not used that much, and even if they are used the packets are in most cases received in-order, and in those cases the extra processing burden caused is quite small. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Fri Feb 20 14:23:00 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KMMxWQ032692; Fri, 20 Feb 2004 14:23:00 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20233 Fri, 20 Feb 2004 16:50:54 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16438.33790.277777.604567@fireball.acr.fi> Date: Sat, 21 Feb 2004 00:02:38 +0200 From: Tero Kivinen To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: Re: Issue #83: Generation of ICMP responses for inbound packet requiring IPSEC protection In-Reply-To: References: <20040130232243.GA6423@thunk.org> <16434.24291.254422.111128@fireball.acr.fi> <16438.75.875878.718798@fireball.acr.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 4 min X-Total-Time: 3 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > >This kind of setup can be used for normal web-traffic etc, where you > >actually do not normally need to create IPsec SAs, but if you happen > >to have SA up, you can use it (it does not cause any harm either). > > it makes behavior non-deterministic, which is generally a bad thing > from a security perspective. In those cases the encryption is not for the real security, but simply encryption just because it is fun, and it will cause more traffic in the net to be encrypted, making large scale traffic analysis harder. > >Might be true, but there are implemenations which support this kind of > >operations. > > Then they are non-complaint. Does the RFC2401 really say, that you cannot expand the SPD at all, and all implementations MUST only support what is defined there. I thought that it specified mostly the minimum requirements not exact requirements what can and cannot be implemented (i.e. I would not call those extended versions non-complaint, I would call them IPsec + extensions versions :-). -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Fri Feb 20 14:23:56 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KMNtRf032737; Fri, 20 Feb 2004 14:23:55 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20203 Fri, 20 Feb 2004 16:49:54 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <579E83556A36E44EB2945CCE990B317401050F0C@EUR-MSG-02.europe.corp.microsoft .com> References: <579E83556A36E44EB2945CCE990B317401050F0C@EUR-MSG-02.europe.corp.microsoft .com> Date: Fri, 20 Feb 2004 16:34:43 -0500 To: "Michael Roe" From: Stephen Kent Subject: RE: SAs that carry fragments Was: Re: Some IKEv2 issues Cc: 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 17:51 +0000 2/20/04, Michael Roe wrote: > >From this discussion, it would appear that there is some disagreement >about exactly which packets are matched by the "ANY" and "OPAQUE" >traffic selectors. RFC 2401 and draft-ietf-ipsec-rfc2401bis-01.txt >aren't very clear on this point. Perhaps rfc2401bis should be updated >to be more explicit about this? yes, we need to be more explicit, and that has motivated some of the discussion. >It's clear that a port selector of OPAQUE will match a non-initial fragment, >and a port selector of "ANY" will match an initial fragment with a cleartext >port number in it. The slightly trickier cases are >(a) Does "OPAQUE" match an initial fragment with a cleartext port >number in it? >(b) Does "ANY" match a non-initial fragment? yes, these are the questoins we are trying to resolve. >Rfc2401bis, section 6, says 'Thus, fragments not containing port numbers may >only match rules having port selectors of OPAQUE or "ANY"' - implying that >the answer to question (b) is yes. we waffled on this, and you see the result of the waffling :-) if we don't specify different behavior for ANY vs. OPAQUE, then we need not have both, e.g., we can have just ANY. >I would guess that "OPAQUE" doesn't match packets in which the port numbers >are visible, but the architecture document isn't very clear. that was the intent, but we need to be clear and nail it down. >draft-ietf-ipsec-ikev2-12.txt doesn't define separate traffic selectors for >"ANY" and "OPAQUE", it just allows a port range of 0..65535. It looks to me >as though IKEv2 is inconsistent with the architecture document. Yep. we exchanged mail with Charlie K on this, and he asked us to bring it to the list for resolution. Steve From owner-ipsec@lists.tislabs.com Fri Feb 20 14:37:17 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KMbHWg033228; Fri, 20 Feb 2004 14:37:17 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20684 Fri, 20 Feb 2004 17:04:40 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16438.34606.154448.734022@fireball.acr.fi> Date: Sat, 21 Feb 2004 00:16:14 +0200 From: Tero Kivinen To: Stephen Kent Cc: Nicolas Williams , Charles Lynn , ipsec@lists.tislabs.com Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues In-Reply-To: References: <16434.27900.199285.136682@fireball.acr.fi> <20040218161436.9707F2051E@wolfe.bbn.com> <16435.55623.26827.859229@fireball.acr.fi> <16438.958.625838.937789@fireball.acr.fi> <20040220175458.GC6177@binky.central.sun.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 7 min X-Total-Time: 11 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > >Or just drop non-initial fragments arriving before their corresponding > >initial fragments (or so much later that the corresponding initial > >fragments have fallen off the cache). > > > >IP can lose packets. Sometimes it's good to excercise this feature. > > yes, sometimes taking advantage of this "feature" can make our lives > easier as designers ;-) Yes, but as vendors shipping code, it would be quite unacceptable to tell that sorry, any linux n.y box you have in the network cannot get any fragmented packets through your SGW. Some linux kernel versions used to send all fragments in reverse order, meaning that for all fragmented packets all the other fragments than the non-first would be dropped. > >In transport mode scenarios (IPv4) this doesn't apply either since the ... > In a BITS implementation the host could have fragmented prior to > IPsec receiving the packet, but one would certainly expect that the > first fragment would arrive at the BITS first in that case. I think you have no other way than to reassemble the packet in those cases. The rfc2401 and rfc2401bis both say that you cannot apply IPsec using transport mode to IPv4 packets that are fragments. I.e. if the BITS implementation receives a fragmented packet and the SA is in transport mode, it must first reassemble the packet, then apply IPsec and then fragment the packet again. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Fri Feb 20 14:53:19 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KMrIxs034355; Fri, 20 Feb 2004 14:53:19 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA21863 Fri, 20 Feb 2004 17:13:50 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16438.35158.75299.704287@gargle.gargle.HOWL> Date: Fri, 20 Feb 2004 17:25:26 -0500 From: Paul Koning To: bora@cisco.com Cc: ipsec@lists.tislabs.com Subject: RE: Traffic Selectors (was SA fragments) References: <004a01c3f7ee$c744ae30$060a0a0a@amer.cisco.com> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Bora" == Bora Akyol writes: Bora> I wrote several responses to this, but chose not to send them, Bora> if there is no technical merit to my proposal on traffic Bora> selectors, then be it. >> -----Original Message----- From: Stephen Kent >> >> ... I think you are way >> too late and have contributed far too little to be taken seriously >> in this regard. Bora is right. If his suggestions have technical merit, they have that merit whether he has contributed for 20 years or 20 days. Conversely, if they have no merit, they would still have no merit even if he had contributed far longer and far more. Can we please evaluate proposals on their technical merit and leave ad hominem comments out? Thanks, paul From owner-ipsec@lists.tislabs.com Fri Feb 20 14:57:45 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KMvim9034938; Fri, 20 Feb 2004 14:57:45 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22376 Fri, 20 Feb 2004 17:17:45 -0500 (EST) Date: Fri, 20 Feb 2004 16:29:11 -0600 From: Nicolas Williams To: Stephen Kent , Tero Kivinen , Charles Lynn , ipsec@lists.tislabs.com Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues Message-ID: <20040220222911.GA6178@binky.central.sun.com> Mail-Followup-To: Stephen Kent , Tero Kivinen , Charles Lynn , ipsec@lists.tislabs.com References: <20040218161436.9707F2051E@wolfe.bbn.com> <16435.55623.26827.859229@fireball.acr.fi> <16438.958.625838.937789@fireball.acr.fi> <20040220175458.GC6177@binky.central.sun.com> <20040220200336.GF6177@binky.central.sun.com> <20040220215617.GK6177@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040220215617.GK6177@binky.central.sun.com> User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, Feb 20, 2004 at 03:56:17PM -0600, Nicolas Williams wrote: > I'd better read Charlie Lynn's proposal now :) IIUC Charlie Lynn's proposal is to assign one SA to protect all fragments even though multiple SAs may be used for different ports, yes? I think this defeats the notion of having SGs with SPD entries with port selectors where the different SAs for the same SA end-points have effectively different IDs (e.g., different userFqdn IDs), though this can be mitigated. Presumably such cases involve a multi-user end-point and this multi-user end-point runs trusted code (i.e., its OS kernel) and may even have a host cert/key; using an SA whose ID corresponds to the host for protecting the fragments would be a fine mitigation, as would multiply-authenticating[*] the SA for carrying fragments (as long as the trusted code in the end-point protects its DH private numbers and SA keys from its users). As compared to Tero's proposal (and with my comments) this is a lighter weight solution -- setting up an SA and adding an SPD entry may be a burden, but that would be less than the burden of keeping initial fragment selector/ID cache (see previous post). [*] Is it possible to run multiple AUTH exchanges for a single IKE_SA with different certs? Obviously the IKE_SA can only have one IDi/IDr... Nico -- From owner-ipsec@lists.tislabs.com Fri Feb 20 16:02:50 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1L02nmx038163; Fri, 20 Feb 2004 16:02:49 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28872 Fri, 20 Feb 2004 18:27:21 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16438.34606.154448.734022@fireball.acr.fi> References: <16434.27900.199285.136682@fireball.acr.fi> <20040218161436.9707F2051E@wolfe.bbn.com> <16435.55623.26827.859229@fireball.acr.fi> <16438.958.625838.937789@fireball.acr.fi> <20040220175458.GC6177@binky.central.sun.com> <16438.34606.154448.734022@fireball.acr.fi> Date: Fri, 20 Feb 2004 18:38:04 -0500 To: Tero Kivinen From: Stephen Kent Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues Cc: Nicolas Williams , Charles Lynn , 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:16 +0200 2/21/04, Tero Kivinen wrote: >Stephen Kent writes: >> >Or just drop non-initial fragments arriving before their corresponding >> >initial fragments (or so much later that the corresponding initial >> >fragments have fallen off the cache). >> > >> >IP can lose packets. Sometimes it's good to excercise this feature. >> >> yes, sometimes taking advantage of this "feature" can make our lives >> easier as designers ;-) > >Yes, but as vendors shipping code, it would be quite unacceptable to >tell that sorry, any linux n.y box you have in the network cannot get >any fragmented packets through your SGW. Some linux kernel versions >used to send all fragments in reverse order, meaning that for all >fragmented packets all the other fragments than the non-first would be >dropped. Well, I guess the ;-) should be a ;-( in that case. > > >In transport mode scenarios (IPv4) this doesn't apply either since the >... >> In a BITS implementation the host could have fragmented prior to >> IPsec receiving the packet, but one would certainly expect that the >> first fragment would arrive at the BITS first in that case. > >I think you have no other way than to reassemble the packet in those >cases. The rfc2401 and rfc2401bis both say that you cannot apply IPsec >using transport mode to IPv4 packets that are fragments. I.e. if the >BITS implementation receives a fragmented packet and the SA is in >transport mode, it must first reassemble the packet, then apply IPsec >and then fragment the packet again. yes, that's true. I forgot that we had imposed that constraint. Steve From owner-ipsec@lists.tislabs.com Fri Feb 20 16:05:54 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1L05sUs038293; Fri, 20 Feb 2004 16:05:54 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28851 Fri, 20 Feb 2004 18:27:05 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16438.32792.613873.117981@fireball.acr.fi> References: <00c301c3f723$fa3577f0$060a0a0a@amer.cisco.com> <16438.3734.624347.316169@fireball.acr.fi> <16438.32792.613873.117981@fireball.acr.fi> Date: Fri, 20 Feb 2004 17:44:10 -0500 To: Tero Kivinen From: Stephen Kent Subject: RE: SAs that carry fragments Was: Re: Some IKEv2 issues Cc: "Bora Akyol" , "'Barbara Fraser'" , "'Charles Lynn'" , 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:46 +0200 2/20/04, Tero Kivinen wrote: >Stephen Kent writes: >> We've had analogous debates on this before. IPsec is NOT just a VPN >> technology and our specs ought not be VPN-specific. I have certainly >> advised folks to use port selectors for tunnels under certain >> instances, e.g., to restrict traffic to a server to be traffic of the >> sort appropriate to that server, based on the well known ports >> associated with the service. > >How have they handled the fragmentation issue in those cases, or have >the simply assumed that the fragmentation will not happen, and ignored >all of those packets. I suggested that they work hard to ensure that there are no fragments emitted by hosts within their environments. This works for TCP services, which is what was of primary interest, but would not work for UDP. We recognized that the lack of detailed specs for how to deal with fragments was a problem. Steve From owner-ipsec@lists.tislabs.com Fri Feb 20 16:06:37 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1L06bZQ038328; Fri, 20 Feb 2004 16:06:37 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28835 Fri, 20 Feb 2004 18:26:58 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16438.35158.75299.704287@gargle.gargle.HOWL> References: <004a01c3f7ee$c744ae30$060a0a0a@amer.cisco.com> <16438.35158.75299.704287@gargle.gargle.HOWL> Date: Fri, 20 Feb 2004 18:36:34 -0500 To: Paul Koning From: Stephen Kent Subject: RE: Traffic Selectors (was SA fragments) Cc: bora@cisco.com, 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 17:25 -0500 2/20/04, Paul Koning wrote: > >>>>> "Bora" == Bora Akyol writes: > > Bora> I wrote several responses to this, but chose not to send them, > Bora> if there is no technical merit to my proposal on traffic > Bora> selectors, then be it. > > >> -----Original Message----- From: Stephen Kent > >> > >> ... I think you are way > >> too late and have contributed far too little to be taken seriously > >> in this regard. > >Bora is right. > >If his suggestions have technical merit, they have that merit whether >he has contributed for 20 years or 20 days. Conversely, if they have >no merit, they would still have no merit even if he had contributed >far longer and far more. > >Can we please evaluate proposals on their technical merit and leave >ad hominem comments out? > >Thanks, > paul Paul, OK, you opened the dialogue, so I'll respond. We have been working on IPsec for a very long time. We need not address every suggestion for a change that arises from anyone. If we did, we will never finish. Most WGs understand this and operate on that basis. In this case, Bora made an absurd, and to me, offensive, assertion, i.e., "I think there is agreement that port based selectors do not make sense for tunnel mode." There is no rational basis for this assertion, based on the message exchanges on the list. In my opinion, anyone who sends a message of this sort is way off base. So, I checked my files to see if this was a comment from someone who had a track record of contributing, since I am willing to give some credence to an individual who has been a contributor. The result of my search is exactly what I stated. It is an ad hominem argument only to the extent that it provides a factual characterization of why I believe his comments ought to be ignored. While you are right that, in principle, anyone may be able to contribute a good idea to a discussion, we don't have the time to devote to work this way. Ask the ADs if they think we should reconsider every aspect of the WG's work based on comments from anyone who chooses to send a message, irrespective of his/her contributory status. If someone finds an objective, technical flaw in what we have proposed, then fine. But when someone suggests that, based on his personal view, an extant feature of an existing standard should be dropped and replaced with another, remotely analogous feature, that's a different matter. As for the substance of his suggestion, I find that it has NO merit. It is: - half-baked (what if the offset goes beyond the next layer protocol headers into data?, how do we apply this to a fragment? how would it work with IPv6 headers with header extensions? how would it work with IPv4 packets that contain options? ...) - it would lead to interop problems because it's a "MAY" and because it imposes no constraints on what offsets, lengths and mask vales might be defined, thus leading to a new set of peer SPD coordination requirements. any other questions? Steve From owner-ipsec@lists.tislabs.com Fri Feb 20 16:39:33 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1L0dX9b039655; Fri, 20 Feb 2004 16:39:33 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01442 Fri, 20 Feb 2004 19:03:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Traffic selectors in IKEv2 Date: Fri, 20 Feb 2004 16:15:06 -0800 Message-ID: Thread-Topic: Traffic selectors in IKEv2 Thread-Index: AcP34SRUdAnXRqfnSG+LkYKnzZe3bAALbysQ From: "Charlie Kaufman" To: "Mohan Parthasarathy" , X-OriginalArrivalTime: 21 Feb 2004 00:14:44.0149 (UTC) FILETIME=[B501AE50:01C3F80F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id TAA01437 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My reading of the spec is that this is allowed, and I can imagine it being useful. If I as a road warrior tunnel into my corporate network and want all of my internet traffic to be routed through the corporate network in order to protected by its firewall, I would want to tunnel all addresses. Stretching my imagination only a little further, I can imagine wanting multiple SAs to separate voice and data traffic (because the network might do some different QOS for the two kinds of traffic). --Charlie -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Mohan Parthasarathy Sent: Friday, February 20, 2004 10:34 AM To: ipsec@lists.tislabs.com Subject: Traffic selectors in IKEv2 I have a couple of questions on the Traffic selectors in IKEv2. 1) Traffic selectors allow a range of addresses. Is the range encompassing all the addresses from 0 to 255.255.255.255 valid (similarly for IPv6) ? Nothing in the spec seems to preclude it. 2) IKEv2 specifically allows multiple IPsec SAs to co-exist (and be used) for the same traffic selector between same endpoints. i would assume that multiple SAs for the selectors specifying all the addresses is still possible between the same endpoints. Is that allowed ? thanks mohan From owner-ipsec@lists.tislabs.com Fri Feb 20 16:48:33 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1L0mWds039928; Fri, 20 Feb 2004 16:48:33 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA03111 Fri, 20 Feb 2004 19:16:55 -0500 (EST) Message-ID: <4036A620.2020502@isi.edu> Date: Fri, 20 Feb 2004 16:28:16 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams CC: Stephen Kent , Tero Kivinen , Charles Lynn , ipsec@lists.tislabs.com Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues References: <16434.27900.199285.136682@fireball.acr.fi> <20040218161436.9707F2051E@wolfe.bbn.com> <16435.55623.26827.859229@fireball.acr.fi> <16438.958.625838.937789@fireball.acr.fi> <20040220175458.GC6177@binky.central.sun.com> <20040220200336.GF6177@binky.central.sun.com> <20040220215617.GK6177@binky.central.sun.com> In-Reply-To: <20040220215617.GK6177@binky.central.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Nicolas Williams wrote: > On Fri, Feb 20, 2004 at 04:15:14PM -0500, Stephen Kent wrote: > >>Nicolas, >> >> >> >> >>>>>In BITW scenarios with SPDs that use port selectors this issue comes >>> >>>up, >>> >>>>>as it does in one side of SG/VPN scenarios, right? >>>> >>>>It used to be the case that transport mode was restricted to end >>>>systems, but due to popular demand we have removed that restriction. >>>>so, this used to be just a tunnel mode issue for SG scenarios, but it >>>>might arise for transport mode too,under our new paradigm. >>> >>>I thought that SGs were allowed to use transport mode for administrative >>>traffic where the SG is an end-point. Is this a misunderstanding of the >>>new paradigm? If not then no issue here. >> >>The old model allowed SGs to use transport mode for admin traffic. >>The new model allows SGs to use it for any traffic, e.g., so that an >>overlay net that does IP-in-IP tunneling can use transport mode for >>the already tunneled packets. > > But in that case the transport mode SAs would still be end-to-end and, > outside the end-point fragmentation in BITS implementations, the clear > packets would not be fragmented prior to application of transport-mode > protection. Right? The transport-mode SAs could be at the SGs. In that case, the clear packets might be fragmented when tunneled (due to the additional header), which would be before transport-mode processing. > I meant an end-point receiver. Presumably an SG wouldn't have to > reassemble packets it is tunnelling -- it would apply the fragment > selector/id caching approach to select an SA for fragments (and then > only if the SPD has entries that use selectors that can be obscured by > fragmentation) as discussed. I would expect that the IP tunnel dest. endpoint would reassemble, but that would happen after receive SG transport-mode processing if using transport + IPIP tunnels. Joe From owner-ipsec@lists.tislabs.com Fri Feb 20 16:52:25 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1L0qPP3040040; Fri, 20 Feb 2004 16:52:25 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA03743 Fri, 20 Feb 2004 19:21:31 -0500 (EST) From: "Bora Akyol" To: "'Stephen Kent'" , "'Paul Koning'" Cc: Subject: RE: Traffic Selectors (was SA fragments) Date: Fri, 20 Feb 2004 16:33:09 -0800 Message-ID: <006101c3f812$487542d0$060a0a0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "I think there is agreement that port based selectors do not > make sense for tunnel mode." There is no rational basis for this > assertion, based on the message exchanges on the list. In my opinion, > anyone who sends a message of this sort is way off base. > Steve, please give a real world deployment example of how and why the port selectors are used in tunnel mode? Why does a network administrator define a security policy that secures one port in tunnel mode differently than another. Then how is this administrator sure that some malicious user is not circumventing his policy and intentionally bypassing the port based selectors. What is the most common application of tunnel mode on the Internet today? VPNs either site-to-site or remote-to-security gateway are 99% of the IPSEC deployments today. Transport mode is used pretty much to secure GRE-over-IPSEC and avoid double header penalties. Other than, it is all tunnels all the time and none of these actually use port selectors. The amount of people that participate on this list actively and exchange messages, is a minute fraction of a percent when compared to people that have actually deployed IPSEC. This is starting to remind me a lot about the three monkeys, so I am going to change the channel and go to the technical aspects of my proposal :---> > As for the substance of his suggestion, I find that it has NO > merit. It is: > > - half-baked (what if the offset goes beyond the next layer > protocol headers into data?, how do we apply this to a fragment? how > would it work with IPv6 headers with header extensions? how would it > work with IPv4 packets that contain options? ...) > Think of this as a construct in a programming language. With this construct you can define either a TCP port or range, or you can even define a completely different value/range set based on ip protocol type. For example I may choose a field in the GRE header and treat ranges in it differently using the security policy. The idea is not half-baked. People have been using this type of a construct in various hardware (ASIC-based) or network processors for a LOOOOONG time. And bounds checking and validation should be part of any good software implementation. Or you can even use an MPLS label when encapsulated in IP to decide what kind of security policy needs to get applied. I am guessing such a flexible format can come in handy even for some storage applications. > - it would lead to interop problems because it's a "MAY" and > because it imposes no constraints on what offsets, lengths and mask > vales might be defined, thus leading to a new set of peer SPD > coordination requirements. > I left this out as a MAY/SHOULD because based on my experience in looking at customer problems, bugs, interoperability issues since 2001, I have not seen people use ports as selectors and personally I think this is really an optional feature until someone writes an application that can make use of it. Tuples that contain IP SA/DA masks/ranges and proto values seem to be enough for 99% of the people out there. And finally, there was no reason to discredit me or insult my intelligence either but you chose to do this anyway. You could have just argued your case on the technical merits. Everyone knows who you are, not many people know me unless they have read RFC3443 or were in the MPLS WG. IMHO, this is no way conduct a conversation on any WG in the IETF. Bora -- Speechless SW engineer in San Jose (SSEISJ) From owner-ipsec@lists.tislabs.com Fri Feb 20 17:57:29 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1L1vTgV043831; Fri, 20 Feb 2004 17:57:29 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA09970 Fri, 20 Feb 2004 20:13:09 -0500 (EST) Message-ID: <01c601c3f819$7f859e80$eb1167c0@adithya> From: "Mohan Parthasarathy" To: "Charlie Kaufman" , References: <01ac01c3f817$3d5da770$eb1167c0@adithya> Subject: Re: Traffic selectors in IKEv2 Date: Fri, 20 Feb 2004 17:24:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie, > My reading of the spec is that this is allowed, and I can imagine it > being useful. If I as a road warrior tunnel into my corporate network > and want all of my internet traffic to be routed through the corporate > network in order to protected by its firewall, I would want to tunnel > all addresses. > In this case, the road warrior would use TSr with the selector that encompasses all addresses ("all-traffic") and TSi as its own address allocated earlier in the CFG request. I wanted to know about the TSi. Can TSi contain the "all-traffic" selector ? This is useful for other VPN cases e.g. PPVPNs. In this case, you need other mechanisms to direct traffic to the right tunnel. In the road warrior case SG would use the road warrior's address to direct packets to the tunnel. So, can TSi and TSr contain "all-traffic" selector ? I assume that the spec itself does not preclude this. But the peer may refuse to accept (or trim) such a selector. Is that right ? -thanks mohan > Stretching my imagination only a little further, I can imagine wanting > multiple SAs to separate voice and data traffic (because the network > might do some different QOS for the two kinds of traffic). > > --Charlie > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Mohan Parthasarathy > Sent: Friday, February 20, 2004 10:34 AM > To: ipsec@lists.tislabs.com > Subject: Traffic selectors in IKEv2 > > I have a couple of questions on the Traffic selectors in IKEv2. > > 1) Traffic selectors allow a range of addresses. Is the range > encompassing all the addresses > from 0 to 255.255.255.255 valid (similarly for IPv6) ? Nothing in > the spec seems to > preclude it. > > 2) IKEv2 specifically allows multiple IPsec SAs to co-exist (and be > used) for the same traffic > selector between same endpoints. i would assume that multiple SAs > for the selectors specifying > all the addresses is still possible between the same endpoints. Is > that allowed ? > > thanks > mohan From owner-ipsec@lists.tislabs.com Fri Feb 20 18:40:03 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1L2e3TF046030; Fri, 20 Feb 2004 18:40:03 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA12954 Fri, 20 Feb 2004 20:58:32 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Fri, 20 Feb 2004 18:09:58 -0800 To: cfrg@ietf.org, , Charlie Kaufman From: Paul Hoffman / VPNC Subject: Re: [Cfrg] Re: Changing the key deriveration Cc: Hugo Krawczyk , "The Purple Streak, Hilarie Orman" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:57 PM +0200 2/17/04, Hugo Krawczyk wrote: >Anyway, replacing SK_ai and SK_ar in the above text (as well as in 2.15, >first paragraph) with SK_d does resolve the problem of using two >algorithms (prf and integrity) with the same key, and it is much better >than what is done now. There have been no more comments on this, and the ADs are still waiting for a final draft of this document so they can move all three IKEv2 documents to IETF last call. Charlie: are you OK with this solution? If so, can you get the new draft out soon, such as when the Internet Drafts window opens? --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Feb 20 19:13:23 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1L3DMfY047484; Fri, 20 Feb 2004 19:13:22 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA16538 Fri, 20 Feb 2004 21:27:53 -0500 (EST) Date: Fri, 20 Feb 2004 19:36:54 -0700 Message-Id: <200402210236.i1L2asDw018580@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: bora@cisco.com Cc: ipsec@lists.tislabs.com In-reply-to: Yourmessage <006101c3f812$487542d0$060a0a0a@amer.cisco.com> Subject: RE: Traffic Selectors (was SA fragments) X-esmartscan-MailScanner: Found to be clean Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve made the perfectly valid point that you had years of opportunity to suggest a major change but chose not to. If you feel that reflects badly on your intelligence, suffer in silence. You also made a sweeping assertion, setting yourself up as a self-proclaimed expert, and Steve takes issue with that. Finally, it is completely typical for IETF draft authors to go ballistic when they are nearly finished with a long and complex document that has had a lot of WG input and then, at the last minute, find people popping out of the mailing list with major changes. In fact, in my experience, they go ballistic over just about anything short of "looks great". Human beings as they are and all. Hilarie Orman Infrequent poster On Fri, 20 Feb 2004 at 16:33:09 -0800 Bora Akyol asserted: > And finally, > there was no reason to discredit me or insult my intelligence either > but you chose to do this anyway. You could have just argued your > case on the technical merits. Everyone knows who you are, not many > people know me unless they have read RFC3443 or were in the MPLS WG. IMHO, > this is no way conduct a conversation on any WG in the IETF. From owner-ipsec@lists.tislabs.com Sat Feb 21 00:06:44 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1L86Vrt003845; Sat, 21 Feb 2004 00:06:44 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA21578 Sat, 21 Feb 2004 02:13:07 -0500 (EST) From: "Bora Akyol" To: Cc: "Bora Akyol" Subject: RE: Traffic Selectors (was SA fragments) Date: Fri, 20 Feb 2004 23:24:46 -0800 Message-ID: <001c01c3f84b$c8f17990$060a0a0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-reply-to: <200402210236.i1L2asDw018580@localhost.localdomain> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Since these documents are about to go to Last Call (and I have been there before), this will be my last email on this subject. The thread is not productive other than raising my blood pressure :-) And finally my apologies to the WG and Steve Kent specifically for dragging on this thread longer than it needed to be and not engaging in the conversation 3 years ago. However, I would love to hear private/public opinions to the semi-coherent thought train that I wrote below: ---------------- How come I have not seen IPSEC policy specified that contains TCP/UDP port selectors in reports from the field? Then I realized, when I use an SSL enabled POP client to get my email, I am in fact using transport layer security with TCP port numbers. When I check my bank account balance, there again, SSL. So answering Nicolas's question about multi-user trusted OS, if I am an application developer and I have the SSL API available to me, why do I trust the network layer to provide me with the security? I don't, I use SSL or transport layer security. One could also argue that this makes the application more robust since it is not dependent on a lower layer for security. If IP is the network layer, and IPSEC is a network layer protocol, why does a network layer security protocol care about transport layer traffic selectors? Is the inclusion of transport layer traffic selectors (TCP/UDP ports) an optimization in the original design? Or is it now an redundant feature with the pervasive deployment of SSL/TLS? Would application developers actually ever trust the network layer to provide them with the security that they need? How can an application trust the network administrator (especially in a shared system) to correctly configure security on a per transport layer demux port basis especially when money or financial information is involved? That is, unless everyone is sharing the same security policy in which case the port-based selectors are not needed. If all one wants to do is secure a particular application running over a specific but not pre-determined port (dynamic), then is the transport layer security the easier way to go? Only time and deployment experience will tell the rest of the story in terms of what features get used or are left to die. However, if the recent uptake in SSL-VPNs (search google/light reading for market predictions) is an indication, we have interesting times ahead. Regards, Bora -- Sleepless SW Engineer in San Jose From uxbezbdvjou@yahoo.com Sat Feb 21 19:39:44 2004 Received: from h24-71-81-52.ok.shawcable.net (h24-71-81-52.ok.shawcable.net [24.71.81.52]) by above.proper.com (8.12.11/8.12.8) with SMTP id i1M3cZ8L091205; Sat, 21 Feb 2004 19:39:09 -0800 (PST) (envelope-from uxbezbdvjou@yahoo.com) Date: Sat, 21 Feb 2004 19:38:35 -0800 (PST) From: uxbezbdvjou@yahoo.com Received: from 42.168.184.136 by 24.71.81.52; Sun, 22 Feb 2004 22:44:48 -0500 Message-ID: To: Subject: Re: Fwd: Certicom IP Rights Date: Sun, 22 Feb 2004 23:18:22 -0800 Message-ID: <000801c3f9dd$38fd7850$52f4200a@sfluhrerhpc> 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have examined the patents that Certicom has cited in their IP claim, and list what I found below. Now, of course, I am not a lawyer, and I am not giving legal advice. >To: housley@vigilsec.com >From: Ian McKinnon >Date: Fri, 31 Oct 2003 15:14:09 -0500 > > >Dear Mr. Housley: > >We wish to advise the IETF that Certicom believes it has rights under >patents and/or pending applications that relate to RFC 3526 "More Modular >Exponential (MODP) Diffie-Hellman Groups for Internet Key Exchange (IKE)", >RFC 2409 "Internet Key Exchange", Internet Draft >(draft-ietf-ipsec-ikev2-11.txt) "Internet Key Exchange (IKEv2) Protocol" >and other IETF standards using MODP Groups. The applicable patents >include, but are not limited to, US Patents #5,933,504, #6,563,928, >#6,078,667, #6,178,507, #6,195,433, US Patent Application Publications >#2001/0014153, #2002/0090085, and PCT Application #WO 00/01109, and >corresponding foreign applications. Patent claims: 5,933,504: 6,563,928: (6,563,928 is an extended version of 5,933,504 with more claims and so I address both together) Both patents are concerned with the Diffie-Hellman protocol and detecting whether the public values received from the peer is within a weak subgroup, that is, a value that would generate a relatively small number of values for the shared secret. The reasoning for this is that an attacker may be able to introduce weak values for both exchanged public values, and thus trick both sides into computing an easily guessable shared secret. Note that both IKEv1 and IKEv2 defend against this attack in manners that differ from the method listed in the patent. That might sound reasonable, however, the MODP modulii that IKE uses are all of the form (2*q+1) for q prime, and the generator used is a quadratic residue to those modulii. What this implies (in English) is that these groups have only one small subgroup, namely the trivial subgroup consisting of the single element {1}. This means that the patented operation is, in this case, comparing the public value you received from the peer (KE payload) against the value 1, and rejecting it if so. This brings up two obvious points: - Is such an operation patentable? Rejecting illegal values has been a part of programming for quite a while. Of course, I am not a lawyer. (Also note that, if you are rejecting illegal values, you would also want to reject the values 0, p-1, p, p+1, which do not appear to be a part of the Certicom patents). - None of the cited IETF documents (RFC3526, RFC2409, the draft IKEv2 document) mandates (or even mentions) such an operation. It is thus difficult to say why these documents, or an implementation based on these documents, are in violation of either patent. 6,078,667: This patents a method of generating "unique and unpredictable values" for use as a private key within a public key encryption system. However, the cited IETF documents do not mandate a way for generating the Diffie-Hellman exponents (and I cannot see any other way of applying this patent). As such, it is thus difficult to say why these documents are in violation of this patent. 6,178,507: This patents a method of authentication involving elliptic curves. As the claims are limited systems involving ECC, this is inapplicable to the MODP-based protocols in question. 6,195,433: This patents the idea of using statistical tests (or 'predetermined set of criteria') when generating private keys. As the cited IETF documents do not mandate any such tests, it is thus difficult to say why these documents are in violation of this patent. US Patent Application Publications 2001/0014153: This patents the idea of checking a generated public/private key pair for validity. As the cited IETF documents do not mandate any such checks, it is difficult to say why these documents are in violation. 2002/0090085: This patents a method of generating a random number between 0 and q (the order of a group). The cited IETF documents do not mandate any such method for generating the Diffie-Hellman exponents (and for MODP groups, you generally don't generate exponents as large as the group order), and thus it is difficult to say why these documents are in violation. I have no idea how to find PCT Application #WO 00/01109, and so I did not examine that. It is possible that WO 00/01109 or some of the uncited patents or non-US patent applications may be applicable. However, in every case I did examine, I could not see how any of the IETF documents in question, or an implementation based on such documents, would necessarily be in violation. I would encourage other people to scan through these patents, and see if my assessments are accurate. And again, for the third time, I am not a lawyer, and please do not use my opinions as legal advise. -- scott From owner-ipsec@lists.tislabs.com Mon Feb 23 08:02:18 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1NG2HNd000232; Mon, 23 Feb 2004 08:02:18 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04327 Mon, 23 Feb 2004 10:23:39 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <006101c3f812$487542d0$060a0a0a@amer.cisco.com> References: <006101c3f812$487542d0$060a0a0a@amer.cisco.com> Date: Mon, 23 Feb 2004 10:31:48 -0500 To: "Bora Akyol" From: Stephen Kent Subject: RE: Traffic Selectors (was SA fragments) Cc: 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:33 -0800 2/20/04, Bora Akyol wrote: > "I think there is agreement that port based selectors do not >> make sense for tunnel mode." There is no rational basis for this >> assertion, based on the message exchanges on the list. In my opinion, >> anyone who sends a message of this sort is way off base. >> > >Steve, please give a real world deployment example of how and why >the port selectors are used in tunnel mode? > >Why does a network administrator define a security policy >that secures one port in tunnel mode differently than another. Then >how is this administrator sure that some malicious user >is not circumventing his policy and intentionally bypassing >the port based selectors. wrong question, again. port-level access controls can be used to allow access to some set of services at an address, but not others. for example, one could allow access to HTTP on a web server, but not SMTP. if this control were applied symmetrically, then the worm that compromised IIS systems would not have been able to spread itself to other sites via e-mail from compromised servers. is that a good enough example? >What is the most common application of tunnel mode on the Internet >today? > >VPNs either site-to-site or remote-to-security gateway are >99% of the IPSEC deployments today. Transport mode is used >pretty much to secure GRE-over-IPSEC and avoid double header >penalties. Other than, it is all tunnels all the time >and none of these actually use port selectors. we don't develop standards to accommodate only what people do today. if we did, then TCP would not be usable with HTTP, since when we developed TCP) the primary apps using it were Telnet, e-mail, and FTP. >The amount of people that participate on this list actively >and exchange messages, is a minute fraction of a percent >when compared to people that have actually deployed IPSEC. and the number of people who fly on planes or pilot them is much greater than the number who design planes. your point is ...? >And finally, >there was no reason to discredit me or insult my intelligence either >but you chose to do this anyway. You could have just argued your >case on the technical merits. Everyone knows who you are, not many >people >know me unless they have read RFC3443 or were in the MPLS WG. IMHO, >this is no way conduct a conversation on any WG in the IETF. I didn't question your intelligence. I pointed out how I perform triage on the vast quantity of messages with which I have to deal. I don't like wasting time responding to every message someone sends recommending a change to a spec. If the author of a message is someone with a track record of significant contributions, then I always pay attention, even if that person has not sent any traffic for a while. if the message is well thought out and polite, even if not from someone I know, it too will probably merit a polite reply. Your message failed both of these tests. In retrospect it might have been better to just ignore it. Steve From owner-ipsec@lists.tislabs.com Mon Feb 23 08:02:31 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1NG2UN9000244; Mon, 23 Feb 2004 08:02:30 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04317 Mon, 23 Feb 2004 10:23:37 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <001c01c3f84b$c8f17990$060a0a0a@amer.cisco.com> References: <001c01c3f84b$c8f17990$060a0a0a@amer.cisco.com> Date: Mon, 23 Feb 2004 10:10:01 -0500 To: "Bora Akyol" From: Stephen Kent Subject: RE: Traffic Selectors (was SA fragments) Cc: 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:24 -0800 2/20/04, Bora Akyol wrote: >Since these documents are about to go to Last Call >(and I have been there before), this will be my last email >on this subject. >The thread is not productive other than raising my blood pressure :-) > >And finally my apologies to the WG and Steve Kent specifically for >dragging on this >thread longer than it needed to be and not engaging in the conversation >3 years ago. > >However, I would love to hear private/public opinions to the >semi-coherent >thought train that I wrote below: > >---------------- > >How come I have not seen IPSEC policy specified >that contains TCP/UDP port selectors in reports from >the field? I cannot account for what you have or have not seen. >Then I realized, when I use an SSL enabled POP client >to get my email, I am in fact using transport layer security >with TCP port numbers. >When I check my bank account balance, there again, SSL. Presumably you are trying to argue that if one wants port level security, the one uses SSL, but SSL does NOT provide any built, in access controls, so this is an odd comparison. >So answering Nicolas's question about multi-user trusted OS, >if I am an application developer and I have the SSL API available >to me, why do I trust the network layer to provide me >with the security? I don't, I use SSL or transport layer security. >One could also argue that this makes the application more robust >since it is not dependent on a lower layer for security. there is considerable literature on the differences between SSL and IPsec security features, which suggests that there are good reasons for choosing each in different contexts. however, the argument that port level security is better provided by SSL is NOT part of that literature. >If IP is the network layer, and IPSEC is a network layer >protocol, why does a network layer security protocol >care about transport layer traffic selectors? IPsec is a security protocol that operates at the Ip layer. It is NOT just an encryption, authentication, integrity protocol. Access control is an important feature of IPsec, as the 2401bis intro notes. IPsec offers access controls consistent with what a stateless, packet filtering firewall offers. this includes port level filtering. the lack of stateful inspection is less of a concern here, because SAs are authenticated, and thus we know who/what is at the other end. >Is the inclusion >of transport layer traffic selectors (TCP/UDP ports) >an optimization in the >original design? Or >is it now an redundant feature with the pervasive >deployment of SSL/TLS? badly worded question. why not just ask if Ipsec has stooped beating its virtual wife? >Would application developers actually >ever trust the network layer to provide them with the security that >they need? How can an application trust the network administrator >(especially in a shared system) >to correctly configure security on a per transport layer demux >port basis especially when money or financial information >is involved? That is, unless everyone is sharing the same security >policy in which case the port-based selectors are not needed. a narrowly focused question, since IPsec is implemented in multiple contexts, not all of which are available to application developers, even when IPsec is in a host, e.g., consider the NIC implementations of IPsec which are designed to be managed centrally, not by app developers. >If all one wants to do is secure a particular application running >over a specific but not pre-determined port (dynamic), then is the >transport layer security the easier way to go? > >Only time and deployment >experience will tell the rest of the story in terms of what >features get used or are left to die. However, if the recent >uptake in SSL-VPNs (search google/light reading for market predictions) >is an indication, we have interesting times ahead. This WG would be ill-advised to make standards design decisions based on what trade rags say. Steve From owner-ipsec@lists.tislabs.com Mon Feb 23 08:25:15 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1NGPE3u001434; Mon, 23 Feb 2004 08:25:14 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08585 Mon, 23 Feb 2004 10:49:38 -0500 (EST) From: Darren Reed Message-Id: <200402231601.i1NG1KYM016151@caligula.anu.edu.au> Subject: Re: Fwd: Certicom IP Rights To: sfluhrer@cisco.com (Scott Fluhrer) Date: Tue, 24 Feb 2004 03:01:20 +1100 (Australia/ACT) Cc: ipsec@lists.tislabs.com In-Reply-To: <000801c3f9dd$38fd7850$52f4200a@sfluhrerhpc> from "Scott Fluhrer" at Feb 22, 2004 11:18:22 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In some mail from Scott Fluhrer, sie said: [...] > It is possible that WO 00/01109 or some of the uncited patents or non-US > patent applications may be applicable. However, in every case I did > examine, I could not see how any of the IETF documents in question, or > an implementation based on such documents, would necessarily be in > violation. I would encourage other people to scan through these > patents, and see if my assessments are accurate. And again, for the > third time, I am not a lawyer, and please do not use my opinions as > legal advise. You were very careful in everything you said to say that the IETF documents do not _mandate_ any of the said approaches in the patents so I'll ask what I think is an obvious question: In implementing one of the said IETF documents, is it possible or likely that someone might chose (perhaps poorly) to do so using one of the patented methods ? And if so, are there alternatives that would bring compliance and avoid patent grief ? Darren From owner-ipsec@lists.tislabs.com Mon Feb 23 09:30:27 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1NHUQti004865; Mon, 23 Feb 2004 09:30:26 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA17439 Mon, 23 Feb 2004 11:46:56 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16438.33790.277777.604567@fireball.acr.fi> References: <20040130232243.GA6423@thunk.org> <16434.24291.254422.111128@fireball.acr.fi> <16438.75.875878.718798@fireball.acr.fi> <16438.33790.277777.604567@fireball.acr.fi> Date: Mon, 23 Feb 2004 11:22:53 -0500 To: Tero Kivinen From: Stephen Kent Subject: Re: Issue #83: Generation of ICMP responses for inbound packet requiring IPSEC protection 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 0:02 +0200 2/21/04, Tero Kivinen wrote: >Stephen Kent writes: >> >This kind of setup can be used for normal web-traffic etc, where you >> >actually do not normally need to create IPsec SAs, but if you happen >> >to have SA up, you can use it (it does not cause any harm either). >> >> it makes behavior non-deterministic, which is generally a bad thing >> from a security perspective. > >In those cases the encryption is not for the real security, but simply >encryption just because it is fun, and it will cause more traffic in >the net to be encrypted, making large scale traffic analysis harder. this is a commonly cited notion, but there are analysis techniques that show that the notion is not valid in most cases :-) > > >Might be true, but there are implemenations which support this kind of >> >operations. >> >> Then they are non-complaint. > >Does the RFC2401 really say, that you cannot expand the SPD at all, >and all implementations MUST only support what is defined there. I >thought that it specified mostly the minimum requirements not exact >requirements what can and cannot be implemented (i.e. I would not call >those extended versions non-complaint, I would call them IPsec + >extensions versions :-). we agree that 2401 specifies a minimum access control capability, but we may disagree about whether a non-deterministic SPD function represents an enhancement or a regression :-) Steve From owner-ipsec@lists.tislabs.com Mon Feb 23 10:03:15 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1NI3Ed0006445; Mon, 23 Feb 2004 10:03:15 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22656 Mon, 23 Feb 2004 12:25:14 -0500 (EST) Date: Mon, 23 Feb 2004 12:25:14 -0500 (EST) From: owner-ipsec@lists.tislabs.com Message-Id: <200402231725.MAA22656@lists.tislabs.com> (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id LAA18216 Mon, 23 Feb 2004 11:52:53 -0500 (EST) Message-ID: From: Michael Smith To: "'sfluhrer@cisco.com'" Cc: "'ipsec@lists.tislabs.com'" , Michael Smith Subject: Re: Fwd: Certicom IP Rights Date: Mon, 23 Feb 2004 09:04:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FA2E.E173E4D3" 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_01C3FA2E.E173E4D3 Content-Type: text/plain; charset="iso-8859-1" >> I have no idea how to find PCT Application #WO 00/01109, and so I did not examine that. See http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=WO0001109 Mike Smith iReady -----Original Message----- From: Scott Fluhrer [mailto:sfluhrer@cisco.com] Sent: Sunday, February 22, 2004 11:18 PM To: ipsec@lists.tislabs.com Subject: Re: Fwd: Certicom IP Rights I have examined the patents that Certicom has cited in their IP claim, and list what I found below. Now, of course, I am not a lawyer, and I am not giving legal advice. >To: housley@vigilsec.com >From: Ian McKinnon >Date: Fri, 31 Oct 2003 15:14:09 -0500 > > >Dear Mr. Housley: > >We wish to advise the IETF that Certicom believes it has rights under >patents and/or pending applications that relate to RFC 3526 "More Modular >Exponential (MODP) Diffie-Hellman Groups for Internet Key Exchange (IKE)", >RFC 2409 "Internet Key Exchange", Internet Draft >(draft-ietf-ipsec-ikev2-11.txt) "Internet Key Exchange (IKEv2) Protocol" >and other IETF standards using MODP Groups. The applicable patents >include, but are not limited to, US Patents #5,933,504, #6,563,928, >#6,078,667, #6,178,507, #6,195,433, US Patent Application Publications >#2001/0014153, #2002/0090085, and PCT Application #WO 00/01109, and >corresponding foreign applications. Patent claims: 5,933,504: 6,563,928: (6,563,928 is an extended version of 5,933,504 with more claims and so I address both together) Both patents are concerned with the Diffie-Hellman protocol and detecting whether the public values received from the peer is within a weak subgroup, that is, a value that would generate a relatively small number of values for the shared secret. The reasoning for this is that an attacker may be able to introduce weak values for both exchanged public values, and thus trick both sides into computing an easily guessable shared secret. Note that both IKEv1 and IKEv2 defend against this attack in manners that differ from the method listed in the patent. That might sound reasonable, however, the MODP modulii that IKE uses are all of the form (2*q+1) for q prime, and the generator used is a quadratic residue to those modulii. What this implies (in English) is that these groups have only one small subgroup, namely the trivial subgroup consisting of the single element {1}. This means that the patented operation is, in this case, comparing the public value you received from the peer (KE payload) against the value 1, and rejecting it if so. This brings up two obvious points: - Is such an operation patentable? Rejecting illegal values has been a part of programming for quite a while. Of course, I am not a lawyer. (Also note that, if you are rejecting illegal values, you would also want to reject the values 0, p-1, p, p+1, which do not appear to be a part of the Certicom patents). - None of the cited IETF documents (RFC3526, RFC2409, the draft IKEv2 document) mandates (or even mentions) such an operation. It is thus difficult to say why these documents, or an implementation based on these documents, are in violation of either patent. 6,078,667: This patents a method of generating "unique and unpredictable values" for use as a private key within a public key encryption system. However, the cited IETF documents do not mandate a way for generating the Diffie-Hellman exponents (and I cannot see any other way of applying this patent). As such, it is thus difficult to say why these documents are in violation of this patent. 6,178,507: This patents a method of authentication involving elliptic curves. As the claims are limited systems involving ECC, this is inapplicable to the MODP-based protocols in question. 6,195,433: This patents the idea of using statistical tests (or 'predetermined set of criteria') when generating private keys. As the cited IETF documents do not mandate any such tests, it is thus difficult to say why these documents are in violation of this patent. US Patent Application Publications 2001/0014153: This patents the idea of checking a generated public/private key pair for validity. As the cited IETF documents do not mandate any such checks, it is difficult to say why these documents are in violation. 2002/0090085: This patents a method of generating a random number between 0 and q (the order of a group). The cited IETF documents do not mandate any such method for generating the Diffie-Hellman exponents (and for MODP groups, you generally don't generate exponents as large as the group order), and thus it is difficult to say why these documents are in violation. I have no idea how to find PCT Application #WO 00/01109, and so I did not examine that. It is possible that WO 00/01109 or some of the uncited patents or non-US patent applications may be applicable. However, in every case I did examine, I could not see how any of the IETF documents in question, or an implementation based on such documents, would necessarily be in violation. I would encourage other people to scan through these patents, and see if my assessments are accurate. And again, for the third time, I am not a lawyer, and please do not use my opinions as legal advise. -- scott ------_=_NextPart_001_01C3FA2E.E173E4D3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Fwd: Certicom IP Rights

>> I have no idea how to find PCT Application = #WO 00/01109, and so I did
not examine that.

See http://v3.espacenet.com/textdoc?DB=3DEPODOC&IDX=3DWO00= 01109

Mike Smith
iReady

-----Original Message-----
From: Scott Fluhrer [mailto:sfluhrer@cisco.com]=
Sent: Sunday, February 22, 2004 11:18 PM
To: ipsec@lists.tislabs.com
Subject: Re: Fwd: Certicom IP Rights


I have examined the patents that Certicom has cited = in their IP claim,
and list what I found below.  Now, of course, I = am not a lawyer, and I
am not giving legal advice.

>To: housley@vigilsec.com
>From: Ian McKinnon = <IMcKinnon@certicom.com>
>Date: Fri, 31 Oct 2003 15:14:09 -0500
>
>
>Dear Mr. Housley:
>
>We wish to advise the IETF that Certicom = believes it has rights under
>patents and/or pending applications that relate = to RFC 3526 "More
Modular
>Exponential (MODP) Diffie-Hellman Groups for = Internet Key Exchange
(IKE)",
>RFC 2409 "Internet Key = Exchange",  Internet Draft
>(draft-ietf-ipsec-ikev2-11.txt) "Internet = Key Exchange (IKEv2)
Protocol"
>and other IETF standards using MODP = Groups.  The applicable patents
>include, but are not limited to, US Patents = #5,933,504, #6,563,928,
>#6,078,667, #6,178,507, #6,195,433, US Patent = Application Publications
>#2001/0014153, #2002/0090085, and PCT = Application #WO 00/01109, and
>corresponding foreign applications.

Patent claims:
5,933,504:
6,563,928:
   (6,563,928 is an extended version of = 5,933,504 with more claims and
so I address both together)
   Both patents are concerned with the = Diffie-Hellman protocol and
detecting whether the public values received from = the peer is within a
weak subgroup, that is, a value that would generate = a relatively small
number of values for the shared secret.  The = reasoning for this is that
an attacker may be able to introduce weak values for = both exchanged
public values, and thus trick both sides into = computing an easily
guessable shared secret.  Note that both IKEv1 = and IKEv2 defend against
this attack in manners that differ from the method = listed in the patent.
   That might sound reasonable, however, = the MODP modulii that IKE uses
are all of the form (2*q+1) for q prime, and the = generator used is a
quadratic residue to those modulii.  What this = implies (in English) is
that these groups have only one small subgroup, = namely the trivial
subgroup consisting of the single element {1}.  = This means that the
patented operation is, in this case, comparing the = public value you
received from the peer (KE payload) against the = value 1, and rejecting
it if so.
   This brings up two obvious = points:
- Is such an operation patentable?  Rejecting = illegal values has been a
part of programming for quite a while.  Of = course, I am not a lawyer.
(Also note that, if you are rejecting illegal = values, you would also
want to reject the values 0, p-1, p, p+1, which do = not appear to be a
part of the Certicom patents).
- None of the cited IETF documents (RFC3526, = RFC2409, the draft IKEv2
document) mandates (or even mentions) such an = operation.  It is thus
difficult to say why these documents, or an = implementation based on
these documents, are in violation of either = patent.

6,078,667:
   This patents a method of generating = "unique and unpredictable values"
for use as a private key within a public key = encryption system.
However, the cited IETF documents do not mandate a = way for generating
the Diffie-Hellman exponents (and I cannot see any = other way of applying
this patent).  As such, it is thus difficult to = say why these documents
are in violation of this patent.

6,178,507:
   This patents a method of authentication = involving elliptic curves.
As the claims are limited systems involving ECC, = this is inapplicable to
the MODP-based protocols in question.

6,195,433:
   This patents the idea of using = statistical tests (or 'predetermined
set of criteria') when generating private = keys.  As the cited IETF
documents do not mandate any such tests, it is thus = difficult to say why
these documents are in violation of this = patent.

US Patent Application Publications
2001/0014153:
   This patents the idea of checking a = generated public/private key pair
for validity.  As the cited IETF documents do = not mandate any such
checks, it is difficult to say why these documents = are in violation.

2002/0090085:
   This patents a method of generating a = random number between 0 and q
(the order of a group).  The cited IETF = documents do not mandate any
such method for generating the Diffie-Hellman = exponents (and for MODP
groups, you generally don't generate exponents as = large as the group
order), and thus it is difficult to say why these = documents are in
violation.


I have no idea how to find PCT Application #WO = 00/01109, and so I did
not examine that.

It is possible that WO 00/01109 or some of the = uncited patents or non-US
patent applications may be applicable.  = However, in every case I did
examine, I could not see how any of the IETF = documents in question, or
an implementation based on such documents, would = necessarily be in
violation.  I would encourage other people to = scan through these
patents, and see if my assessments are = accurate.  And again, for the
third time, I am not a lawyer, and please do not use = my opinions as
legal advise.


--
scott

------_=_NextPart_001_01C3FA2E.E173E4D3-- From owner-ipsec@lists.tislabs.com Mon Feb 23 11:49:42 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1NJnffG014496; Mon, 23 Feb 2004 11:49:42 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06225 Mon, 23 Feb 2004 14:10:29 -0500 (EST) Message-ID: From: Michael Smith To: "'sfluhrer@cisco.com'" Cc: "'ipsec@lists.tislabs.com'" , Michael Smith Subject: Re: Fwd: Certicom IP Rights Date: Mon, 23 Feb 2004 09:04:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FA2E.E173E4D3" 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_01C3FA2E.E173E4D3 Content-Type: text/plain; charset="iso-8859-1" >> I have no idea how to find PCT Application #WO 00/01109, and so I did not examine that. See http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=WO0001109 Mike Smith iReady -----Original Message----- From: Scott Fluhrer [mailto:sfluhrer@cisco.com] Sent: Sunday, February 22, 2004 11:18 PM To: ipsec@lists.tislabs.com Subject: Re: Fwd: Certicom IP Rights I have examined the patents that Certicom has cited in their IP claim, and list what I found below. Now, of course, I am not a lawyer, and I am not giving legal advice. >To: housley@vigilsec.com >From: Ian McKinnon >Date: Fri, 31 Oct 2003 15:14:09 -0500 > > >Dear Mr. Housley: > >We wish to advise the IETF that Certicom believes it has rights under >patents and/or pending applications that relate to RFC 3526 "More Modular >Exponential (MODP) Diffie-Hellman Groups for Internet Key Exchange (IKE)", >RFC 2409 "Internet Key Exchange", Internet Draft >(draft-ietf-ipsec-ikev2-11.txt) "Internet Key Exchange (IKEv2) Protocol" >and other IETF standards using MODP Groups. The applicable patents >include, but are not limited to, US Patents #5,933,504, #6,563,928, >#6,078,667, #6,178,507, #6,195,433, US Patent Application Publications >#2001/0014153, #2002/0090085, and PCT Application #WO 00/01109, and >corresponding foreign applications. Patent claims: 5,933,504: 6,563,928: (6,563,928 is an extended version of 5,933,504 with more claims and so I address both together) Both patents are concerned with the Diffie-Hellman protocol and detecting whether the public values received from the peer is within a weak subgroup, that is, a value that would generate a relatively small number of values for the shared secret. The reasoning for this is that an attacker may be able to introduce weak values for both exchanged public values, and thus trick both sides into computing an easily guessable shared secret. Note that both IKEv1 and IKEv2 defend against this attack in manners that differ from the method listed in the patent. That might sound reasonable, however, the MODP modulii that IKE uses are all of the form (2*q+1) for q prime, and the generator used is a quadratic residue to those modulii. What this implies (in English) is that these groups have only one small subgroup, namely the trivial subgroup consisting of the single element {1}. This means that the patented operation is, in this case, comparing the public value you received from the peer (KE payload) against the value 1, and rejecting it if so. This brings up two obvious points: - Is such an operation patentable? Rejecting illegal values has been a part of programming for quite a while. Of course, I am not a lawyer. (Also note that, if you are rejecting illegal values, you would also want to reject the values 0, p-1, p, p+1, which do not appear to be a part of the Certicom patents). - None of the cited IETF documents (RFC3526, RFC2409, the draft IKEv2 document) mandates (or even mentions) such an operation. It is thus difficult to say why these documents, or an implementation based on these documents, are in violation of either patent. 6,078,667: This patents a method of generating "unique and unpredictable values" for use as a private key within a public key encryption system. However, the cited IETF documents do not mandate a way for generating the Diffie-Hellman exponents (and I cannot see any other way of applying this patent). As such, it is thus difficult to say why these documents are in violation of this patent. 6,178,507: This patents a method of authentication involving elliptic curves. As the claims are limited systems involving ECC, this is inapplicable to the MODP-based protocols in question. 6,195,433: This patents the idea of using statistical tests (or 'predetermined set of criteria') when generating private keys. As the cited IETF documents do not mandate any such tests, it is thus difficult to say why these documents are in violation of this patent. US Patent Application Publications 2001/0014153: This patents the idea of checking a generated public/private key pair for validity. As the cited IETF documents do not mandate any such checks, it is difficult to say why these documents are in violation. 2002/0090085: This patents a method of generating a random number between 0 and q (the order of a group). The cited IETF documents do not mandate any such method for generating the Diffie-Hellman exponents (and for MODP groups, you generally don't generate exponents as large as the group order), and thus it is difficult to say why these documents are in violation. I have no idea how to find PCT Application #WO 00/01109, and so I did not examine that. It is possible that WO 00/01109 or some of the uncited patents or non-US patent applications may be applicable. However, in every case I did examine, I could not see how any of the IETF documents in question, or an implementation based on such documents, would necessarily be in violation. I would encourage other people to scan through these patents, and see if my assessments are accurate. And again, for the third time, I am not a lawyer, and please do not use my opinions as legal advise. -- scott ------_=_NextPart_001_01C3FA2E.E173E4D3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Fwd: Certicom IP Rights

>> I have no idea how to find PCT Application = #WO 00/01109, and so I did
not examine that.

See http://v3.espacenet.com/textdoc?DB=3DEPODOC&IDX=3DWO00= 01109

Mike Smith
iReady

-----Original Message-----
From: Scott Fluhrer [mailto:sfluhrer@cisco.com]=
Sent: Sunday, February 22, 2004 11:18 PM
To: ipsec@lists.tislabs.com
Subject: Re: Fwd: Certicom IP Rights


I have examined the patents that Certicom has cited = in their IP claim,
and list what I found below.  Now, of course, I = am not a lawyer, and I
am not giving legal advice.

>To: housley@vigilsec.com
>From: Ian McKinnon = <IMcKinnon@certicom.com>
>Date: Fri, 31 Oct 2003 15:14:09 -0500
>
>
>Dear Mr. Housley:
>
>We wish to advise the IETF that Certicom = believes it has rights under
>patents and/or pending applications that relate = to RFC 3526 "More
Modular
>Exponential (MODP) Diffie-Hellman Groups for = Internet Key Exchange
(IKE)",
>RFC 2409 "Internet Key = Exchange",  Internet Draft
>(draft-ietf-ipsec-ikev2-11.txt) "Internet = Key Exchange (IKEv2)
Protocol"
>and other IETF standards using MODP = Groups.  The applicable patents
>include, but are not limited to, US Patents = #5,933,504, #6,563,928,
>#6,078,667, #6,178,507, #6,195,433, US Patent = Application Publications
>#2001/0014153, #2002/0090085, and PCT = Application #WO 00/01109, and
>corresponding foreign applications.

Patent claims:
5,933,504:
6,563,928:
   (6,563,928 is an extended version of = 5,933,504 with more claims and
so I address both together)
   Both patents are concerned with the = Diffie-Hellman protocol and
detecting whether the public values received from = the peer is within a
weak subgroup, that is, a value that would generate = a relatively small
number of values for the shared secret.  The = reasoning for this is that
an attacker may be able to introduce weak values for = both exchanged
public values, and thus trick both sides into = computing an easily
guessable shared secret.  Note that both IKEv1 = and IKEv2 defend against
this attack in manners that differ from the method = listed in the patent.
   That might sound reasonable, however, = the MODP modulii that IKE uses
are all of the form (2*q+1) for q prime, and the = generator used is a
quadratic residue to those modulii.  What this = implies (in English) is
that these groups have only one small subgroup, = namely the trivial
subgroup consisting of the single element {1}.  = This means that the
patented operation is, in this case, comparing the = public value you
received from the peer (KE payload) against the = value 1, and rejecting
it if so.
   This brings up two obvious = points:
- Is such an operation patentable?  Rejecting = illegal values has been a
part of programming for quite a while.  Of = course, I am not a lawyer.
(Also note that, if you are rejecting illegal = values, you would also
want to reject the values 0, p-1, p, p+1, which do = not appear to be a
part of the Certicom patents).
- None of the cited IETF documents (RFC3526, = RFC2409, the draft IKEv2
document) mandates (or even mentions) such an = operation.  It is thus
difficult to say why these documents, or an = implementation based on
these documents, are in violation of either = patent.

6,078,667:
   This patents a method of generating = "unique and unpredictable values"
for use as a private key within a public key = encryption system.
However, the cited IETF documents do not mandate a = way for generating
the Diffie-Hellman exponents (and I cannot see any = other way of applying
this patent).  As such, it is thus difficult to = say why these documents
are in violation of this patent.

6,178,507:
   This patents a method of authentication = involving elliptic curves.
As the claims are limited systems involving ECC, = this is inapplicable to
the MODP-based protocols in question.

6,195,433:
   This patents the idea of using = statistical tests (or 'predetermined
set of criteria') when generating private = keys.  As the cited IETF
documents do not mandate any such tests, it is thus = difficult to say why
these documents are in violation of this = patent.

US Patent Application Publications
2001/0014153:
   This patents the idea of checking a = generated public/private key pair
for validity.  As the cited IETF documents do = not mandate any such
checks, it is difficult to say why these documents = are in violation.

2002/0090085:
   This patents a method of generating a = random number between 0 and q
(the order of a group).  The cited IETF = documents do not mandate any
such method for generating the Diffie-Hellman = exponents (and for MODP
groups, you generally don't generate exponents as = large as the group
order), and thus it is difficult to say why these = documents are in
violation.


I have no idea how to find PCT Application #WO = 00/01109, and so I did
not examine that.

It is possible that WO 00/01109 or some of the = uncited patents or non-US
patent applications may be applicable.  = However, in every case I did
examine, I could not see how any of the IETF = documents in question, or
an implementation based on such documents, would = necessarily be in
violation.  I would encourage other people to = scan through these
patents, and see if my assessments are = accurate.  And again, for the
third time, I am not a lawyer, and please do not use = my opinions as
legal advise.


--
scott

------_=_NextPart_001_01C3FA2E.E173E4D3-- From owner-ipsec@lists.tislabs.com Mon Feb 23 15:16:10 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1NNG9BP027568; Mon, 23 Feb 2004 15:16:09 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00816 Mon, 23 Feb 2004 17:24:46 -0500 (EST) Message-Id: <200402232232.i1NMW1vf015925@rs9.luxsci.com> From: "William Dixon" To: Subject: AD requests WG review of final revisions to draft-ietf-ipsec-nat-reqts-06.txt <= 48hrs please Date: Mon, 23 Feb 2004 14:30:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Lux-Comment: LuxSci remailer message ID code - 1077575521-6983909.43314825 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The NAT-T requirements draft is in final RFC editor review. Having a fresh look at this, Bernard and I have proposed a number of changes to the latest revision. While most are clarifications, the ADs wanted to make sure the WG got a chance to review these to catch any immediate objections. The authors believe that none of the proposed changes affect the current solutions. But we are asking a quick 48hour review period for these changes. This is the current document to which the change requests below apply: ftp://ftp.rfc-editor.org/in-notes/authors/rfc3715.txt Note: this link is to a living document. It will go away when the RFC issues, and will change if the RFC editor makes further changes during the review process. On Page 4, change: "IPsec/GRE" to "IPsec protected GRE" Change: " c) Incompatibility between IKE address identifiers and NAT. Where IP addresses are used as identifiers in Internet Key Exchange Protocol (IKE) MM [RFC2409] or QM, modification of the IP source or destination addresses by NATs or reverse NATs will result in a mismatch between the identifiers and the addresses in the IP header. As described in [RFC2409], IKE implementations are required to discard such packets. In order to avoid use of IP addresses as IKE MM and QM identifiers, userIDs and FQDNs can be used instead. Where user authentication is desired, an ID type of ID_USER_FQDN can be used, as described in [RFC2407]. Where machine authentication is desired, an ID type of ID_FQDN can be used. In either case, it is necessary to verify that the proposed identity matches that enclosed in the certificate. However, while use of USER_FQDN or FQDN identity types is possible within IKE, there are usage scenarios (e.g., Security Policy Database (SPD) entries describing subnets) that cannot be accommodated this way." to: " c) Incompatibility between IKE address identifiers and NAT. Where IP addresses are used as identifiers in Internet Key Exchange Protocol (IKE) Phase 1 [RFC2409] or Phase 2, modification of the IP source or destination addresses by NATs or reverse NATs will result in a mismatch between the identifiers and the addresses in the IP header. As described in [RFC2409], IKE implementations are required to discard such packets. In order to avoid use of IP addresses as IKE Phase 1 and Phase 2 identifiers, userIDs and FQDNs can be used instead. Where user authentication is desired, an ID type of ID_USER_FQDN can be used, as described in [RFC2407]. Where machine authentication is desired, an ID type of ID_FQDN can be used. In either case, it is necessary to verify that the proposed identifier matches that enclosed in the certificate if certificates are exchanged in Phase 1. While use of USER_FQDN or FQDN identity types is possible within IKE, there are usage scenarios (e.g., Security Policy Database (SPD) entries describing subnets) that cannot be accommodated this way. Since the source address in the Phase 2 identifier is often used to form a full 5-tuple inbound SA selector, the destination address, protocol, source port and destination port can be used in the selector so as not to weaken inbound SA processing." Change: " d) Incompatibility between fixed IKE destination ports and NAPT." To: " d) Incompatibility between fixed IKE source ports and NAPT." Change: " e) Incompatibilities between overlapping SPD entries and NAT. Where hosts behind a NAT negotiate overlapping SPD entries with the same destination in IKE QM, packets may be sent down the wrong IPsec SA. This occurs because to the sender, the IPsec SAs appear to be equivalent, since they exist between the same endpoints and can be used to pass the same traffic." To: " e) Incompatibilities between overlapping SPD entries and NAT. Where initiating hosts behind a NAT use their source IP addresses in Phase 2 identifiers, they can negotiate overlapping SPD entries with the same responder IP address. The responder could then send packets down the wrong IPsec SA. This occurs because to the responder, the IPsec SAs appear to be equivalent, since they exist between the same endpoints and can be used to pass the same traffic." Change: " Note that this is not an incompatibility with IPsec per se, but rather with the way it is typically implemented. With both AH and ESP, the receiving host specifies the SPI to use for a given SA. At present, the combination of Destination IP, SPI, and Security Protocol (AH, ESP) uniquely identifies a Security Association. This means that the receiving host can select SPIs, such that it has one Security Association (SA) with (SPI=470, Dest IP=10.2.3.4), and a different Security Association with (SPI=470, Dest IP=10.3.4.5)." To: " Note that this is not an incompatibility with IPsec per se, but rather with the way it is typically implemented. With both AH and ESP, the receiving host specifies the SPI to use for a given SA, a choice which is significant only to the receiver. At present, the combination of Destination IP, SPI, and Security Protocol (AH, ESP) uniquely identifies a Security Association. This means that the receiving host can select SPIs, such that it has one Security Association (SA) with (SPI=470, Dest IP=10.2.3.4), and a different Security Association with (SPI=470, Dest IP=10.3.4.5). The receiving NA(P)T will not be able to determine which internal host an inbound IPsec packet should be forwarded to." Change: It is also possible for the receiving host to allocate a unique SPI to each unicast Security Association. In this case, the Destination IP Address need only be checked to see if it is "any valid unicast IP for this host", not checked to see if it is the specific Destination IP address used by the sending host. This approach is completely backwards compatible, and only requires the particular receiving host to make a change to its SPI allocation and IPsec_esp_input() code." To: " It is also possible for the receiving host to allocate a unique SPI to each unicast Security Association. In this case, the Destination IP Address need only be checked to see if it is "any valid unicast IP for this host", not checked to see if it is the specific Destination IP address used by the sending host. Using this technique, the NA(P)T can be assured of a low but non-zero chance of forwarding packets to the wrong internal host, even when two or more hosts establish SAs with the same external host. This approach is completely backwards compatible, and only requires the particular receiving host to make a change to its SPI allocation and IPsec_esp_input() code. However, NA(P)T devices cannot detect or depend upon this behavior." Insert after h) and renumber subsequent paragraphs: " i) Inbound SA selector verification. Assuming IKE negotiates phase 2 selectors, inbound SA processing will drop the decapsulated packet, since [RFC2401] requires a packet's source address match the SA selector value, which NA(P)T processing of an ESP packet would change." Change: " i) Inability to handle non-UDP/TCP traffic. Some NAPTs discard non- UDP/TCP traffic. Such NAPTs are unable to pass SCTP, ESP (protocol 50), or AH (protocol 51) traffic." To: " j) Inability to handle non-UDP/TCP traffic. Some NA(P)Ts discard non- UDP/TCP traffic or perform address-only translation when only one host is behind the NAT. Such NAPTs are unable to enable SCTP, ESP (protocol 50), or AH (protocol 51) traffic." In Section 3, change: " The goal of an IPsec-NAT compatibility solution is to expand the range of usable IPsec functionality beyond that available in the NAT-compatible IPsec tunnel mode solution described above." To: " The goal of an IPsec-NAT compatibility solution is to expand the range of usable IPsec functionality beyond that available in the NAT-compatible IPsec tunnel mode solution described in Section 2.3." Change: " In a gateway-gateway scenario, a privately addressed network (DMZ) may be inserted between the corporate network and the Internet. In this design, IPsec security gateways connecting portions of the corporate network will have private addresses on their external interfaces. A NA(P)T connects the DMZ network to the Internet. A NAT-IPsec solution MUST enable secure host-host communication via IPsec, as well as host-gateway communications. A host on a private network MUST be able to bring up IPsec-protected TCP connections or UDP sessions to another host with one or more NA(P)Ts between them. For example, NA(P)Ts may be deployed within branch offices connecting to the corporate network, with an additional NA(P)T connecting the corporate network to the Internet. This may require special processing of TCP and UDP traffic on the host." To: "Gateway-to-Gateway Scenario In a gateway-gateway scenario, a privately addressed network (DMZ) may be inserted between the corporate network and the Internet. In this design, IPsec security gateways connecting portions of the corporate network may be resident in the DMZ and have private addresses on their external (DMZ) interfaces. A NA(P)T connects the DMZ network to the Internet. End-to-End Scenario A NAT-IPsec solution MUST enable secure host-host TCP/IP communication via IPsec, as well as host-gateway communications. A host on a private network MUST be able to bring up one or multiple IPsec-protected TCP connections or UDP sessions to another host with one or more NA(P)Ts between them. For example, NA(P)Ts may be deployed within branch offices connecting to the corporate network, with an additional NA(P)T connecting the corporate network to the Internet. Likewise, NA(P)Ts may be deployed within a corporate network LAN or WAN to connect wireless or remote location clients to the corporate network. This may require special processing of TCP and UDP traffic on the host." Change: " At a minimum, an IPsec-NAT compatibility solution MUST support traversal of the IPsec modes required for support within [RFC2401]. For example, an IPsec gateway MUST support ESP tunnel mode NA(P)T traversal, and an IPsec host MUST support IPsec transport mode NA(P)T traversal. The purpose of AH is to protect immutable fields within the IP header (including addresses), and NA(P)T translates addresses, invalidating the AH integrity check. As a result, NA(P)T and AH are fundamentally incompatible and there is no requirement that an IPsec-NAT compatibility solution support AH transport or tunnel mode." To: " At a minimum, an IPsec-NAT compatibility solution MUST support traversal of the IKE and IPsec modes required for support within [RFC2409] and [RFC2401]. For example, an IPsec gateway MUST support ESP tunnel mode NA(P)T traversal, and an IPsec host MUST support IPsec transport mode NA(P)T traversal. The purpose of AH is to protect immutable fields within the IP header (including addresses), and NA(P)T translates addresses, invalidating the AH integrity check. As a result, NA(P)T and AH are fundamentally incompatible and there is no requirement that an IPsec-NAT compatibility solution support AH transport or tunnel mode." In Section 4.2, change: " RSIP, described in [RSIP] and [RSIPFrame], includes mechanisms for IPsec traversal, as described in [RSIPsec]. By enabling host-gateway communication, RSIP addresses issues of IPsec SPI de-multiplexing, as well as SPD overlap. It is thus suitable for use in enterprises, as well as home networking scenarios. By enabling hosts behind a NAT to share the external IP address of the gateway, this approach is compatible with protocols including embedded IP addresses." To: " RSIP, described in [RSIP] and [RSIPFrame], includes mechanisms for IPsec traversal, as described in [RSIPsec]. By enabling host-NA(P)T communication, RSIP addresses issues of IPsec SPI de-multiplexing, as well as SPD overlap. It is thus suitable for use in enterprises, as well as home networking scenarios. By enabling hosts behind a NAT to share the external IP address of the NA(P)T (the RSIP gateway), this approach is compatible with protocols including embedded IP addresses." In Section 5, change: " In addition, since ESP with any transform does not protect against source address spoofing, some sort of source IP address sanity checking needs to be performed. The importance of the anti-spoofing check is not widely understood. There is normally an anti-spoofing check on the Source IP Address as part of IPsec_{esp,ah}_input(). This ensures that the packet originates from the same address as that claimed within the original IKE MM and QM security associations. When a receiving host is behind a NAT, this check might not strictly be meaningful for unicast sessions, whereas in the Global Internet this check is important for tunnel-mode unicast sessions to prevent a spoofing attack described in [AuthSource]." To: " In addition, since ESP with any transform does not protect against source address spoofing, some sort of source IP address sanity checking needs to be performed. The importance of the anti-spoofing check is not widely understood. There is normally an anti-spoofing check on the Source IP Address as part of IPsec_{esp,ah}_input(). This ensures that the packet originates from the same address as that claimed within the original IKE Phase 1 and Phase 2 security associations. When a receiving host is behind a NAT, this check might not strictly be meaningful for unicast sessions, whereas in the Global Internet this check is important for tunnel-mode unicast sessions to prevent a spoofing attack described in [AuthSource], which can occur when access controls on the receiver depend upon the source IP address of verified ESP packets after decapsulation. IPsec-NAT compatibility schemes should provide anti-spoofing protection if it uses source addresses for access controls." End of changes From owner-ipsec@lists.tislabs.com Mon Feb 23 16:47:22 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1O0lLtV033737; Mon, 23 Feb 2004 16:47:22 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA16444 Mon, 23 Feb 2004 19:07:37 -0500 (EST) Date: Mon, 23 Feb 2004 19:18:47 -0500 (EST) From: canetti To: Paul Hoffman / VPNC cc: cfrg@ietf.org, ipsec@lists.tislabs.com, Charlie Kaufman , Hugo Krawczyk , "The Purple Streak, Hilarie Orman" Subject: Re: [Cfrg] Re: Changing the key deriveration In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry for the delayed reaction. Let me try to be concise: 1. I strongly support the move to change the spec. Using the same key to two different algorithms is a big "no no" that, on top of other drawbacks, does not allow mathematical proofs of security to go through. (Not being amenable to analysis is a considerable *practical* weakness, even if do not see how to turn the weakness into an explicit attack...) 2. Both the solution suggested by Hugo (to derive two more keys from SEEDKEY, to be used for the PRF by the sender/responder, respectively), and the solution suggested by Hilarie (to use SK_d, the key meant for deriving the IPSEC keying material as the key to the PRF) are in principle sound. However, Hugo's solution seems somewhat more robust: It seems preferable to keep the ``virginity'' of the derivation key, SK_d, and refrain from using it inside the protocol. This feeling is compounded by the fact that in the password-based authentication mode the PRF is applied to messages of a generic password-based protocol, so the door may be open to "oracle attacks" that use the parties to obtain values of PRF(SK_d,...) on desired values. So, in conclusion, if we're already changing the spec for better analyzability/provability, then I think we should play it safe and derive two extra keys from SEEDKEY, rather than use SK_d. (The difference in performance and complexity between the two options seems minimal.) Ran On Fri, 20 Feb 2004, Paul Hoffman / VPNC wrote: > At 9:57 PM +0200 2/17/04, Hugo Krawczyk wrote: > >Anyway, replacing SK_ai and SK_ar in the above text (as well as in 2.15, > >first paragraph) with SK_d does resolve the problem of using two > >algorithms (prf and integrity) with the same key, and it is much better > >than what is done now. > > There have been no more comments on this, and the ADs are still > waiting for a final draft of this document so they can move all three > IKEv2 documents to IETF last call. > > Charlie: are you OK with this solution? If so, can you get the new > draft out soon, such as when the Internet Drafts window opens? > > --Paul Hoffman, Director > --VPN Consortium > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg > From qjyrtvx@yahoo.com Mon Feb 23 22:01:00 2004 Received: from bzq-218-26-220.cablep.bezeqint.net (bzq-218-26-220.cablep.bezeqint.net [81.218.26.220]) by above.proper.com (8.12.11/8.12.8) with SMTP id i1O60cYZ050999; Mon, 23 Feb 2004 22:00:54 -0800 (PST) (envelope-from qjyrtvx@yahoo.com) Date: Mon, 23 Feb 2004 22:00:38 -0800 (PST) From: qjyrtvx@yahoo.com Received: from 61.37.94.102 by 81.218.26.220; Wed, 25 Feb 2004 09:59:36 +0400 Message-ID: From: Markku Savela To: ipsec@lists.tislabs.com In-reply-to: (message from Stephen Kent on Fri, 20 Feb 2004 16:15:14 -0500) Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues References: <16434.27900.199285.136682@fireball.acr.fi> <20040218161436.9707F2051E@wolfe.bbn.com> <16435.55623.26827.859229@fireball.acr.fi> <16438.958.625838.937789@fireball.acr.fi> <20040220175458.GC6177@binky.central.sun.com> <20040220200336.GF6177@binky.central.sun.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm still somewhat uneasy with this talk about doing IPSEC on fragments. Say we have a following setup: H <======> SG <-----> S H is my host SG is security gateway S is some server behind the SG Normally my policy on H would express something like Use tunneled IPSEC via SG using ESP (3des, sha1) for all communication with server S. There are cases 1. S replies with fragmented packets 1.1 SG reassembles the packet, applies IPSEC as required, and the result gets fragmented again. 1.2 SG does not reassemble packet, but applies IPSEC directly to the fragments coming from S. 2. S does not fragment packets, and sends them as whole. 2.1 SG applies IPSEC to packet and sends it out without fragmentation (packet is still short enough to fit PMTU) 2.2 SG applies IPSEC, but the resulting packet needs to be fragmented --------- The bothering thing is: The H must now be prepared to handle all combinations EQUALLY with the same dataflow - full packets protected with IPSEC - full IPSEC:ed packets fragmented - fragments with IPSEC applied individually to them because host H cannot know what type of impelementation SG has (whether it reassembles packets from S before doing IPSEC or not). If there are different SA's required for normal and fragment packets, the implementation must in worst case negotiate 4 SA's for each connection, to be prepared for all possible variants (fragment and non-fragment SA for each direction). If the possibility of the fragments needs to noticed in the policy, all policies need to be duplicated: one for non-fragmented, and one for fragmented case. The fragments may not arrive in order. If the policy is dependent on specific ports, the recever must remember each applied SA on each fragment until the full packet is received and the policy can be checked. Some optimization is possible, like if two fragments belonging to the same packet are protected with different SA's, the whole packet is invalid, and receiver can stop processing the fragments of that packet. [Note: if fragments are protected with some different SA, then also the first fragment must use the same]. What if SA's expire between fragments? For example due to bytecount? Long fragmented packets eat up the replay window fast (I still use 32 bits, need to upgrade I guess)? I would just forbid doing IPSEC on fragments, and require SG in above to do reassembly, if S fragmented the packet. The other option is to disallow port selectors with tunnel mode policies [and thus the policy could be checked on each fragment individually]. From owner-ipsec@lists.tislabs.com Tue Feb 24 09:19:58 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1OHJvJR058861; Tue, 24 Feb 2004 09:19:58 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06649 Tue, 24 Feb 2004 11:44:23 -0500 (EST) Date: Tue, 24 Feb 2004 11:50:35 -0500 From: "Theodore Ts'o" To: Paul Hoffman / VPNC Cc: cfrg@ietf.org, ipsec@lists.tislabs.com, Charlie Kaufman , Hugo Krawczyk , "The Purple Streak, Hilarie Orman" Subject: Re: [Cfrg] Re: Changing the key deriveration Message-ID: <20040224165035.GA27403@thunk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i 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 On Fri, Feb 20, 2004 at 06:09:58PM -0800, Paul Hoffman / VPNC wrote: > At 9:57 PM +0200 2/17/04, Hugo Krawczyk wrote: > >Anyway, replacing SK_ai and SK_ar in the above text (as well as in 2.15, > >first paragraph) with SK_d does resolve the problem of using two > >algorithms (prf and integrity) with the same key, and it is much better > >than what is done now. > > There have been no more comments on this, and the ADs are still > waiting for a final draft of this document so they can move all three > IKEv2 documents to IETF last call. David and Ran --- is the CFRG currently working on some kind of official statement that represents the consensus of the group, or should we use the comments made by CFRG members in our deliberations? If the former, could you give us a timeline when the official comments from the CFRG can be expected? If the latter, please accept the thanks of the IPSEC working group to those members who took the time to evaluate Hugo's proposal. - Ted From owner-ipsec@lists.tislabs.com Tue Feb 24 10:53:27 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1OIrQhf064980; Tue, 24 Feb 2004 10:53:27 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA22645 Tue, 24 Feb 2004 13:09:44 -0500 (EST) To: IPsec WG Subject: ICMP messages and per-port selectors X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Tue, 24 Feb 2004 13:21:09 -0500 Message-ID: <29398.1077646869@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Along time ago, I wrote a number of drafts about ICMP messages: PMTU messages: draft-richardson-ipsec-pmtu-discovery.txt http://www.sandelman.ca/SSW/ietf/draft-richardson-ipsec-pmtu-discovery-00.txt more recent ideas (discussed with the re-chartered PMTUD group already): draft-richardson-ipsec-fragment-00.txt http://www.sandelman.ca/SSW/ietf/ipsec/fragment/draft-richardson-ipsec-fragment-00.txt on other ICMP messages: http://www.sandelman.ca/SSW/ietf/ipsec-icmp-handle-v4-01.txt and http://www.sandelman.ca/SSW/ietf/ipsec-icmp-options-01.txt Tero Kivinen asked me to repost references to them. The essential premise of the later documents it that an ICMP message such as a port-unreachable should be examined - the "quoted" IP packet examined, reversed (src<->dst address/ports) and an SA found for it. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQDuWE4qHRg3pndX9AQGMVQP/VRjfaQ8gcD6AK2i6mE4qpGOaKremU9Sv RwPboX3wg+iZUSnHn8OrAX7XzTbfajIeRukcGeylGpDppxJACAJFoJnAWJH/IMCE 5Zw3YrZfcW8FZpGB42LUMzoWRk8AykI3vmkzG3kanihchRLpVtuae4VjvBJBlHU8 jwYLF/yTrco= =kOlX -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Feb 24 11:28:09 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1OJS8iR067019; Tue, 24 Feb 2004 11:28:09 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28490 Tue, 24 Feb 2004 13:51:09 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16443.40928.882061.628063@fireball.acr.fi> Date: Tue, 24 Feb 2004 21:02:56 +0200 From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: Traffic selectors, fragments, ICMP messages and security policy problems X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 22 min X-Total-Time: 27 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There has been some discussion in the IPsec list about how the fragments should be handled when the port selectors are in use. The problem is not only fragments but also ICMP, or actually any packet related to the data going through the SA using port selectors. Lets take example. The security policy of the company is: - Encrypt all SMTP traffic with AES - Use only SHA1-AH for web traffic (encryption of web traffic is forbidden, so goverment / company can see what pages you read :-) If fragments and ICMP messages are put on the separate SA there is no way to enforce that kind of policy. If you create 2 SAs: port 25 => ESP(AES) port 80 => AH(SHA1) all non-first fragments and ICMP messages are dropped, causing problems. If you add any or opaque rule: opaque (or any) => AH(SHA1) you are not folling the company rule that all SMTP traffic must be encrypted as non-first fragments will be sent out in clear text. Also any ICMP message received for the SMTP traffic (packet too big) contains parts of the SMTP traffic and they will also be sent in clear text. If you on the other hand change the AH(SHA1) to ESP(AES) then you will be encrypting web traffic against the policy. There is no way to express that kind of setup with current RFC2401bis document. This means that port selectors cannot really be used before this problem is solved. The fragmentation issue is solved when using transport mode, as there cannot be any fragments there. The ICMP issue is not solved there, as ICMPs might still get wrong protection. The vendors have solved this problem differently. As I explained earlier for example our implementation will do partial-reassembly (i.e. wait for the first-fragment and then forward all fragments to same SA) to handle fragments. This will put all fragments to the same SA, providing them the same protection. For ICMPs you can check the original packet part of the ICMP message and see if it contains enough information so you can select the proper SA for it (i.e. if the port numbers are available use them and select SA based on them). If the ICMP does not have enough data (possible in IPv4) to contain selectors, then it propably will not have any real policy sensitive data anyways, thus sending it using any SA is propably ok. I think we should add text to rfc2401bis saying that If port selectors are used then all data associated with data flow MUST be sent to the SA associated with that stream. This all data includes normal packets, ICMP messages related to the data flow and fragments (first and non-first) of packets. Responder MUST accept all data stream related data from SA associated with that stream." -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Tue Feb 24 11:30:33 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1OJUWPf067151; Tue, 24 Feb 2004 11:30:32 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29376 Tue, 24 Feb 2004 13:58:35 -0500 (EST) Date: Tue, 24 Feb 2004 21:10:29 +0200 Message-Id: <200402241910.i1OJATNM019837@burp.tkv.asdf.org> From: Markku Savela To: ipsec@lists.tislabs.com In-reply-to: <200402241621.i1OGLATm018207@burp.tkv.asdf.org> (message from Markku Savela on Tue, 24 Feb 2004 18:21:10 +0200) Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues References: <16434.27900.199285.136682@fireball.acr.fi> <20040218161436.9707F2051E@wolfe.bbn.com> <16435.55623.26827.859229@fireball.acr.fi> <16438.958.625838.937789@fireball.acr.fi> <20040220175458.GC6177@binky.central.sun.com> <20040220200336.GF6177@binky.central.sun.com> <200402241621.i1OGLATm018207@burp.tkv.asdf.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Answering to my own mail, and bringing the issue back to topic... > The H must now be prepared to handle all combinations EQUALLY with > the same dataflow > > - full packets protected with IPSEC > - full IPSEC:ed packets fragmented > - fragments with IPSEC applied individually to them My suggestion is: IPSEC SA negotiation is based on full packet, and the same SA is applied to both full packet and fragments. This is logical, because fragmentation, whether it happens or not, should not in any way affect the security of the protected connection. Thus, it is no concern of IKEv2, whether IPSEC is applied to fragments or not. It should be left to the IPSEC implementation how they deal with the fragment issue. It is not an issue for key management. For example, if your SG does not support (or does not currently have) port selectors in policy, you can just process packets individually, whether they are whole or fragments. If your SG wants to support port selector, it must at minimum buffer the fragments until the first is received. And if it prepares to do this, it could also assemble the packet in full and not apply IPSEC to fragments at all. From owner-ipsec@lists.tislabs.com Tue Feb 24 12:30:56 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1OKUtMr072352; Tue, 24 Feb 2004 12:30:55 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA08906 Tue, 24 Feb 2004 14:48:56 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems In-reply-to: Your message of "Tue, 24 Feb 2004 21:02:56 +0200." <16443.40928.882061.628063@fireball.acr.fi> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Tue, 24 Feb 2004 15:00:38 -0500 Message-ID: <6389.1077652838@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Tero Kivinen wrote: Tero> solved. The fragmentation issue is solved when using transport mode, Tero> as there cannot be any fragments there. The ICMP issue is not solved Tero> there, as ICMPs might still get wrong protection. Actually, I don't agree. There can be fragments there (consider 8K NFS over UDP), but one can assume that the transport layer is sufficiently clued in to the IPsec layer so that the right SA is "cached". In the case of BITS implementation, the BITS can claim a very large MTU and do fragmentation itself (either before or after ESP/AH). Tero> The vendors have solved this problem differently. As I explained Tero> earlier for example our implementation will do partial-reassembly Tero> (i.e. wait for the first-fragment and then forward all fragments to Tero> same SA) to handle fragments. This will put all fragments to the same Tero> SA, providing them the same protection. Yes, at great cost to queueing buffers, and if a fragment is lost, or goes via another path, you loose. Tero> For ICMPs you can check the original packet part of the ICMP message Tero> and see if it contains enough information so you can select Tero> the proper SA for it (i.e. if the port numbers are available Tero> use them and select SA based on them). If the ICMP does not Tero> have enough data (possible in IPv4) to contain selectors, then Tero> it propably will not have any real Tero> policy sensitive data anyways, thus sending it using any SA is Tero> propably ok. I can agree to this. It does have profound effects upon tunnel exit policy! Tero> I think we should add text to rfc2401bis saying that Tero> If port selectors are used then all data associated with data flow Tero> MUST be sent to the SA associated with that stream. This all data Tero> includes normal packets, ICMP messages related to the data flow and Tero> fragments (first and non-first) of packets. Responder MUST accept all Tero> data stream related data from SA associated with that stream." That's sufficient text for me to understand, but maybe more text is necessary to properly explain the situation. Perhaps your entire message provides a good basis. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQDutZYqHRg3pndX9AQGgZAP+JVoQ0fnvZCV8nsCoM9VtQQD/pq2W2NoI Mjw8M3Jm0r3XVLdcwOaVbqRm/73svAcpMkHLUrJTQYbf04h/Qgpih3aznq+gH+Yw Oa/axPRNk07OSRKy18q0Yo+4RTSBZEgM+WkSBe1z3ANmaUJOOV9j8xU/9hObHs9c Bse2fxrY3N0= =wyHE -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Feb 24 18:21:48 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1P2Llm8090062; Tue, 24 Feb 2004 18:21:48 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14378 Tue, 24 Feb 2004 17:41:12 -0500 (EST) Message-Id: <5.2.0.9.0.20040224173754.0290be48@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 24 Feb 2004 17:44:50 -0500 To: Tero Kivinen , ipsec@lists.tislabs.com From: Mark Duffy Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems In-Reply-To: <16443.40928.882061.628063@fireball.acr.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:02 PM 2/24/2004 +0200, Tero Kivinen wrote: ... >I think we should add text to rfc2401bis saying that > >If port selectors are used then all data associated with data flow >MUST be sent to the SA associated with that stream. This all data >includes normal packets, ICMP messages related to the data flow and >fragments (first and non-first) of packets. Responder MUST accept all >data stream related data from SA associated with that stream." IMO mandating such behavior, with the implied buffering and state-saving it requires, would place a substantial obstacle to the availability of high speed, high capacity implementations. --Mark From owner-ipsec@lists.tislabs.com Tue Feb 24 18:42:50 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1P2gnbt091278; Tue, 24 Feb 2004 18:42:49 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14270 Tue, 24 Feb 2004 17:40:42 -0500 (EST) Message-Id: <200402242250.i1OMo2NA032424@rs9.luxsci.com> From: "William Dixon" To: "'Tero Kivinen'" Cc: , , , , Subject: RE: AD requests WG review of final revisions to draft-ietf-ipsec-nat-reqts-06.txt <= 48hrs please Date: Tue, 24 Feb 2004 14:49:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-reply-to: <16443.51136.808898.917913@ryijy.hel.internal> X-Lux-Comment: LuxSci remailer message ID code - 1077663002-2045697.08661733 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks Tero. Cc'ing the list. Any others have comments on the proposed changes ? -----Original Message----- From: Tero Kivinen [mailto:kivinen@safenet-inc.com] Sent: Tuesday, February 24, 2004 1:53 PM To: William Dixon Cc: Briansw@microsoft.com; vvolpe@cisco.com; Ari.Huttunen@F-Secure.com; ldiburro@nortelnetworks.com Subject: FW: AD requests WG review of final revisions to draft-ietf-ipsec-nat-reqts-06.txt <= 48hrs please William Dixon writes: > NAT-T authors, please make sure you are ok with these changes in next 24hrs. I checked the changes out, and they seem to be ok. > I noticed also that UDP-ESP-08 currently lacks a statement on how it > meets the requirements. I noticed that when I edited it, but didn't want to add it myself. > IKE NAT-T has such a statement in the intro. Thanks, -Wm And that actually states, that the IKE NAT-T in combination with UDP-ENCAPS represents an "unconditionally compliant" solution to the requirements as defined by [Aboba03]... -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Wed Feb 25 06:27:57 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PERum2006447; Wed, 25 Feb 2004 06:27:57 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11279 Wed, 25 Feb 2004 08:44:55 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <76651B96-6707-11D8-A080-0003935495EC@mindspring.com> Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com, tytso@mit.edu, byfraser@cisco.com, hugo@ee.technion.ac.il From: "David A. McGrew" Date: Tue, 24 Feb 2004 15:24:35 -0500 To: cfrg@ietf.org X-Mailer: Apple Mail (2.606) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, we CFRGers need to wrap up the discussion of Hugo's proposed change to the IKEv2 Internet Draft (see https://www1.ietf.org/mail-archive/working-groups/cfrg/current/ msg00366.html). This ID is close to being wrapped up, so it is important that we get our comments in now. I think that the questions that CFRG ought to be answering are: * Is the problem significant? * Is proposed solution good? * Is revising the specification warranted? From Barb Fraser, I understand that the cost of delaying the IKEv2 draft is not big - as long the change is small and can be made by the time that the periodic blackout on Internet Drafts is lifted on or around March 11th. From what I've gathered, it should be possible to make this change within this timeframe (Barb, Ted, Hugo, if I'm wrong about this, please correct me.) Here is my personal $0.02: the change is well motivated, the solution is good (it requires storing two extra keys, which seems not to be a big deal), and if the spec can be rev'ed in the next couple of weeks, I vote to do it. I spoke with several people about this issue who had similar sentiments. Other opinions welcome. David From owner-ipsec@lists.tislabs.com Wed Feb 25 06:30:46 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PEUjtg006585; Wed, 25 Feb 2004 06:30:45 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11437 Wed, 25 Feb 2004 08:45:47 -0500 (EST) In-Reply-To: <20040224165035.GA27403@thunk.org> References: <20040224165035.GA27403@thunk.org> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <77B04400-6707-11D8-A080-0003935495EC@cisco.com> Content-Transfer-Encoding: 7bit Cc: Hugo Krawczyk , cfrg@ietf.org, Charlie Kaufman , ipsec@lists.tislabs.com, Paul Hoffman / VPNC , "The Purple Streak, Hilarie Orman" From: "David A. McGrew" Subject: Re: [Cfrg] Re: Changing the key deriveration Date: Tue, 24 Feb 2004 15:24:37 -0500 To: "Theodore Ts'o" X-Mailer: Apple Mail (2.606) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ted, I'll try to wrap up the discussion and move on a summary that we can agree on, in a separate mail. David On Feb 24, 2004, at 11:50 AM, Theodore Ts'o wrote: > On Fri, Feb 20, 2004 at 06:09:58PM -0800, Paul Hoffman / VPNC wrote: >> At 9:57 PM +0200 2/17/04, Hugo Krawczyk wrote: >>> Anyway, replacing SK_ai and SK_ar in the above text (as well as in >>> 2.15, >>> first paragraph) with SK_d does resolve the problem of using two >>> algorithms (prf and integrity) with the same key, and it is much >>> better >>> than what is done now. >> >> There have been no more comments on this, and the ADs are still >> waiting for a final draft of this document so they can move all three >> IKEv2 documents to IETF last call. > > David and Ran --- is the CFRG currently working on some kind of > official statement that represents the consensus of the group, or > should we use the comments made by CFRG members in our deliberations? > If the former, could you give us a timeline when the official comments > from the CFRG can be expected? If the latter, please accept the > thanks of the IPSEC working group to those members who took the time > to evaluate Hugo's proposal. > > - Ted > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg > From owner-ipsec@lists.tislabs.com Wed Feb 25 06:41:48 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PEfm0o007603; Wed, 25 Feb 2004 06:41:48 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16960 Wed, 25 Feb 2004 09:06:49 -0500 (EST) Date: Wed, 25 Feb 2004 09:18:05 -0500 (EST) From: canetti To: "David A. McGrew" cc: cfrg@ietf.org, ipsec@lists.tislabs.com, tytso@mit.edu, byfraser@cisco.com, hugo@ee.technion.ac.il Subject: Re: your mail In-Reply-To: <76651B96-6707-11D8-A080-0003935495EC@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I concur. Ran On Tue, 24 Feb 2004, David A. McGrew wrote: > Here is my personal $0.02: the change is well motivated, the solution > is good (it requires storing two extra keys, which seems not to be a > big deal), and if the spec can be rev'ed in the next couple of weeks, I > vote to do it. I spoke with several people about this issue who had > similar sentiments. Other opinions welcome. > > David > From owner-ipsec@lists.tislabs.com Wed Feb 25 11:21:00 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PJKxND027649; Wed, 25 Feb 2004 11:21:00 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17110 Wed, 25 Feb 2004 13:35:46 -0500 (EST) To: ipsec@lists.tislabs.com CC: Mark Duffy Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems In-reply-to: Your message of "Tue, 24 Feb 2004 17:44:50 EST." <5.2.0.9.0.20040224173754.0290be48@email> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Wed, 25 Feb 2004 13:47:24 -0500 Message-ID: <32221.1077734844@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Mark Duffy wrote: >> I think we should add text to rfc2401bis saying that >> >> If port selectors are used then all data associated with data flow >> MUST be sent to the SA associated with that stream. This all data >> includes normal packets, ICMP messages related to the data flow and >> fragments (first and non-first) of packets. Responder MUST accept all >> data stream related data from SA associated with that stream." Mark> IMO mandating such behavior, with the implied buffering and Mark> state-saving it requires, would place a substantial obstacle Mark> to the availability of high speed, high capacity implementations. To date, the only significant deployment that I know of that would even use port-selectors is securing L2TP traffic - and that traffic, being ultimately a tunnelling protocol which terminates the *UDP* on two hosts, should not have a problem. Can you name a situation or application that requires high speed, high capacity offloading of *per-port* selector granularity? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQDztu4qHRg3pndX9AQGsvwQA3mfD9CJ/1FUKxS90ggs+nSR9OdfWGfOP Npn1aucJJnWK68qKwgXkyYRGhMrGNv75+geklK5OF8R1qThfjctIczIixj1RBv+C ZAC0Qy71l243KFlrJmL9VNnRgPV/W91L3KCIC8bvbEwtY+cRXAvuPdFiWBOOP+GG KGidBHf9c3s= =Z+I3 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Feb 25 11:40:35 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PJeYIY028615; Wed, 25 Feb 2004 11:40:35 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23449 Wed, 25 Feb 2004 14:07:29 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <29398.1077646869@marajade.sandelman.ottawa.on.ca> References: <29398.1077646869@marajade.sandelman.ottawa.on.ca> Date: Wed, 25 Feb 2004 13:38:59 -0500 To: Michael Richardson From: Stephen Kent Subject: Re: ICMP messages and per-port selectors Cc: IPsec WG 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 Michael, >The essential premise of the later documents it that an ICMP message >such as a port-unreachable should be examined - the "quoted" IP packet >examined, reversed (src<->dst address/ports) and an SA found for it. Ultimately we may need to deal with ICMP messages arriving via an SA by looking at the "quoted" packet, but I would not suggest that one do it literally as described above. I worry about the delays and added complexity imposed on receivers re what we might consider "fast path" processing. We need to pick out ICMP traffic to perform the more in depth inspection this traffic requires. That observation motivated the idea of a separate SA for all ICMP traffic between two IPsec peers, where we can make first order decisions about accepting or rejecting this traffic based on message type and code. Then, for acceptable traffic, we can look inside to see what we have in the way of a returned packet and what to do with it. We're not guaranteed that the 64-bytes we get with an IPv4 ICMP message will have porty fields, for example, so it is not always as easy as reversing the addresses and ports to match against an extant SA. Steve From owner-ipsec@lists.tislabs.com Wed Feb 25 11:42:42 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PJgfvL028730; Wed, 25 Feb 2004 11:42:42 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23471 Wed, 25 Feb 2004 14:07:36 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <200402241621.i1OGLATm018207@burp.tkv.asdf.org> References: <16434.27900.199285.136682@fireball.acr.fi> <20040218161436.9707F2051E@wolfe.bbn.com> <16435.55623.26827.859229@fireball.acr.fi> <16438.958.625838.937789@fireball.acr.fi> <20040220175458.GC6177@binky.central.sun.com> <20040220200336.GF6177@binky.central.sun.com> <200402241621.i1OGLATm018207@burp.tkv.asdf.org> Date: Wed, 25 Feb 2004 12:58:10 -0500 To: Markku Savela From: Stephen Kent Subject: Re: SAs that carry fragments Was: Re: Some IKEv2 issues 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 18:21 +0200 2/24/04, Markku Savela wrote: >I'm still somewhat uneasy with this talk about doing IPSEC on >fragments. Say we have a following setup: > > H <======> SG <-----> S > > H is my host > SG is security gateway > S is some server behind the SG > >Normally my policy on H would express something like > > Use tunneled IPSEC via SG using ESP (3des, sha1) for all > communication with server S. > >There are cases > >1. S replies with fragmented packets > > 1.1 SG reassembles the packet, applies IPSEC as required, and the > result gets fragmented again. there has never been a requirement for an SG to do this, but it could, and the result would be indistinguishable from traffic from S that had not been fragmented. > 1.2 SG does not reassemble packet, but applies IPSEC directly to the > fragments coming from S. and, these IPsec protected packets MIGHT be fragmented later along the path > >2. S does not fragment packets, and sends them as whole. > > 2.1 SG applies IPSEC to packet and sends it out without > fragmentation (packet is still short enough to fit PMTU) you didn't say for 1.1 above where the packet is fragmented. if the SG fragments it after applying IPsec, this is indistinguishable from later fragmentation between SH and H, so I assume this is why you didn't need to say which of these two cases occurred. > > 2.2 SG applies IPSEC, but the resulting packet needs to be > fragmented really another example of 1.1 > >--------- > >The bothering thing is: > >The H must now be prepared to handle all combinations EQUALLY with >the same dataflow > > - full packets protected with IPSEC > - full IPSEC:ed packets fragmented > - fragments with IPSEC applied individually to them but this has always been true. >because host H cannot know what type of impelementation SG has >(whether it reassembles packets from S before doing IPSEC or not). I think this is irrelevant, for the reasons I cited above. >If there are different SA's required for normal and fragment packets, >the implementation must in worst case negotiate 4 SA's for each >connection, to be prepared for all possible variants (fragment and >non-fragment SA for each direction). this is true, in the worst case, but the way you said it makes it sound even worse, since there would already be 2 SA for each "connection." >If the possibility of the fragments needs to noticed in the policy, >all policies need to be duplicated: one for non-fragmented, and one >for fragmented case. I don't understand you reasoning here. if we were to specify an SA to carry non-initial fragments are to be carried on a separate SA between two IPsec peers, then that would add another SPD entry on a per-peer basis, but that is not the same as doubling the number of SPD entries. >The fragments may not arrive in order. If the policy is dependent on >specific ports, the recever must remember each applied SA on each >fragment until the full packet is received and the policy can be >checked. not true for v4. this is just one possible implementation option. others have suggested that its OK to accept non-initial fragments over an SA so long as minimum offset checks are verified, to prevent overlapping reassmebly attacks. >Some optimization is possible, like if two fragments belonging to the >same packet are protected with different SA's, the whole packet is >invalid, and receiver can stop processing the fragments of that >packet. [Note: if fragments are protected with some different SA, then >also the first fragment must use the same]. sorry, but I can't quite parse the sentences above. >What if SA's expire between fragments? For example due to bytecount? >Long fragmented packets eat up the replay window fast (I still use 32 >bits, need to upgrade I guess)? > >I would just forbid doing IPSEC on fragments, and require SG in above >to do reassembly, if S fragmented the packet. The other option is to >disallow port selectors with tunnel mode policies [and thus the policy >could be checked on each fragment individually]. I think that the suggested solution to require reassembly by an SG is not viable, in general, e.g., because outbound fragments might arrive at two different SGs. In general, at the Ip layer, we discourage intermediate reassembly strategies because of this sort of potential problem. Steve From owner-ipsec@lists.tislabs.com Wed Feb 25 11:46:56 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PJktYX029115; Wed, 25 Feb 2004 11:46:55 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA24133 Wed, 25 Feb 2004 14:10:29 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Wed, 25 Feb 2004 14:28:00 -0500 To: ipsec mailingList From: Karen Seo Subject: 2401bis Issue # 93 -- Clarification re: the selector "name" 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 #: 93 Title: Clarification re: the selector "name" Description: ============ The current 2401bis contains updates (from 2401) to the text on the selector "name", but additional clarification is still needed, e.g., how to use the field, correspondence to IKEv2 fields, etc. Proposed approach: ================== Replace the current 2401bis text with the text below. Note: We will also need to add some text to the earlier discussion of the SPD-S, to match the back pointer below. Name: A name may be used as a symbolic identifier for an IPsec source or destination address. It is not a selector in the same sense as a literal address, protocol, port, etc. As noted earlier, the SPS-S can be divided into named entries and unnamed entries. The latter entries are matched to traffic based on the selector types and values, whereas the named entries are selected based on names. Named SPD entries are used in two ways: 1. A named SPD entry is used by a responder (vs. initiator) in support of access control when IP address selectors would not be appropriate, e.g., for "road warriors." The name used to match this field is communicated during the IKE negotiation in the ID payload. In this context, the remote system's IP address (inner IP header in tunnel mode) is bound to the SAD entry created by the IKE negotiation. All IPsec implementations MUST support this use of names. 2. A named SPD entry may be used by an initiator to identify a user for whom an IPsec SA will be created (or for whom traffic may be bypassed). Support for this use is optional for multi-user, native host implementations. A named SPD entry MUST set either the source or destination IP address selector to NULL, consistent with its use in support of the first or second scenario. The identifiers employed in named SPD entries are one of the following four types: a. a fully qualified user name string (email), e.g., mozart@foo.example.com (this corresponds to ID_RFC822_ADDR in IKEv2) b. a fully qualified DNS name, e.g., foo.example.com (this corresponds to ID_FQDN in IKEv2) c. X.500 distinguished name, e.g., C = US, SP = MA, O = BBN Technologies, CN = Stephen T. Kent (this corresponds to ID_DER_ASN1_DN in IKEv2, after decoding) d. a user's name in a local system context (this corresponds to ID_KEY_ID in IKEv2) Thank you, Karen From owner-ipsec@lists.tislabs.com Wed Feb 25 13:33:09 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PLX8l3037896; Wed, 25 Feb 2004 13:33:09 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14510 Wed, 25 Feb 2004 15:52:34 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16445.3549.141718.642008@fireball.acr.fi> Date: Wed, 25 Feb 2004 23:04:29 +0200 From: Tero Kivinen To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems In-Reply-To: <6389.1077652838@marajade.sandelman.ottawa.on.ca> References: <16443.40928.882061.628063@fireball.acr.fi> <6389.1077652838@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 4 min X-Total-Time: 3 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson writes: > Tero> solved. The fragmentation issue is solved when using transport mode, > Tero> as there cannot be any fragments there. The ICMP issue is not solved > Tero> there, as ICMPs might still get wrong protection. > Actually, I don't agree. > There can be fragments there (consider 8K NFS over UDP), but one can > assume that the transport layer is sufficiently clued in to the IPsec > layer so that the right SA is "cached". The rfc2401bis says that "AH and ESP cannot be applied using transport mode to IPv4 packets that are fragments.". I.e. in transport mode the IPsec is applied to full packets, and then the ESP packet is fragmented. This will solve the problem as while we are doing the SA selection based on selectors, we always have full packet, not fragments, thus we can always see the port numbers. > In the case of BITS implementation, the BITS can claim a very large > MTU and do fragmentation itself (either before or after ESP/AH). No, all implementations using transport mode MUST do framentation after ESP/AH. They cannot do it before. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Wed Feb 25 15:05:56 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PN5tPI044010; Wed, 25 Feb 2004 15:05:56 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA03288 Wed, 25 Feb 2004 17:30:53 -0500 (EST) Message-Id: <5.2.0.9.0.20040225161626.020c34e0@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 25 Feb 2004 16:51:33 -0500 To: Michael Richardson , ipsec@lists.tislabs.com From: Mark Duffy Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems In-Reply-To: <32221.1077734844@marajade.sandelman.ottawa.on.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 01:47 PM 2/25/2004 -0500, Michael Richardson wrote: > Tero> I think we should add text to rfc2401bis saying that > Tero> > Tero> If port selectors are used then all data associated with data flow > Tero> MUST be sent to the SA associated with that stream. This all data > Tero> includes normal packets, ICMP messages related to the data flow and > Tero> fragments (first and non-first) of packets. Responder MUST accept all > Tero> data stream related data from SA associated with that stream." > > Mark> IMO mandating such behavior, with the implied buffering and > Mark> state-saving it requires, would place a substantial obstacle > Mark> to the availability of high speed, high capacity implementations. > > To date, the only significant deployment that I know of that would >even use port-selectors is securing L2TP traffic - and that traffic, >being ultimately a tunnelling protocol which terminates the *UDP* on >two hosts, should not have a problem. > > Can you name a situation or application that requires high speed, high >capacity offloading of *per-port* selector granularity? IPsec incorporates port selectors and the market looks to IPsec equipment vendors to support them. As a vendor, when I ship a box with support for port selectors I have to assume my customers will use them. It has to work and it has to perform. To respond more directly to your question, any situation that requires per-port selector granularity at low speed/capacity may require the same selector granularity at high speed/capacity if the data rate grows or if IPsec is provided at a place in the network where traffic is more highly aggregated. If no one needs per port granularity, let's remove it from 2401bis; if it is needed, then in some cases it will be needed with high performance. One reason someone might want to encrypt only certain applications would be if IPsec implementations that do not run at wire rate are present in the network and therefore encryption has to be rationed to the most sensitive apps. --Mark From owner-ipsec@lists.tislabs.com Wed Feb 25 16:09:09 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1Q096RU047613; Wed, 25 Feb 2004 16:09:08 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17829 Wed, 25 Feb 2004 18:33:21 -0500 (EST) Message-ID: <006f01c3fbf9$63f820a0$c91167c0@adithya> From: "Mohan Parthasarathy" To: "ipsec mailingList" , "Karen Seo" Cc: , , "Angelos D. Keromytis" , , References: Subject: Re: 2401bis Issue # 93 -- Clarification re: the selector "name" Date: Wed, 25 Feb 2004 15:45:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Karen, Just one question below.. > Here's a description and proposed approach for: > > IPsec Issue #: 93 > > Title: Clarification re: the selector "name" > > > Description: > ============ > The current 2401bis contains updates (from 2401) to the text on the > selector "name", but additional clarification is still needed, e.g., > how to use the field, correspondence to IKEv2 fields, etc. > > > Proposed approach: > ================== > Replace the current 2401bis text with the text below. Note: We will > also need to add some text to the earlier discussion of the SPD-S, to > match the back pointer below. > > Name: A name may be used as a symbolic identifier for an IPsec source > or destination address. It is not a selector in the same sense as a > literal address, protocol, port, etc. As noted earlier, the SPS-S can > be divided into named entries and unnamed entries. The latter entries > are matched to traffic based on the selector types and values, > whereas the named entries are selected based on names. Named SPD > entries are used in two ways: > > 1. A named SPD entry is used by a responder (vs. initiator) in > support of access control when IP address selectors would not be > appropriate, e.g., for "road warriors." The name used to match this > field is communicated during the IKE negotiation in the ID payload. > In this context, the remote system's IP address (inner IP header in > tunnel mode) is bound to the SAD entry created by the IKE > negotiation. All IPsec implementations MUST support this use of names. > > 2. A named SPD entry may be used by an initiator to identify a user > for whom an IPsec SA will be created (or for whom traffic may be > bypassed). Support for this use is optional for multi-user, native > host implementations. > > A named SPD entry MUST set either the source or destination IP > address selector to NULL, consistent with its use in support of the > first or second scenario. The identifiers employed in named SPD > entries are one of the following four types: > > a. a fully qualified user name string (email), e.g., > mozart@foo.example.com > (this corresponds to ID_RFC822_ADDR in IKEv2) > > b. a fully qualified DNS name, e.g., > foo.example.com > (this corresponds to ID_FQDN in IKEv2) > > c. X.500 distinguished name, e.g., > C = US, SP = MA, > O = BBN Technologies, CN = Stephen T. Kent > (this corresponds to ID_DER_ASN1_DN in IKEv2, after decoding) > > d. a user's name in a local system context > (this corresponds to ID_KEY_ID in IKEv2) > Should (d) be constrained to be a user name ? This is just whatever the two systems understand. It could be an employee ID or different thing in other contexts. ID_KEY_ID carries opaque octet stream as per the definition. So, can we not leave it flexible ? thanks mohan > Thank you, > Karen From owner-ipsec@lists.tislabs.com Wed Feb 25 16:46:59 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1Q0kwZR050451; Wed, 25 Feb 2004 16:46:58 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA25167 Wed, 25 Feb 2004 19:11:47 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <16445.3549.141718.642008@fireball.acr.fi> References: <16443.40928.882061.628063@fireball.acr.fi> <6389.1077652838@marajade.sandelman.ottawa.on.ca> <16445.3549.141718.642008@fireball.acr.fi> Date: Wed, 25 Feb 2004 19:19:35 -0500 To: Tero Kivinen From: Stephen Kent Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems Cc: Michael Richardson , 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:04 +0200 2/25/04, Tero Kivinen wrote: >Michael Richardson writes: >> Tero> solved. The fragmentation issue is solved when using >>transport mode, >> Tero> as there cannot be any fragments there. The ICMP issue >>is not solved >> Tero> there, as ICMPs might still get wrong protection. >> Actually, I don't agree. >> There can be fragments there (consider 8K NFS over UDP), but one can >> assume that the transport layer is sufficiently clued in to the IPsec >> layer so that the right SA is "cached". > >The rfc2401bis says that "AH and ESP cannot be applied using transport >mode to IPv4 packets that are fragments.". I.e. in transport mode the >IPsec is applied to full packets, and then the ESP packet is >fragmented. This will solve the problem as while we are doing the SA >selection based on selectors, we always have full packet, not >fragments, thus we can always see the port numbers. right. > >> In the case of BITS implementation, the BITS can claim a very large >> MTU and do fragmentation itself (either before or after ESP/AH). > >No, all implementations using transport mode MUST do framentation >after ESP/AH. They cannot do it before. yes, the intent is to fragment after applying IPsec, not before. Steve From owner-ipsec@lists.tislabs.com Wed Feb 25 16:50:19 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1Q0oHMf050634; Wed, 25 Feb 2004 16:50:19 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA25901 Wed, 25 Feb 2004 19:15:56 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <5.2.0.9.0.20040225161626.020c34e0@email> References: <5.2.0.9.0.20040225161626.020c34e0@email> Date: Wed, 25 Feb 2004 19:25:42 -0500 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems 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 I'll mention my example, again, as to why port fields are appropriate, and add a n ote on performance: - by restricting access via an SA to a well known set of ports, relative to a specific address or set of addresses, one can reduce opportunities for attacks against the hosts or servers. think of this as a way to close off access to inappropriate ports, and to prevent malicious software that may have taken over a machine from being able to use that machine to launch attacks against other machines, at least for some classes of attacks. the worm that attacked IIS and spear via e-mail from web servers was the example I cited earlier. As for high speed, I concur with Mark. For my DoD clients, the intent is to be able to take advantage of these access control facilities over a wide performance range, not to have to tradeoff access control features vs. interface speeds. Steve From owner-ipsec@lists.tislabs.com Wed Feb 25 17:58:58 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1Q1wvlt054452; Wed, 25 Feb 2004 17:58:57 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA06672 Wed, 25 Feb 2004 20:22:31 -0500 (EST) Date: Wed, 25 Feb 2004 20:33:59 -0500 From: Thor Lancelot Simon To: ipsec@lists.tislabs.com Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems Message-ID: <20040226013359.GA683@panix.com> Reply-To: tls@rek.tjls.com References: <5.2.0.9.0.20040224173754.0290be48@email> <32221.1077734844@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32221.1077734844@marajade.sandelman.ottawa.on.ca> User-Agent: Mutt/1.4.2.1i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Feb 25, 2004 at 01:47:24PM -0500, Michael Richardson wrote: > > To date, the only significant deployment that I know of that would > even use port-selectors is securing L2TP traffic - and that traffic, > being ultimately a tunnelling protocol which terminates the *UDP* on > two hosts, should not have a problem. I use port selectors quite regularly. I use them, for instance, for preserving confidentality of syslog logs without encrypting all traffic between the log source and sink. Why do I do this? I do it because the performance impact of encrypting all the traffic would be unacceptable; so this is not a "high speed, high capacity" application, perhaps, but it is not one in which arbitrarily poor performance is acceptable. Thor From owner-ipsec@lists.tislabs.com Wed Feb 25 19:25:24 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1Q3PNwO059697; Wed, 25 Feb 2004 19:25:24 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA24521 Wed, 25 Feb 2004 21:48:36 -0500 (EST) From: "Bora Akyol" To: Subject: RE: Traffic selectors, fragments, ICMP messages and security policy problems Date: Wed, 25 Feb 2004 19:00:09 -0800 Message-ID: <007c01c3fc14$a50e9e50$060a0a0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > - by restricting access via an SA to a well known set of > ports, relative to a specific address or set of addresses, one can > reduce opportunities for attacks against the hosts or servers. think > of this as a way to close off access to inappropriate ports, and to > prevent malicious software that may have taken over a machine from > being able to use that machine to launch attacks against other > machines, at least for some classes of attacks. the worm that > attacked IIS and spear via e-mail from web servers was the example I > cited earlier. It is hard to speak without knowing the complete network architecture and application, but for what is described here, a firewall may be more appropriate. Much easier on the server since it offloads filtering from the server to the firewall and current breed of firewalls are capable of multi gigabit speeds for doing access control and filtering and stateful inspection. Also, the worms and the general classes of zombies want to speak to the server on a legitimate well-known port. If the network architecture is such that the server wants to talk a subset of the intranet/Internet, then it is easier to put the server behind a firewall/IDS system. If it is intranet alone, and switches are involved, VLANs can also be used, provided that the routing is set-up correctly. > > As for high speed, I concur with Mark. For my DoD clients, the > intent is to be able to take advantage of these access control > facilities over a wide performance range, not to have to tradeoff > access control features vs. interface speeds. Agreed as long as the features are not frivilous. -- Bora From owner-ipsec@lists.tislabs.com Wed Feb 25 23:40:30 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1Q7eTO8008008; Wed, 25 Feb 2004 23:40:30 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA23681 Thu, 26 Feb 2004 01:51:42 -0500 (EST) In-Reply-To: <007c01c3fc14$a50e9e50$060a0a0a@amer.cisco.com> References: <007c01c3fc14$a50e9e50$060a0a0a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: From: Yoav Nir Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems Date: Thu, 26 Feb 2004 09:03:20 +0200 To: "Bora Akyol" X-Mailer: Apple Mail (2.612) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Firewalls have their place, but often administrators like to allow all decrypted traffic in, believing that because it was encrypted, it is more secure. A very common policy, especially when the firewall and VPN are collocated is something like this: - Allow HTTP and HTTPS to web server + outgoing - Allow SMTP to SMTP server - Allow all VPN traffic - Block everything else When they're not collocated, you put the firewall closer to the Internet than the VPN, because it can filter all those gigabits. Such a firewall can't know what's in the VPN. This makes sense because VPN traffic is considered "internal" and therefore can be anything. We want someone in the Paris office to be able to access all the network resources as if she were in the main office. Of course, now we know better, and would not like to encrypt the attacks that the worm that infected her computer is sending out. This is why VPN has to have its own access control regardless of the firewall. A case could be made for a pure VPN with no port selectors, collocated with a dedicated firewall, and that works as long as both ends are managed by the same administrator. If, however, your policy is to block NFS, it's a shame that the other side would keep encrypting and your side would keep decrypting. On Feb 26, 2004, at 5:00 AM, Bora Akyol wrote: > >> - by restricting access via an SA to a well known set of >> ports, relative to a specific address or set of addresses, one can >> reduce opportunities for attacks against the hosts or servers. think >> of this as a way to close off access to inappropriate ports, and to >> prevent malicious software that may have taken over a machine from >> being able to use that machine to launch attacks against other >> machines, at least for some classes of attacks. the worm that >> attacked IIS and spear via e-mail from web servers was the example I >> cited earlier. > > It is hard to speak without knowing the complete network architecture > and application, but for what is described here, a firewall > may be more appropriate. > Much easier on the server since it offloads > filtering from the server to the firewall and current > breed of firewalls are capable of multi gigabit speeds > for doing access control and filtering and stateful inspection. From owner-ipsec@lists.tislabs.com Thu Feb 26 01:35:59 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1Q9ZwVM047152; Thu, 26 Feb 2004 01:35:58 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA22931 Thu, 26 Feb 2004 03:56:09 -0500 (EST) Date: Thu, 26 Feb 2004 10:07:44 +0100 From: Jean-Jacques Puig To: IPsec WG Subject: Re: ICMP messages and per-port selectors Message-ID: <20040226090744.GJ9542@ivan.int-evry.fr> Mail-Followup-To: IPsec WG References: <29398.1077646869@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Feb 25, 2004 at 01:38:59PM -0500, Stephen Kent wrote: > Michael, > > >The essential premise of the later documents it that an ICMP message > >such as a port-unreachable should be examined - the "quoted" IP packet > >examined, reversed (src<->dst address/ports) and an SA found for it. > > Ultimately we may need to deal with ICMP messages arriving via an SA > by looking at the "quoted" packet, but I would not suggest that one > do it literally as described above. I worry about the delays and > added complexity imposed on receivers re what we might consider "fast > path" processing. We need to pick out ICMP traffic to perform the > more in depth inspection this traffic requires. That observation > motivated the idea of a separate SA for all ICMP traffic between two > IPsec peers, where we can make first order decisions about accepting > or rejecting this traffic based on message type and code. Then, for > acceptable traffic, we can look inside to see what we have in the way > of a returned packet and what to do with it. This sounds efficient but all ICMP error types will still carry original data which would require appropriate protection (cf. thread 'Traffic selectors, fragments, ICMP messages and security policy problems'). There are certainly no widely available statistics on the amount of ICMP traffic of each type on the Internet, but I think errors (likely, destination_unreachable) are the most common. Thus, except for Echo/Echo_Reply, there is almost no message which could politically cope with a SA for all ICMP traffic, given the original data being carried. A way out would be to get rid of original data; that is: when forwarding, the gateway would erase any original data after those which should be available for upper layer selectors check (which should also be in most cases the same required for a minimal treatment of the error on the host). This way, information disclosure is limited. > We're not guaranteed > that the 64-bytes we get with an IPv4 ICMP message will have porty > fields, for example, so it is not always as easy as reversing the > addresses and ports to match against an extant SA. Can you give an example of these 64 BITS not carrying the adequate information for upper layer selectors check ? Note that non-initial fragments are not allowed in ICMP errors, and that the original data should be *at least* 64 bits (as for rfc1122). -- Jean-Jacques Puig [homepage] http://www-lor.int-evry.fr/~puig/ Soutenez le mouvement SAUVONS LA RECHERCHE : http://recherche-en-danger.apinc.org/ From owner-ipsec@lists.tislabs.com Thu Feb 26 02:01:34 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QA1XXW051584; Thu, 26 Feb 2004 02:01:34 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA29669 Thu, 26 Feb 2004 04:25:16 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16445.48695.689376.728332@fireball.acr.fi> Date: Thu, 26 Feb 2004 11:36:55 +0200 From: Tero Kivinen To: Mark Duffy Cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems In-Reply-To: <5.2.0.9.0.20040225161626.020c34e0@email> References: <5.2.0.9.0.20040225161626.020c34e0@email> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 3 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark Duffy writes: > To respond more directly to your question, any situation that requires > per-port selector granularity at low speed/capacity may require the same > selector granularity at high speed/capacity if the data rate grows or if > IPsec is provided at a place in the network where traffic is more highly > aggregated. If no one needs per port granularity, let's remove it from > 2401bis; if it is needed, then in some cases it will be needed with high > performance. > > One reason someone might want to encrypt only certain applications would be > if IPsec implementations that do not run at wire rate are present in the > network and therefore encryption has to be rationed to the most > sensitive apps. Which means that you really would not like the case where the non-first fragments of that sensitive apps receive no protection at all are sent out in clear? Or all ICMP messages sent back quoting the packet are also sent in clear. If we ever are going to use tunnel mode IPsec with port selectors in the cases where different protocols gets different level of encryption we MUST put all the traffic associated with the flow (normal packets, first fragments, non-first fragments and ICMP messages) to SA having at least similar protection. In your case you propably wouldn't have resources to encrypt all non-first fragments, thus creating SA for non-first fragments isn't a solution for you? -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Thu Feb 26 02:04:48 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QA4ltu051908; Thu, 26 Feb 2004 02:04:47 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA00212 Thu, 26 Feb 2004 04:28:36 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16445.48883.758215.735165@fireball.acr.fi> Date: Thu, 26 Feb 2004 11:40:03 +0200 From: Tero Kivinen To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems In-Reply-To: References: <5.2.0.9.0.20040225161626.020c34e0@email> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 2 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > - by restricting access via an SA to a well known set of > ports, relative to a specific address or set of addresses, one can > reduce opportunities for attacks against the hosts or servers. think > of this as a way to close off access to inappropriate ports, and to > prevent malicious software that may have taken over a machine from > being able to use that machine to launch attacks against other > machines, at least for some classes of attacks. the worm that > attacked IIS and spear via e-mail from web servers was the example I > cited earlier. For that kind of cases the separate non-first fragment SA is ok, as your different policies are either encrypt with XXX or drop, i.e. you do not have pass through in clear rule. Immediately when you have pass through in clear rule which sents some traffic in clear, then you needs to select whether the non-first fragments are going to use the encrypt with XXX rule or pass through in clear rule, and if the reason for pass through in clear was performance issues, then you propably cannot encrypt the non-first fragments. > As for high speed, I concur with Mark. For my DoD clients, the > intent is to be able to take advantage of these access control > facilities over a wide performance range, not to have to tradeoff > access control features vs. interface speeds. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Thu Feb 26 06:50:59 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QEowKm068556; Thu, 26 Feb 2004 06:50:59 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06267 Thu, 26 Feb 2004 09:07:51 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16446.125.832000.333536@gargle.gargle.HOWL> Date: Thu, 26 Feb 2004 09:19:41 -0500 From: Paul Koning To: kent@bbn.com Cc: ipsec@lists.tislabs.com Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems References: <5.2.0.9.0.20040225161626.020c34e0@email> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Stephen" == Stephen Kent writes: Stephen> I'll mention my example, again, as to why port fields are Stephen> appropriate, and add a n ote on performance: Stephen> - by restricting access via an SA to a well known set of Stephen> ports, relative to a specific address or set of addresses, Stephen> one can reduce opportunities for attacks against the hosts Stephen> or servers. think of this as a way to close off access to Stephen> inappropriate ports, and to prevent malicious software that Stephen> may have taken over a machine from being able to use that Stephen> machine to launch attacks against other machines, at least Stephen> for some classes of attacks. the worm that attacked IIS and Stephen> spear via e-mail from web servers was the example I cited Stephen> earlier. Stephen> As for high speed, I concur with Mark. For my DoD clients, Stephen> the intent is to be able to take advantage of these access Stephen> control facilities over a wide performance range, not to Stephen> have to tradeoff access control features vs. interface Stephen> speeds. I think Mark argued some in both direction (i.e., port selection as a workaround for poor crypto performance), but I agree with your view. If a feature is useful, it should be implementable at good performance. My suspicion is that some of the argument is coming from the commercial marketplace. IPSec is hard enough to manage that the added complexity of port selector setup is going to be adopted only when there is a strong need for it. In environments where I have worked (which were commercial networks), that wasn't the case, but I can see your argument that there are others (such as DoD) where it definitely is. So where are we with Tero's previous analysis, which shows that port selection in the presence of fragmentation can only be done correctly if you keep cross-fragment state in the SG, i.e., it is expensive at high speed? It sounds to me like we have a case of (a) fast and efficient, (b) support fragments, (c) support port selectors -- pick any TWO. paul From owner-ipsec@lists.tislabs.com Thu Feb 26 07:41:11 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QFfAgJ071316; Thu, 26 Feb 2004 07:41:10 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17171 Thu, 26 Feb 2004 10:01:22 -0500 (EST) Message-Id: <5.2.0.9.0.20040226095435.0208aa50@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 26 Feb 2004 10:13:37 -0500 To: Tero Kivinen From: Mark Duffy Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems Cc: Michael Richardson , ipsec@lists.tislabs.com In-Reply-To: <16445.48695.689376.728332@fireball.acr.fi> References: <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040225161626.020c34e0@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:36 AM 2/26/2004 +0200, Tero Kivinen wrote: >Mark Duffy writes: > > To respond more directly to your question, any situation that requires > > per-port selector granularity at low speed/capacity may require the same > > selector granularity at high speed/capacity if the data rate grows or if > > IPsec is provided at a place in the network where traffic is more highly > > aggregated. If no one needs per port granularity, let's remove it from > > 2401bis; if it is needed, then in some cases it will be needed with high > > performance. > > > > One reason someone might want to encrypt only certain applications > would be > > if IPsec implementations that do not run at wire rate are present in the > > network and therefore encryption has to be rationed to the most > > sensitive apps. > >Which means that you really would not like the case where the >non-first fragments of that sensitive apps receive no protection at >all are sent out in clear? Or all ICMP messages sent back quoting the >packet are also sent in clear. agreed >If we ever are going to use tunnel mode IPsec with port selectors in >the cases where different protocols gets different level of encryption >we MUST put all the traffic associated with the flow (normal packets, >first fragments, non-first fragments and ICMP messages) to SA having >at least similar protection. I'm not convinced that is a MUST. One alternative is to leave this choice to the administrators. I.e. if they want to protect the non-initial fragments, they do so via SPD rules that match them based on port selectors of "any" or "opaque". >In your case you propably wouldn't have resources to encrypt all >non-first fragments, thus creating SA for non-first fragments isn't >a solution for you? Not so. I do not see encrypting all fragments as a problem at all. I see mandating that security gateways buffer fragments until such time as they can associate them with the initial fragment as a problem (for high speed/capacity implementations). Creating a separate SA for non-initial fragments is acceptable to me, but I believe the wg has rejected this. Like almost everything, this is a compromise between cost, performance, and protection. IMO the status quo from 2401 is ok for fragment processing. AFAIK there have not been widespread complaints about it, although others on this list would know much better than I. Regards, Mark From owner-ipsec@lists.tislabs.com Thu Feb 26 07:47:13 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QFlCVc071624; Thu, 26 Feb 2004 07:47:12 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19077 Thu, 26 Feb 2004 10:08:36 -0500 (EST) Message-Id: <5.2.0.9.0.20040226101514.0208a8e0@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 26 Feb 2004 10:20:45 -0500 To: Paul Koning , kent@bbn.com From: Mark Duffy Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems Cc: ipsec@lists.tislabs.com In-Reply-To: <16446.125.832000.333536@gargle.gargle.HOWL> References: <5.2.0.9.0.20040225161626.020c34e0@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:19 AM 2/26/2004 -0500, Paul Koning wrote: >I think Mark argued some in both direction (i.e., port selection as a >workaround for poor crypto performance), but I agree with your view. >If a feature is useful, it should be implementable at good >performance. Sorry, I fear that my earlier statement was unclear. My concern is mainly that the standard be conducive to high-performance implementations. I raised the notion of a high-speed implementation, some of whose peers are low speed implementations, as an example of a case where the low speed device could not handle encrypting all the traffic, forcing both the hi and low speed devices to go to port selectors in order to apply encryption more selectively. --Mark From owner-ipsec@lists.tislabs.com Thu Feb 26 08:24:12 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QGOBkN074718; Thu, 26 Feb 2004 08:24:12 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA25034 Thu, 26 Feb 2004 10:46:15 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16446.6031.179644.393418@fireball.acr.fi> Date: Thu, 26 Feb 2004 17:58:07 +0200 From: Tero Kivinen To: Mark Duffy Cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems In-Reply-To: <5.2.0.9.0.20040226095435.0208aa50@email> References: <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040226095435.0208aa50@email> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 6 min X-Total-Time: 6 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark Duffy writes: > >In your case you propably wouldn't have resources to encrypt all > >non-first fragments, thus creating SA for non-first fragments isn't > >a solution for you? > > Not so. I do not see encrypting all fragments as a problem at all. I see I was thinking like the environment like syslog and NFS (both using UDP), where almost all fragmented packets are NFS, and also causing most of the traffic, but the sensetive packets are syslog, which might also get fragmented in some cases. > mandating that security gateways buffer fragments until such time as they > can associate them with the initial fragment as a problem (for high > speed/capacity implementations). The firewalls etc are already doing that on high-speed/capacity implementations, so it is not impossible. The actual processing power needed for the processing is low (one hash-table lookup per fragment per fragmented packet). For non-fragmented packets it does not cause any performance penalty. For most of the fragmented packets do come in order, thus the extra storage requirements can also kept quite low. > Creating a separate SA for non-initial > fragments is acceptable to me, but I believe the wg has rejected this. Yes. > Like almost everything, this is a compromise between cost, performance, and > protection. IMO the status quo from 2401 is ok for fragment > processing. I think 2401 is silent about the issue, meaning that there will be non-interoperable implementations, and I do not think that is acceptable. > AFAIK there have not been widespread complaints about it, > although others on this list would know much better than I. I think the port selectors with tunnel mode are not used that much that people would have noticed. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Thu Feb 26 08:30:28 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QGUSxt075207; Thu, 26 Feb 2004 08:30:28 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26751 Thu, 26 Feb 2004 10:55:45 -0500 (EST) From: "Bora Akyol" To: "'Yoav Nir'" Cc: Subject: Filtering (RE: Traffic selectors, fragments, ICMP messages and security policy problems) Date: Thu, 26 Feb 2004 07:54:02 -0800 Message-ID: <000a01c3fc80$c1931080$070a0a0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The point that I was trying to make is that you can offload filtering on a per port basis from the end node (server in this case) to the network element that it is connected to. For example, if the server is connected to a switch or router, you can install a filter on that port so that the server never even sees the traffic. Of course this only works in a well-controlled environment where we know precisely the network information for the nodes in the network that will communicate with each other. This also allows more legitimate traffic to utilize the link since the filtered traffic never even gets on the link to the server. I do agree with your statements about the other uses of the firewall. Thanks Bora From owner-ipsec@lists.tislabs.com Thu Feb 26 08:48:50 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QGmnnX076156; Thu, 26 Feb 2004 08:48:50 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA29184 Thu, 26 Feb 2004 11:10:19 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Theodore Ts'o" , Hugo Krawczyk , byfraser@cisco.com, canetti , ipsec@lists.tislabs.com From: "David A. McGrew" Subject: Re: [Cfrg] Re: your mail Date: Thu, 26 Feb 2004 11:21:15 -0500 To: cfrg@ietf.org X-Mailer: Apple Mail (2.606) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk CFRGers, is there anyone with another viewpoint about Hugo's proposed changes? If not, we will go ahead and report this back to the IPsec WG. thanks, David On Feb 25, 2004, at 9:18 AM, canetti wrote: > > I concur. > > Ran > > > On Tue, 24 Feb 2004, David A. McGrew wrote: > >> Here is my personal $0.02: the change is well motivated, the solution >> is good (it requires storing two extra keys, which seems not to be a >> big deal), and if the spec can be rev'ed in the next couple of weeks, >> I >> vote to do it. I spoke with several people about this issue who had >> similar sentiments. Other opinions welcome. >> >> David >> > > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg > From owner-ipsec@lists.tislabs.com Thu Feb 26 10:04:10 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QI4AHO079803; Thu, 26 Feb 2004 10:04:10 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17312 Thu, 26 Feb 2004 12:24:05 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <16446.125.832000.333536@gargle.gargle.HOWL> References: <5.2.0.9.0.20040225161626.020c34e0@email> <16446.125.832000.333536@gargle.gargle.HOWL> Date: Thu, 26 Feb 2004 12:35:28 -0500 To: Paul Koning From: Stephen Kent Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems 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 Paul, >So where are we with Tero's previous analysis, which shows that port >selection in the presence of fragmentation can only be done correctly >if you keep cross-fragment state in the SG, i.e., it is expensive at >high speed? I think I disagreed with that argument in a previous message. I have started to write an analysis of these issues, to try to put things in better perspective, since our discussion of this topic has gotten very detailed and hard to follow at times. > >It sounds to me like we have a case of (a) fast and efficient, (b) >support fragments, (c) support port selectors -- pick any TWO. Maybe, but I don't think this is an intrinsic tradeoff. Steve From owner-ipsec@lists.tislabs.com Thu Feb 26 10:30:54 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QIUr5r081646; Thu, 26 Feb 2004 10:30:53 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22343 Thu, 26 Feb 2004 12:46:33 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems In-reply-to: Your message of "Wed, 25 Feb 2004 20:33:59 EST." <20040226013359.GA683@panix.com> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Thu, 26 Feb 2004 12:58:04 -0500 Message-ID: <20939.1077818284@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve and Thor post about situations where there are per-port selectors between two hosts. That does not present a fragmentation problem - you do not need to accumulate fragments to make the decision. The situation where this is necessary is BITS, BITW. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Thu Feb 26 10:50:26 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QIoQ5p082505; Thu, 26 Feb 2004 10:50:26 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28815 Thu, 26 Feb 2004 13:14:21 -0500 (EST) Date: Thu, 26 Feb 2004 13:26:01 -0500 From: Thor Lancelot Simon To: ipsec@lists.tislabs.com Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems Message-ID: <20040226182601.GA24580@panix.com> Reply-To: tls@rek.tjls.com References: <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040224173754.0290be48@email> <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040226095435.0208aa50@email> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.0.20040226095435.0208aa50@email> User-Agent: Mutt/1.4.2.1i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Feb 26, 2004 at 10:13:37AM -0500, Mark Duffy wrote: > > I'm not convinced that is a MUST. One alternative is to leave this choice > to the administrators. I.e. if they want to protect the non-initial > fragments, they do so via SPD rules that match them based on port selectors > of "any" or "opaque". Please, consider the human-factors issues here! I think that this is a terrible idea; inevitably, administrators (who may not reasonably be expected to even truly grasp the concept of IP fragmentation, nor to know what information appears in initial and subsequent fragments!) will be confused by this concept and will inadvertently fail to secure their systems, while believing that they have, in fact, secured them. If we make the rule a MUST, we can emphasize that an implementation MAY implement it by generating and applying additional "any" or "opaque" port selectors to catch fragments. But expecting anyone who wishes to use IPsec and port selectors to understand such protocol details seems an incredibly poor choice. All too often, I think, we design systems by the criterion "Can it be used in a secure fashion" when what we actually care about, in practice, is "*Will* it be used in a secure fashion". Then we go away happy with ourselves for getting the "technical details" right -- except that we've done so only by declaring the difficult issue of whether users of only middling intelligence and knowledge will actually be able to correctly use what we've specified to be out-of-scope. This would be a particularly bad place to make that mistake. From owner-ipsec@lists.tislabs.com Thu Feb 26 11:06:46 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QJ6jvb083312; Thu, 26 Feb 2004 11:06:45 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02199 Thu, 26 Feb 2004 13:26:45 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <200402232232.i1NMW1vf015925@rs9.luxsci.com> References: <200402232232.i1NMW1vf015925@rs9.luxsci.com> Date: Thu, 26 Feb 2004 13:37:12 -0500 To: "William Dixon" From: Stephen Kent Subject: Re: AD requests WG review of final revisions to draft-ietf-ipsec-nat-reqts-06.txt <= 48hrs please Cc: 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 William, I have some concern with the wording in the text. > >" c) Incompatibility between IKE address identifiers and NAT. Where IP > addresses are used as identifiers in Internet Key Exchange > Protocol (IKE) Phase 1 [RFC2409] or Phase 2, modification of the IP >source > or destination addresses by NATs or reverse NATs will result in a > mismatch between the identifiers and the addresses in the IP > header. As described in [RFC2409], IKE implementations are > required to discard such packets. > > In order to avoid use of IP addresses as IKE Phase 1 and Phase 2 > identifiers, userIDs and FQDNs can be used instead. Where user > authentication is desired, an ID type of ID_USER_FQDN can be used, > as described in [RFC2407]. Where machine authentication is > desired, an ID type of ID_FQDN can be used. In either case, > it is necessary to verify that the proposed identifier matches that > enclosed in the certificate if certificates are exchanged in Phase 1. the pki4ipsec WG, and 2401bis, are addressing what is required to establish that the asserted ID in the IKE payload is authorized relative to the authentication data provided. thus the text here seems a bit too restrictive when it says "matches that enclosed in the certificate ..." I'd suggest something along the lines of "In either case, it is necessary to verify that the proposed identifier is authenticated as a result of processing an end-entity certificate, if certificates are exchanged in Phase 1." > > While use of USER_FQDN or FQDN identity types is possible within IKE, > there are usage scenarios (e.g., Security Policy Database (SPD) >entries > describing subnets) that cannot be accommodated this way. > > Since the source address in the Phase 2 identifier > is often used to form a full 5-tuple inbound SA selector, the > destination address, protocol, source port and destination port can > be used in the selector so as not to weaken inbound SA processing." I don't know what this means, precisely. We are clarifying how to use named SPD entries in 2401bis, so that there will be no need to talk about weakening inbound SA processing. >" Note that this is not an incompatibility with IPsec per se, but > rather with the way it is typically implemented. With both AH and > ESP, the receiving host specifies the SPI to use for a given SA, a > choice which is significant only to the receiver. At present, the > combination of Destination IP, SPI, and Security Protocol (AH, ESP) > uniquely identifies a Security Association. This means that the >receiving > host can select SPIs, such that it has one Security Association (SA) >with > (SPI=470, Dest IP=10.2.3.4), and a different Security Association with > (SPI=470, Dest IP=10.3.4.5). The receiving NA(P)T will not be able to > determine which internal host an inbound IPsec packet should be >forwarded > to." I'd suggest using the new text on SA demuxing, from the revised AH & ESP specs as approved by the WG months ago. it clarifies what is required re demuxing for unicast vs. multicast traffic. >" It is also possible for the receiving host to allocate a unique > SPI to each unicast Security Association. In this case, the > Destination IP Address need only be checked to see if it is "any > valid unicast IP for this host", not checked to see if it is the > specific Destination IP address used by the sending host. > Using this technique, the NA(P)T can be assured of a low but > non-zero chance of forwarding packets to the wrong internal host, > even when two or more hosts establish SAs with the same external host. > > This approach is completely backwards compatible, and only requires > the particular receiving host to make a change to its SPI allocation > and IPsec_esp_input() code. However, NA(P)T devices cannot > detect or depend upon this behavior." again, if one uses the new text to which I alluded above, this is very clear. From owner-ipsec@lists.tislabs.com Thu Feb 26 14:46:45 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1QMkiLX095492; Thu, 26 Feb 2004 14:46:44 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA23114 Thu, 26 Feb 2004 17:03:17 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16446.28630.731484.491933@fireball.acr.fi> Date: Fri, 27 Feb 2004 00:14:46 +0200 From: Tero Kivinen To: Stephen Kent Cc: "William Dixon" , Subject: Re: AD requests WG review of final revisions to draft-ietf-ipsec-nat-reqts-06.txt <= 48hrs please In-Reply-To: References: <200402232232.i1NMW1vf015925@rs9.luxsci.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 10 min X-Total-Time: 10 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > > desired, an ID type of ID_FQDN can be used. In either case, > > it is necessary to verify that the proposed identifier matches that > > enclosed in the certificate if certificates are exchanged in Phase 1. > > the pki4ipsec WG, and 2401bis, are addressing what is required to pki4ipsec is just starting now, we do not know what they are going to be producing. The 2401bis refers also to IKEv2, which have its own NAT traversal and there are differences in the IDs allowed etc. This document is now in the RFC editor final step, I do not think we should be modifying this text based on the future work that is still work in progress. > establish that the asserted ID in the IKE payload is authorized > relative to the authentication data provided. thus the text here > seems a bit too restrictive when it says "matches that enclosed in > the certificate ..." I'd suggest something along the lines of "In > either case, it is necessary to verify that the proposed identifier > is authenticated as a result of processing an end-entity certificate, > if certificates are exchanged in Phase 1." The original text works fine for the current IKEv1 usage, and I do not think we should be changing the current text at this step. > > While use of USER_FQDN or FQDN identity types is possible within IKE, > > there are usage scenarios (e.g., Security Policy Database (SPD) > >entries > > describing subnets) that cannot be accommodated this way. > > > > Since the source address in the Phase 2 identifier > > is often used to form a full 5-tuple inbound SA selector, the > > destination address, protocol, source port and destination port can > > be used in the selector so as not to weaken inbound SA processing." > > I don't know what this means, precisely. We are clarifying how to use > named SPD entries in 2401bis, so that there will be no need to talk > about weakening inbound SA processing. We do not want to wait for work in progress, i.e. rfc2401bis. This document refers to rfc2401 which does not have the clarification yet. > I'd suggest using the new text on SA demuxing, from the revised AH & > ESP specs as approved by the WG months ago. it clarifies what is > required re demuxing for unicast vs. multicast traffic. Again this document refers to rfc2401, rfc2402, rfc2406, this it cannot use later AH and ESP documents. If this document would be in normal working group edit phase, then those changes would propably be ok, but as we are now in the rfc editor 48 hours notice time, I do not think we should be doing that kind of changes. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Thu Feb 26 16:14:58 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1R0EvB4000235; Thu, 26 Feb 2004 16:14:57 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16592 Thu, 26 Feb 2004 18:36:54 -0500 (EST) Date: Thu, 26 Feb 2004 18:48:46 -0500 From: Thor Lancelot Simon To: ipsec@lists.tislabs.com Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems Message-ID: <20040226234846.GA24091@panix.com> Reply-To: tls@rek.tjls.com References: <20040226013359.GA683@panix.com> <20939.1077818284@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20939.1077818284@marajade.sandelman.ottawa.on.ca> User-Agent: Mutt/1.4.2.1i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Feb 26, 2004 at 12:58:04PM -0500, Michael Richardson wrote: > > Steve and Thor post about situations where there are per-port selectors > between two hosts. That does not present a fragmentation problem - you Not necessarily; one end may be a gateway for the ultimate destination of the traffic. Think "offload box in front of logging applicance that doesn't have IPsec". I have run into a situation analogous to this, that I can't really describe in detail, that did in fact require both fragmentation and per-port selectors. Strange but true. Thor From owner-ipsec@lists.tislabs.com Fri Feb 27 07:31:43 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1RFVgbc023653; Fri, 27 Feb 2004 07:31:42 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA14552 Fri, 27 Feb 2004 09:45:54 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <200402271022.i1RAM1nb006444@rs9.luxsci.com> References: <200402271022.i1RAM1nb006444@rs9.luxsci.com> Date: Fri, 27 Feb 2004 09:55:30 -0500 To: "William Dixon" From: Stephen Kent Subject: RE: AD requests WG review of final revisions to draft-ietf-ipsec-nat-reqts-06.txt <= 48hrs please Cc: 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 William, Thanks for the response at this late date. Since you indicated a willingness to adopt my suggested text for the first issue, I'm happy going forward. Steve From owner-ipsec@lists.tislabs.com Fri Feb 27 07:31:43 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1RFVg7l023654; Fri, 27 Feb 2004 07:31:42 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13888 Fri, 27 Feb 2004 09:41:34 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <16446.28630.731484.491933@fireball.acr.fi> References: <200402232232.i1NMW1vf015925@rs9.luxsci.com> <16446.28630.731484.491933@fireball.acr.fi> Date: Fri, 27 Feb 2004 09:50:49 -0500 To: Tero Kivinen From: Stephen Kent Subject: Re: AD requests WG review of final revisions to draft-ietf-ipsec-nat-reqts-06.txt <= 48hrs please Cc: "William Dixon" , 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 Tero, You make a good point, that I overlooked, i.e., that the document in question refers to the old set of RFCs. I think that addresses all of my comments but the first. The old set of RFcs does not specify how to verify that a name in the IKE ID is to be verified against a cert, so the text here represents an extrapolation relative to the old RFCs, and should be changed to not impose more specific requirements than what those RFCs stated. Steve From owner-ipsec@lists.tislabs.com Fri Feb 27 13:53:42 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1RLrfD8048854; Fri, 27 Feb 2004 13:53:41 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17631 Fri, 27 Feb 2004 16:10:49 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Fri, 27 Feb 2004 16:28:35 -0500 To: ipsec@lists.tislabs.com From: Karen Seo Subject: Re: IPsec -- new versions of AH and ESP Cc: Barbara Fraser , "Theodore Ts'o" , kivinen@iki.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 Forgot to say that I submitted the new drafts to the IETF secretariat today but they bounced due to the upcoming IETF meeting with a message requesting that I resubmit them on/after March 1. I'll send email when I resubmit them. From owner-ipsec@lists.tislabs.com Sat Feb 28 01:48:03 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1S9m2jX063762; Sat, 28 Feb 2004 01:48:03 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA18085 Sat, 28 Feb 2004 04:08:22 -0500 (EST) Message-ID: <402023CA.306@airespace.com> Date: Tue, 03 Feb 2004 14:42:18 -0800 From: "Scott G. Kelly" Organization: Airespace User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / VPNC CC: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: IANA document References: <5837.1075820257@marajade.sandelman.ottawa.on.ca> <4020041C.8070509@airespace.com> In-Reply-To: X-Enigmail-Version: 0.76.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Feb 2004 22:45:01.0022 (UTC) FILETIME=[5B63EFE0:01C3EAA7] X-AIMC-AUTH: (null) X-AIMC-MAILFROM: owner-ipsec@lists.tislabs.com X-AIMC-AUTH: (null) X-AIMC-MAILFROM: scott@airespace.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Paul, I guess I'm concerned about two eventualities: (1) the expert, perhaps for personal reasons, treats one person's request differently than another's, or (2) the expert, perhaps due to a personal opinion, refuses to allow something that other "experts" view as a good idea. Do you think there are adequate contingencies in place to prevent either of these? Of course, we all believe that if we were the designated expert, such a thing would never occur. But we are all human, so maybe it could at that. I guess that so long as there is some sort of reliable appeal process for such cases, that addresses my concern to some extent. Scott Paul Hoffman / VPNC wrote: > At 12:27 PM -0800 2/3/04, Scott G. Kelly wrote: > >> Michael Richardson wrote: >> >>> >>> I think that the consensus of the WG list is that all values should >>> be a consistent "Expert Review". Please disagree. >> >> >> As you wish :-) This is a difficult question, but given that the IETF >> is a political organization, effectively concentrating this power in >> one individual seems inappropriate. > > > The person is appointed by the IESG. They can be replaced at any time. > >> Personally, I liked the summary of allocation policies you first >> suggested, and thought your rationale was well founded. I think Jari >> raised some reasonable questions, but I don't think a case was made >> for giving the whole kit and kaboodle over to a benevolent dictator. > > > These are assignments to IANA, not protocol additions. > >> There is much to be said for public review and consensus. > > > Exactly right. It is quite reasonable for the IPsec community to ask the > IESG to make sure that the IKEv2 IANA reviewer does everything in > public, and even asks for comments on each action. This is a trivial > task (mailing lists and web sites, you know), and would certainly make > it so that if the reviewer said "no" to something, people who cared > would know immediately to talk to the IESG. > > --Paul Hoffman, Director > --VPN Consortium From isaxjhwgsogbi@yahoo.com Sat Feb 28 14:00:56 2004 Received: from ALAN-XKZWF96GA8 ([24.66.137.166]) by above.proper.com (8.12.11/8.12.8) with SMTP id i1SM0EwE005239; Sat, 28 Feb 2004 14:00:47 -0800 (PST) (envelope-from isaxjhwgsogbi@yahoo.com) Date: Sat, 28 Feb 2004 14:00:47 -0800 (PST) From: isaxjhwgsogbi@yahoo.com Received: from 1.96.102.46 by 24.66.137.166; Sat, 28 Feb 2004 14:57:47 -0700 Message-ID: To: "Scott G. Kelly" Cc: Paul Hoffman / VPNC , Michael Richardson , ipsec@lists.tislabs.com Subject: Re: IANA document In-Reply-To: Your message of "Tue, 03 Feb 2004 14:42:18 PST." <402023CA.306@airespace.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 29 Feb 2004 05:10:52 +0900 Message-Id: <20040228201052.36B267B47@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <402023CA.306@airespace.com>, "Scott G. Kelly" writes: >Hi Paul, > >I guess I'm concerned about two eventualities: (1) the expert, perhaps >for personal reasons, treats one person's request differently than >another's, or (2) the expert, perhaps due to a personal opinion, refuses >to allow something that other "experts" view as a good idea. Do you >think there are adequate contingencies in place to prevent either of these? > >Of course, we all believe that if we were the designated expert, such a >thing would never occur. But we are all human, so maybe it could at >that. I guess that so long as there is some sort of reliable appeal >process for such cases, that addresses my concern to some extent. > You can always appeal to the IESG. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Sun Feb 29 07:07:11 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TF7A83028249; Sun, 29 Feb 2004 07:07:11 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10730 Sun, 29 Feb 2004 09:24:39 -0500 (EST) To: IPsec WG cc: Stephen Kent Subject: Re: ICMP messages and per-port selectors In-Reply-To: Message from Stephen Kent of "Wed, 25 Feb 2004 13:38:59 EST." References: <29398.1077646869@marajade.sandelman.ottawa.on.ca> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Sun, 29 Feb 2004 09:36:16 -0500 Message-ID: <30510.1078065376@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Stephen" == Stephen Kent writes: >> The essential premise of the later documents it that an ICMP >> message such as a port-unreachable should be examined - the >> "quoted" IP packet examined, reversed (src<->dst address/ports) >> and an SA found for it. Stephen> Ultimately we may need to deal with ICMP messages arriving Stephen> via an SA by looking at the "quoted" packet, but I would Stephen> not suggest that one do it literally as described above. I That's fine. Stephen> returned packet and what to do with it. We're not Stephen> guaranteed that the 64-bytes we get with an IPv4 ICMP Stephen> message will have porty fields, for example, so it is not Stephen> always as easy as reversing the addresses and ports to Stephen> match against an extant SA. No, but packets that are too small are probably also *not* useful to the original sender. While a human might guess what they mean from tcpdump, they won't get returned to any application that might be looking for the hint that they should failover, etc. I generally like the idea of a seperate SA, but I don't think it scales very well. I don't see the fast-path argument. The ICMP messages that arrive will fail the fast-path checks - that's fine. Like any packet that failed the fast-path checks, they should then go somewhere to be logged/audited. That's already the slowpath, so no difference. In fact, doing it this way gives us a better guarantee that the fast-path is implemented/tested correctly, since we would regularly be excersizing the slow-path. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQEH43oqHRg3pndX9AQEaAQQA7IFd4l6MhW/yepVyiF5PQxJkDM6StExv sbBp0xDPHwem6X9ZqbfSfeSFKQ+HBCfNF9IOyV3xY1mB3PkrQcZrCjoqlSmmK4iC 872nhdzQUUWf+VFrLYN7zRFfUOaF/vBKoqtQES/5bmRQMrKgywRp/uXkhfxaa3N0 8sI4ETjOntk= =CwA3 -----END PGP SIGNATURE-----