IPsec -- new versions of AH and ESP

From owner-ipsec@lists.tislabs.com Mon Mar 1 08:14: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 i21GE0Nr025860; Mon, 1 Mar 2004 08:14:01 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00375 Mon, 1 Mar 2004 10:16:28 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Fri, 27 Feb 2004 16:16:33 -0500 To: ipsec@lists.tislabs.com From: Karen Seo Subject: 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: multipart/alternative; boundary="============_-1134205902==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1134205902==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Folks, Back on 7/25/03, there was an email on the list from "Salekul Islam" re: "Sliding Window Mechanism using ESN in AH". At the time, we addressed one of the two questions/issues it contained, but overlooked the second, which we just realized in reviewing some old mail. To address this second issue, we have added a line to the pseudo code in the ESN appendix (see below) for both AH and ESP. My apologies for this oversight/delay. Please let us know if you have any questions. Thank you, Karen From appendix A2.2. Determining the Higher Order Bits (Seqh) of the Sequence Number Else Case B If (Seql >= Tl - W + 1) Seqh = Th - 1 If (pass replay check) If (pass integrity check) Set the bit corresponding to Seql Pass packet on Else reject packet Else reject packet Else Added-> Seqh = Th If (Seql <= Tl) If (pass replay check) If (pass integrity check) Set the bit corresponding to Seql Pass packet on Else reject packet Else reject packet Else If (pass integrity check) Tl = Seql (shift bits) Set the bit corresponding to Seql Pass packet on Else reject packet --============_-1134205902==_ma============ Content-Type: text/html; charset="us-ascii" IPsec -- new versions of AH and ESP

Folks,

Back on 7/25/03, there was an email on the list from "Salekul Islam" re: "Sliding Window Mechanism using ESN in AH". At the time, we addressed one of the two questions/issues it contained, but overlooked the second, which we just realized in reviewing some old mail. To address this second issue, we have added a line to the pseudo code in the ESN appendix (see below) for both AH and ESP.

My apologies for this oversight/delay. Please let us know if you have any questions. Thank you,

Karen

From appendix A2.2. Determining the Higher Order Bits (Seqh) of the Sequence Number

        Else                                    Case B
            If (Seql >= Tl - W + 1)
                Seqh = Th - 1
                If (pass replay check)
                    If (pass integrity check)
                        Set the bit corresponding to Seql
                        Pass packet on
                    Else reject packet
                Else reject packet
            Else

Added-> Seqh = Th

                If (Seql <= Tl)
                    If (pass replay check)
                        If (pass integrity check)
                            Set the bit corresponding to Seql
                            Pass packet on
                        Else reject packet
                    Else reject packet
                Else
                    If (pass integrity check)
                        Tl = Seql (shift bits)
                        Set the bit corresponding to Seql
                        Pass packet on

Else reject packet

--============_-1134205902==_ma============-- From ZVYKN@yahoo.com Mon Mar 1 08:31:46 2004 Received: from d53-64-254-232.nap.wideopenwest.com (d53-64-254-232.nap.wideopenwest.com [64.53.232.254]) by above.proper.com (8.12.11/8.12.8) with SMTP id i21GVPXT026791; Mon, 1 Mar 2004 08:31:35 -0800 (PST) (envelope-from ZVYKN@yahoo.com) Date: Mon, 1 Mar 2004 08:31:25 -0800 (PST) From: ZVYKN@yahoo.com Received: from 162.159.86.84 by 64.53.232.254; Tue, 02 Mar 2004 10:33:21 -0600 Message-ID: Date: Mon, 1 Mar 2004 13:27:13 -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 Folks, I've re-submitted these 2 drafts to the IETF secretariat. Note: Given the ongoing IETF, they may not get posted right away. Karen From owner-ipsec@lists.tislabs.com Mon Mar 1 15:24: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 i21NNxkw056141; Mon, 1 Mar 2004 15:24:00 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA19237 Mon, 1 Mar 2004 17:41:34 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Announce: FreeS/WAN Project Ending X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Mon, 01 Mar 2004 17:51:54 -0500 Message-ID: <9059.1078181514@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From http://www.freeswan.org/ending_letter.html -----BEGIN PGP SIGNED MESSAGE----- Dear FreeS/WAN community, After more than five years of active development, the FreeS/WAN project will be coming to an end. The initial goal of the project was ambitious -- to secure the Internet using opportunisitically negotiated encryption, invisible and convenient to the user. (for more, see http://www.freeswan.org/history.html). A secondary goal was to challenge then-current US export regulations, which prohibited the export of strong cryptography (such as triple DES encryption) of US origin or authorship. Since the project's inception, there has been limited success on the political front. After the watershed Bernstein case (see http://www.eff.org/Privacy/Crypto_export/Bernstein_case/ ) US export regulations were relaxed. Since then, many US companies have exported strong cryptography, without seeming restriction other than having to notify the Bureau of Export Administration for tracking purposes. This comfortable situation has perhaps created a false sense of security. The catch? Export regulations are not laws. The US government still reserves the right to change its export regulations on short notice, and there is no facility to challenge them directly in a court of law. This leaves the US crypto community and US Linux distributions in a position which seems safe, but is not legally protected -- where the US government might at any time *retroactively* regulate previously released code, by prohibiting its future export. This is why FreeS/WAN has always been developed outside the US (in Canada and in Greece), and why it has never (to the best of our knowledge) accepted US patches. If FreeS/WAN has neither secured the Internet, nor secured the right of US citizens to export software that could do so, it has still had positive benefit. With version 1.x, the FreeS/WAN team created a mature, well-tested IPsec VPN (Virtual Private Network) product for Linux. The Linux community has relied on it for some time, and it (or a patched variant) has shipped with several Linux distributions. With version 2.x, FreeS/WAN development efforts focussed on increasing the usability of Opportunistic Encryption (OE), IPSec encryption without prearrangement. Configuration was simplified, FreeS/WAN's cryptographic offerings were streamlined, and the team promoted OE through talks and outreach. However, nine months after the release of FreeS/WAN 2.00, OE has not caught on as we'd hoped. The Linux user community demands feature-rich VPNs for corporate clients, and while folks genuinely enjoy FreeS/WAN and its derivatives, the ways they use FreeS/WAN don't seem to be getting us any closer to the project's goal: widespread deployment of OE. For its part, OE requires more testing and community feedback before it is ready to be used without second thought. The project's funders have therefore chosen to withdraw their funding. Anywhere you stop, a little of the road ahead is visible. FreeS/WAN 2.x might have developed further, for example to include ipv6 support. Before the project stops, the team plans to do at least one more release. Release 2.06 will see FreeS/WAN making a late step toward its goal of being a simple, secure OE product with the removal of Transport Mode. This in keeping with one of Neils Fergusson's and Bruce Schneier's security recommendations, in _A Cryptographic Evaluation of IPsec_ (http://www.counterpane.com/ipsec.pdf). 2.06 will also feature KLIPS (FreeS/WAN's Kernel Layer IPsec machinery) changes to faciliate use with the 2.6 kernel series. After Release 2.06, FreeS/WAN code will continue to be available for public use and tinkering. Our website will stay up, and our mailing lists at lists.freeswan.org will continue to provide a forum for users to support one another. We expect that FreeS/WAN and its derivatives will be widely deployed for some time to come. It is our hope that the public will one day be ready for, and demand, transparent, opportunistic encryption. Perhaps then some adventurous folks pick up FreeS/WAN 2.x and continue its development, making the project's original goal a reality. Many thanks to the wonderful folks who've been part of the lists.freeswan.org community over the last few years. Thanks to the developers who've created patches and written HOWTOs. Thanks to the volunteers who've donated Web space and time as system administrators. Thanks to the distributors who've puzzled out the fine points of integrating our software with others'. Finally, thanks to the users who've tested our software, shared interoperation success stories, and given others a helping hand. We couldn't have done it without you. Best Regards, Claudia Schmeing for the Linux FreeS/WAN Project -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQCVAwUBQEOI23DIYXPDEHodAQG1VAP/cy4kK4oRV73YzIokEhElnbg841v/fKN5 v6s//gi/1zfJWVrG2uX9X4ZMi0ebQGFN0J5zr/rhsy2fYcdlDJyaiQvFqyFzzrk9 XUAIYjI+tdB/Fu8StfdutPf29ZdT6igOHI54uH4kYOXtIpj1b/H21SsZEPR+dni3 eZSNoxgDQNo= =iLJC -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Mar 2 00:47:36 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 i228lZPp043215; Tue, 2 Mar 2004 00:47:35 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA15283 Tue, 2 Mar 2004 03:02:40 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <20040226090744.GJ9542@ivan.int-evry.fr> References: <29398.1077646869@marajade.sandelman.ottawa.on.ca> <20040226090744.GJ9542@ivan.int-evry.fr> Date: Tue, 2 Mar 2004 03:13:02 -0500 To: Jean-Jacques Puig 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 At 10:07 +0100 2/26/04, Jean-Jacques Puig wrote: > > > 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). I was thinking about the added IPsec header, and ICMP messages returned via an intermediate gateway (not over an SA). in those cases we will not have access to the protocol or the port fields. but for an ICMP arriving via an SA, we should get the necessary info. the issue here is one of relative performance impacts for ICMP traffic sent or received via an SA. if we don't have a separate SA for such traffic, then I'm not sure we need to add selectors for ICMP type/code values, but we do find ourselves having to afford special treatment for ICMP traffic both on transmission and reception, if we don't segregate this traffic. we have to look at tghe ICMP payload, retrieve addresses and ports and flip them, and use these values plus the protocol to locate the right SA for outbound traffic. if we have an ICMP SA, then we don't have to do that work. we have to do the same sort of work if one of these packets arrives via a non-ICMP SA, to see if the ICMP payload is right for the SA via which it was received. If we have an ICMP-specific SA, then the first pass checks are not special, and the slow path processing takes place after these checks are completed. So, it would seem that use of a dedicated ICMP SA makes transmission easier, but reception processing is complex in both cases. it may be very implementation specific as to whether its easier on steady state processing to segregate the ICMP traffic on its own SA, vs. having every SA be prepared to forward such traffic to an ICMP process. Michael suggested it was a toss up because one would have to hand off packets that failed inbound SA checks for auditing. 2401 does says that this is an auditable event, and suggests minimum data for an audit log. I have a question for implementors: do you audit inbound packets packets that are discarded due to SA check failures, and if so is the audit log entry one that captures packet data (vs. just adding 1 to the "received bad packet via this SA" counter? Steve From owner-ipsec@lists.tislabs.com Tue Mar 2 11:20: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 i22JKR0S007580; Tue, 2 Mar 2004 11:20:28 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23204 Tue, 2 Mar 2004 13:28:51 -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="utf-8" Subject: Ordered and unordered SPD in draft-ietf-ipsec-rfc2401bis-01 Date: Tue, 2 Mar 2004 18:40:24 -0000 Message-ID: <579E83556A36E44EB2945CCE990B31740111DBDA@EUR-MSG-02.europe.corp.microsoft.com> Thread-Topic: Ordered and unordered SPD in draft-ietf-ipsec-rfc2401bis-01 Thread-Index: AcQAhdBHGnby5w5VRLaFddlX3ERCRQ== From: "Michael Roe" To: "Stephen Kent" , "Karen Seo" Cc: X-OriginalArrivalTime: 02 Mar 2004 18:40:25.0838 (UTC) FILETIME=[D3DD90E0:01C40085] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id NAA23201 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Karen, Steve, In draft-ietf-rfc2401bis-01, the description of the processing model is very confusing. The problem is that is keeps switching between two different representations of the SPD: (a) An ordered SPD, which may contain overlapping entries (b) An unordered SPD, which must not contain overlapping entries So we have: [page 16] "The SPD is an ordered database,..." - ordered SPD [page 17] "An SPD is logically divided into three pieces, all of which should be decorrelated ..." - unordered SPD [page 17] "The management interface for the SPD ... MUST support (total) ordering of these entries, as seen via this interface." - ordered SPD It seems as though the description of packet processing is based on an UNordered SPD; implementors may at their discretion implement it either as an ordered or an unordered datastructure; and as a conformance requirement, the management user interface MUST present the user with the appearance of an ordered SPD, using the Annex B algorithm to translate if necessary. I appreciate that technical changes are unwelcome at this point, but I thought I ought to try and explain why the current text is confusing. Cheers, Mike From owner-ipsec@lists.tislabs.com Tue Mar 2 11:20: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 i22JKRGK007578; Tue, 2 Mar 2004 11:20:28 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA24581 Tue, 2 Mar 2004 13:44:57 -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="utf-8" Subject: draft-ietf-rfc2401bis-01: editorial nits Date: Tue, 2 Mar 2004 18:56:08 -0000 Message-ID: <579E83556A36E44EB2945CCE990B31740111DBF1@EUR-MSG-02.europe.corp.microsoft.com> Thread-Topic: draft-ietf-rfc2401bis-01: editorial nits Thread-Index: AcQAiAOOoc/HMgePTwuH3IWHjFxzLg== From: "Michael Roe" To: "Stephen Kent" , "Karen Seo" Cc: "IPsec WG" X-OriginalArrivalTime: 02 Mar 2004 18:56:08.0334 (UTC) FILETIME=[05A30AE0:01C40088] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id NAA24578 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (1) On page 14: "There are two nominal databases in this model ..." "A third database, the Peer Authorization Database ..." Wouldn't it be better to say that there are THREE nominal databases in the model? (Unless you think that the PAD is somehow not part of the model). (2) On page 33: "Note: The source address that appears in the encapsulating tunnel header MUST be the one that was negotiated during the SA establishment process." Should this be the destination address, not the source address? (Dst addr + SPI will uniquely identify the SA unless it's multicast) Cheers! Mike From owner-ipsec@lists.tislabs.com Tue Mar 2 13:52: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 i22LqQ5b017039; Tue, 2 Mar 2004 13:52:27 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05332 Tue, 2 Mar 2004 16:14:43 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <579E83556A36E44EB2945CCE990B31740111DBDA@EUR-MSG-02.europe.corp.microsoft .com> References: <579E83556A36E44EB2945CCE990B31740111DBDA@EUR-MSG-02.europe.corp.microsoft .com> Date: Tue, 2 Mar 2004 16:24:35 -0500 To: "Michael Roe" From: Stephen Kent Subject: Re: Ordered and unordered SPD in draft-ietf-ipsec-rfc2401bis-01 Cc: "Karen Seo" , 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 Mike, Thanks for the feedback. We will go back and try to clarify the description in the places you noted. We may need to refer to the SPD and the decorrelated SPD, with the former as the default unless otherwise qualified, to avoid this confusion. Steve From owner-ipsec@lists.tislabs.com Tue Mar 2 16:39: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 i230delh027457; Tue, 2 Mar 2004 16:39:40 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA17737 Tue, 2 Mar 2004 19:00:55 -0500 (EST) Message-Id: <5.2.0.9.0.20040302190635.020b4430@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 02 Mar 2004 19:13:05 -0500 To: kent@bbn.com, kseo@bbn.com, ipsec@lists.tislabs.com From: Mark Duffy Subject: comments on 2401bis-01 - Transport mode by SGs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I just finished reading through draft-ietf-ipsec-rfc2401bis-01.txt and I found it much clearer than 2401. A big thank you to the authors and other contributors! I have a few questions on the content which I will spread over several messages. Regarding use of transport mode by security gateways in sect. 4.1 it states: A transport mode SA is a security association typically employed between a pair of hosts to provide end-to-end security services. When link (vs. end-to-end) security is desired between two intermediate systems along a path, ... It seems a bit of a misnomer to refer to this as "link security" since it may in fact span multiple links. I propose referring to this instead as "intermediate system to intermediate system security." ... transport mode MAY be used between security gateways or between a security gateway and a host. In the latter case, transport mode may be used to support IP-in-IP [Per96] or GRE tunneling [FaLiHaMeTr00] over transport mode SAs. Even in the former case (SG to SG) shouldn't the use of transport mode be limited to cases where some in-IP tunnelling mechanism is used? But, it might not be IP-and-IP or GRE; it could be L2TP, MPLS-in-IP, etc. So I suggest rewording this passage as follows: A transport mode SA is a security association typically employed between a pair of hosts to provide end-to-end security services. When security is desired between two intermediate systems along a path or between an intermediate and an end system, transport mode MAY be used between security gateways or between a security gateway and a host. In these cases transport mode may be used to secure any sort of in-IP tunneling. In these cases the security gateway(s) are in fact acting as end systems with respect to the in-IP tunnel packets to which transport mode IPsec is applied. There are 2 additional mentions of "link security" later in the section that would also change: Change "... security gateways MAY support a transport mode SA to provide link security for IP traffic" to "... security gateways MAY support a transport mode SA to provide intermediate system to intermediate system security for tunneled IP traffic" Change "If it supports transport mode, that should be used only when the security gateway is acting as a host, e.g., for network management, or to provide link security." to "If it supports transport mode, that should be used only when the security gateway is acting as a host, e.g., for network management, or to provide intermediate system to intermediate system security for tunneled IP traffic." --Mark From owner-ipsec@lists.tislabs.com Tue Mar 2 16:54:47 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 i230skRh028228; Tue, 2 Mar 2004 16:54:47 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA19123 Tue, 2 Mar 2004 19:22:09 -0500 (EST) To: Stephen Kent Cc: "Karen Seo" , "Michael Roe" , ipsec@lists.tislabs.com Subject: Re: Ordered and unordered SPD in draft-ietf-ipsec-rfc2401bis-01 References: <579E83556A36E44EB2945CCE990B31740111DBDA@EUR-MSG-02.europe.corp.microsoft .com> From: Greg Troxel Date: 02 Mar 2004 19:34:10 -0500 In-Reply-To: Message-ID: Lines: 30 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk From: "Michael Roe" In draft-ietf-rfc2401bis-01, the description of the processing model is very confusing. The problem is that is keeps switching between two different representations of the SPD: (a) An ordered SPD, which may contain overlapping entries (b) An unordered SPD, which must not contain overlapping entries I had a similar reaction on reading the draft, but was lame about commenting. Since decorrelation is "just" an optimization, my (unconsidered) preference is to have all the descriptions be in terms of the ordered SPD, perhaps with 'the packet is looked up in the SPD' explained once, and then that definition simply used. The decorrelation presentation could then be descriptive, with the authoritative rules for lookup be in terms of the ordered SPD. There is another, more subtle issue, which is that any time the SPD is changed any data structures derived from the SPD should be updated. While this typically course includes computing a new decorrelated SPD to enable fast lookups, it may also be necessary to revisit extant SAs in implementations that omit SPD lookups when a packet matches an SA, since an SA match may no longer indicate reliably that the packet is allowed by the SPD. Decorrlating the SPD doesn't _cause_ this issue, but I believe it makes it harder to see. -- Greg Troxel From owner-ipsec@lists.tislabs.com Tue Mar 2 17:59: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 i231xj52033495; Tue, 2 Mar 2004 17:59:45 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA23680 Tue, 2 Mar 2004 20:18:50 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: References: <579E83556A36E44EB2945CCE990B31740111DBDA@EUR-MSG-02.europe.corp.microsoft .com> Date: Tue, 2 Mar 2004 20:28:41 -0500 To: Greg Troxel From: Stephen Kent Subject: Re: Ordered and unordered SPD in draft-ietf-ipsec-rfc2401bis-01 Cc: "Karen Seo" , "Michael Roe" , 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 19:34 -0500 3/2/04, Greg Troxel wrote: > From: "Michael Roe" > > In draft-ietf-rfc2401bis-01, the description of the processing > model is very confusing. The problem is that is keeps switching > between two different representations of the SPD: > > (a) An ordered SPD, which may contain overlapping entries > (b) An unordered SPD, which must not contain overlapping entries > >I had a similar reaction on reading the draft, but was lame about >commenting. > >Since decorrelation is "just" an optimization, my (unconsidered) >preference is to have all the descriptions be in terms of the ordered >SPD, perhaps with 'the packet is looked up in the SPD' explained once, >and then that definition simply used. The decorrelation presentation >could then be descriptive, with the authoritative rules for lookup be >in terms of the ordered SPD. the problem is that our new model for processing flow uses caches, which require a decorrelated SPD. Steve From owner-ipsec@lists.tislabs.com Tue Mar 2 18:33: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 i232XiIq035954; Tue, 2 Mar 2004 18:33:45 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA27280 Tue, 2 Mar 2004 21:01:37 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Wed, 3 Mar 2004 11:13:11 +0900 To: Karen Seo , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC 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" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:27 PM -0500 3/1/04, Karen Seo wrote: >I've re-submitted these 2 drafts to the IETF secretariat. Note: >Given the ongoing IETF, they may not get posted right away. As usual, temporary versions of these documents are available at: These files will disappear when the real copies appear in the Internet Drafts directory. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Mar 2 19:23: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 i233Ni9O040475; Tue, 2 Mar 2004 19:23:44 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA01640 Tue, 2 Mar 2004 21:43:33 -0500 (EST) Date: Tue, 2 Mar 2004 21:55:36 -0500 From: Thor Lancelot Simon To: ipsec@lists.tislabs.com Subject: Re: comments on 2401bis-01 - Transport mode by SGs Message-ID: <20040303025536.GA19170@panix.com> Reply-To: tls@rek.tjls.com References: <5.2.0.9.0.20040302190635.020b4430@email> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.0.20040302190635.020b4430@email> User-Agent: Mutt/1.4.2.1i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Mar 02, 2004 at 07:13:05PM -0500, Mark Duffy wrote: > > ... transport mode MAY be used between security > gateways or between a security gateway and a host. In the latter > case, transport mode may be used to support IP-in-IP [Per96] or GRE > tunneling [FaLiHaMeTr00] over transport mode SAs. > > Even in the former case (SG to SG) shouldn't the use of transport mode be > limited to cases where some in-IP tunnelling mechanism is used? But, it > might not be IP-and-IP or GRE; it could be L2TP, MPLS-in-IP, etc. So I > suggest rewording this passage as follows: Why forbid two security gateways from using transport mode to protect other SG-to-SG traffic? From owner-ipsec@lists.tislabs.com Tue Mar 2 20:23: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 i234NCpg046162; Tue, 2 Mar 2004 20:23:13 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA07649 Tue, 2 Mar 2004 22:44:10 -0500 (EST) Message-Id: <5.2.0.9.0.20040302214818.0208c5b8@email> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 02 Mar 2004 22:55:18 -0500 To: kent@bbn.com, kseo@bbn.com, ipsec@lists.tislabs.com From: Mark Duffy Subject: comments on 2401bis-01 - SPD, selectors Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In draft-ietf-ipsec-rfc2401bis-01.txt sect. 4.4.1 (re the SPD): 1. On page 17 it states: "The second choice [bypass] refers to traffic that is allowed to pass without additional IPsec protection." If an inbound packet is received with IPsec protection (e.g ESP) but the SPD calls for "bypass" for that packet, should it be accepted or dropped? I have always understood that it should be dropped. But either way the document should make it explicit. 2. On page 18: "If IPsec processing is specified for an entry, a "populate from packet" (PFP) flag may be asserted for one or more of the selector types in the SPD entry. If present, the flag applies to all selectors of the indicated type in the outbound element of the pair." What is meant by "all selectors of the indicated type"? Does that mean, all values in the lists of ranges for the given selector type? What pair is being referred to? Would it be accurate to rephrase that second sentence as "... If asserted for a given selector type, the flag indicates that the SA to be created should take its value for that selector type from the value in the packet; otherwise the SA should takes its value(s) for that selector from the value(s) in the SPD entry." Shouldn't it further state that, in the non-PFP case, the actual selectors negotiated may be narrower than those in the SPD entry, depending on the SPD policy of the peer? In sect 4.4.2 (selectors): 3. On p. 20: "Also, note that the source/destination port selectors may be labeled as "OPAQUE" to accommodate situations where these fields are inaccessible because of prior encryption or due to packet fragmentation." If the "prior encryption" here refers a packet that is an IPsec packet then the Next Layer Protocol for the packet will be AH or ESP and port selectors are *undefined* (not opaque) for such a packet, right? This looks like a holdover from 2401 where AH and ESP were not considered next layer (transport) headers. Can we change "because of prior encryption or due to packet fragmentation" to just "due to packet fragmentation"? 4. On p. 20: "Note: In a non-initial fragment, port values will not be available. If the SA requires a non-OPAQUE port value, an arriving fragment MUST be discarded." If the SA "requires" (allows) the port value ANY, shouldn't that match non-initial fragments? In section 6 on p. 38 it states: "fragments not containing port numbers may only match rules having port selectors of OPAQUE or "ANY". Either p. 20 or p. 38 should be changed. IMO either ANY or OPAQUE should match non-initial fragments, so I'd suggest changing p. 20 to read "Note: In a non-initial fragment, port values will not be available. If the SA requires a non-OPAQUE port value other than ANY, an arriving fragment MUST be discarded." As an editorial comment, since selectors appear in both SPD and SAD entries, I would further reword that to not be SA-centric: "Note: In a non-initial fragment, port values will not be available. If a port selector specifies a non-OPAQUE value other than ANY, it cannot match packets which are non-initial fragments." Thanks, Mark From owner-ipsec@lists.tislabs.com Tue Mar 2 20:46: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 i234kE4w048530; Tue, 2 Mar 2004 20:46:14 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA10259 Tue, 2 Mar 2004 23:08:05 -0500 (EST) Message-Id: <5.2.0.9.0.20040302230102.0208dc50@localhost> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 02 Mar 2004 23:20:01 -0500 To: tls@rek.tjls.com, ipsec@lists.tislabs.com From: Mark Duffy Subject: Re: comments on 2401bis-01 - Transport mode by SGs In-Reply-To: <20040303025536.GA19170@panix.com> References: <5.2.0.9.0.20040302190635.020b4430@email> <5.2.0.9.0.20040302190635.020b4430@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:55 PM 3/2/2004 -0500, Thor Lancelot Simon wrote: >On Tue, Mar 02, 2004 at 07:13:05PM -0500, Mark Duffy wrote: > > > > ... transport mode MAY be used between security > > gateways or between a security gateway and a host. In the latter > > case, transport mode may be used to support IP-in-IP [Per96] or GRE > > tunneling [FaLiHaMeTr00] over transport mode SAs. > > > > Even in the former case (SG to SG) shouldn't the use of transport mode be > > limited to cases where some in-IP tunnelling mechanism is used? But, it > > might not be IP-and-IP or GRE; it could be L2TP, MPLS-in-IP, etc. So I > > suggest rewording this passage as follows: > >Why forbid two security gateways from using transport mode to protect >other SG-to-SG traffic? By SG-to-SG traffic, do you mean packets whose source/dest addresses are the SGs? I didn't mean to forbid any of that. I think that WRT the non-tunneled traffic, the SG is acting as a host and the use of transport mode for this is described a few paragraphs further on in 2401bis. Or, I can propose new text that explicitly includes that. My points were that 1) SG-to-SG and SG-to-host should have the same rules applied to them, and 2) the type of in-IP tunneling doesn't matter and should not be limited to IP-in-IP and GRE. As far as applying transport mode to transit packets (whose source/dest are not the SGs) 2401 proscribed that, I believe 2401bis-01 intends to proscribe it, and I had no intention of changing that. --Mark From owner-ipsec@lists.tislabs.com Tue Mar 2 22:09: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 i23690Vn057327; Tue, 2 Mar 2004 22:09:00 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA18475 Wed, 3 Mar 2004 00:30:24 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <2EFAFC388B9C4C48B581846AEC20A020016CA81E@scexch01.arc.com> References: <2EFAFC388B9C4C48B581846AEC20A020016CA81E@scexch01.arc.com> Date: Wed, 3 Mar 2004 00:25:29 -0500 To: "Charlet, Ricky" From: Stephen Kent Subject: RE: Ordered and unordered SPD in draft-ietf-ipsec-rfc2401bis-01 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 20:01 -0800 3/2/04, Charlet, Ricky wrote: >Howdy, > > Could the flow cashing and decorrelated SPD be implementation >suggestions? > > I feel implementers should have the freedom to achieve the >effect of an ordered SPD search in what ever internal mechanism they >choose. Flow cashing, while a very good idea for processing efficiency, >is not an interoperability issue. And it may not be the only or even the >best idea for processing efficiency (though I can't think of others). > > RFC 1812, section 5.2 hinted at a cashing suggestion but only >required implementers to achieve the effect of a search algorithm while >specifically allowing impelmentors to innovate (see section 5.2.1). I >think similar language could be used here. There is no requirement to decorrelate the SPD or to cache, and the text says that. I just found it much easier to describe the flow based on the use of caches, which implied decorrleation. Steve From owner-ipsec@lists.tislabs.com Tue Mar 2 23:51: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 i237pJ2S000287; Tue, 2 Mar 2004 23:51:20 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA00357 Wed, 3 Mar 2004 02:14:24 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <579E83556A36E44EB2945CCE990B31740111DBF1@EUR-MSG-02.europe.corp.microsoft .com> References: <579E83556A36E44EB2945CCE990B31740111DBF1@EUR-MSG-02.europe.corp.microsoft .com> Date: Wed, 3 Mar 2004 02:25:52 -0500 To: "Michael Roe" From: Stephen Kent Subject: Re: draft-ietf-rfc2401bis-01: editorial nits Cc: "Karen Seo" , "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 At 18:56 +0000 3/2/04, Michael Roe wrote: >(1) On page 14: "There are two nominal databases in this model ..." > "A third database, the Peer Authorization Database ..." > > Wouldn't it be better to say that there are THREE nominal >databases in the model? > (Unless you think that the PAD is somehow not part of the model). just a "plus or minus 1 bug" :-) we'll fix this text to say three in both places. > >(2) On page 33: "Note: The source address that appears in the encapsulating > tunnel header MUST be the one that was negotiated during the SA >establishment > process." > > Should this be the destination address, not the source address? >(Dst addr + SPI > will uniquely identify the SA unless it's multicast) this text is a carry over from 2401. in retrospect, it should be removed. for a tunnel mode SA, the outer addresses have no security significance in terms of the receiver, for unicast traffic. for multicast we now say that either or both of these addresses might be used for demuxing, and in that case it is important to ensure consistency over the lifetime of the SA. so we might add a note to that effect. it also was observed that one might perform some form of address-based filtering on inbound IPsec traffic prior to demuxing, and that would also motivate using the same source address, but such filtering is outside the scope of IPsec. Steve From owner-ipsec@lists.tislabs.com Wed Mar 3 00:19: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 i238J4WU009885; Wed, 3 Mar 2004 00:19:04 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA04433 Wed, 3 Mar 2004 02:46:33 -0500 (EST) From: "Mujinga, M" To: Subject: IPSec on tunneling mechanisms Date: Wed, 3 Mar 2004 09:58:01 +0200 Message-ID: <000501c400f5$495dd450$0a0b60c0@damba> 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.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Folks I'm new in this IPSec business, but question is. Can IPSec secure traffic on IPv6 being tunnelled over the IPv4 networks, e.g. using 6to4 etc? I'm considering doing research in that area. Cheers From owner-ipsec@lists.tislabs.com Wed Mar 3 00:21: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 i238Lf0q010907; Wed, 3 Mar 2004 00:21:41 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA04720 Wed, 3 Mar 2004 02:48:35 -0500 (EST) Message-Id: <200403030800.i2380ZSj060736@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Michael Roe" cc: "Stephen Kent" , "Karen Seo" , "IPsec WG" Subject: Re: draft-ietf-rfc2401bis-01: editorial nits In-reply-to: Your message of Tue, 02 Mar 2004 18:56:08 GMT. <579E83556A36E44EB2945CCE990B31740111DBF1@EUR-MSG-02.europe.corp.microsoft.com> Date: Wed, 03 Mar 2004 09:00:35 +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: (2) On page 33: "Note: The source address that appears in the encapsulating tunnel header MUST be the one that was negotiated during the SA establishment process." Should this be the destination address, not the source address? => even fixed (:-) this statement is a bit too strong for MOBIKE which is supposed to allow to update the address(es). I can't propose a better wording but obviously one is needed... Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Wed Mar 3 01:11: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 i239BYUD030150; Wed, 3 Mar 2004 01:11:36 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA11192 Wed, 3 Mar 2004 03:29:39 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <200403030800.i2380ZSj060736@givry.rennes.enst-bretagne.fr> References: <200403030800.i2380ZSj060736@givry.rennes.enst-bretagne.fr> Date: Wed, 3 Mar 2004 03:23:02 -0500 To: Francis Dupont From: Stephen Kent Subject: Re: draft-ietf-rfc2401bis-01: editorial nits Cc: "Michael Roe" , "Karen Seo" , "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 At 9:00 +0100 3/3/04, Francis Dupont wrote: > In your previous mail you wrote: > > (2) On page 33: "Note: The source address that appears in the encapsulating > tunnel header MUST be the one that was negotiated during the SA > establishment process." > > Should this be the destination address, not the source address? > >=> even fixed (:-) this statement is a bit too strong for MOBIKE which >is supposed to allow to update the address(es). I can't propose a better >wording but obviously one is needed... > >Thanks > >Francis.Dupont@enst-bretagne.fr Francis, Maybe you didn't see my response, which said that the text was outdated and that there need not be such a constraint. Steve From owner-ipsec@lists.tislabs.com Wed Mar 3 03: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 i23BeT8G051861; Wed, 3 Mar 2004 03:40:29 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA04093 Wed, 3 Mar 2004 06:02:13 -0500 (EST) Message-Id: <200403031114.i23BEASj061283@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Mujinga, M" cc: ipsec@lists.tislabs.com Subject: Re: IPSec on tunneling mechanisms In-reply-to: Your message of Wed, 03 Mar 2004 09:58:01 +0200. <000501c400f5$495dd450$0a0b60c0@damba> Date: Wed, 03 Mar 2004 12:14:10 +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: I'm new in this IPSec business, but question is. Can IPSec secure traffic on IPv6 being tunnelled over the IPv4 networks, e.g. using 6to4 etc? => RFC 2401 and its comming revision both allow IPv6 over IPv4 (or IPv4 over IPv6) in tunnel mode but many implementations for reasons I don't understand (laziness? unfounded fear?) don't support this... I'm considering doing research in that area. => there is nothing to search (in the technical domain :-). Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Wed Mar 3 03:42: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 i23BgAki051933; Wed, 3 Mar 2004 03:42:10 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA05266 Wed, 3 Mar 2004 06:10:38 -0500 (EST) Message-Id: <200403031122.i23BMYSj061315@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Stephen Kent cc: "Michael Roe" , "Karen Seo" , "IPsec WG" Subject: Re: draft-ietf-rfc2401bis-01: editorial nits In-reply-to: Your message of Wed, 03 Mar 2004 03:23:02 EST. Date: Wed, 03 Mar 2004 12:22:34 +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: Maybe you didn't see my response, => I didn't see your response in time... Sorry. which said that the text was outdated and that there need not be such a constraint. => so my concern is solved! Thanks Francis.Dupont@enst-bretagne.fr PS: I know many IPsec implementations which spuriously check the external source address... IMHO the document should not be changed (i.e., no SHOULD NOT) but this point should be checked in interoperability tests. From owner-ipsec@lists.tislabs.com Wed Mar 3 06:24:41 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 i23EOeaa064030; Wed, 3 Mar 2004 06:24:41 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA26187 Wed, 3 Mar 2004 08:48:19 -0500 (EST) From: Charles Lynn To: "Mujinga, M" Cc: Subject: Re: IPSec on tunneling mechanisms In-Reply-To: <000501c400f5$495dd450$0a0b60c0@damba> Message-Id: <20040303135941.865E32051E@wolfe.bbn.com> Date: Wed, 3 Mar 2004 08:59:41 -0500 (EST) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Can IPSec secure traffic on IPv6 being tunnelled over the IPv4 > networks, e.g. using 6to4 etc? Yes. 2401[bis] uses examples of IPv4 tunneled in IPv4 and IPv6 tunneled in IPv6 for ease of description, but the other two cases, IPv4 in IPv6 and IPv6 in IPv4 are also valid. IPsec can be used in all four scenarios, and IKEv2 can setup the appropriate SAs. Charlie From owner-ipsec@lists.tislabs.com Wed Mar 3 09:35: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 i23HZRfA079587; Wed, 3 Mar 2004 09:35:28 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11757 Wed, 3 Mar 2004 11:55:25 -0500 (EST) Message-Id: <5.2.0.9.0.20040303095222.02090aa0@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 03 Mar 2004 10:24:46 -0500 To: kent@bbn.com, kseo@bbn.com, ipsec@lists.tislabs.com From: Mark Duffy Subject: comments on 2401bis-01 - SAD, pkt processing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In draft-ietf-ipsec-rfc2401bis-01.txt sect. 4.4.3 (re the SAD) on p. 23: Note that implementations SHOULD be able to handle having the counters at the ends of an SA get out of synch, ... (md) Given that the counters will almost certainly be out of sync, shouldn't that SHOULD be a MUST? ----- In sect. 5 on p. 28 re IP Traffic Processing: But, if the SPD entries are first decorrelated, then the resulting entries can safely be cached, and each cached entry will map to an SA (or multiple SAs if "populate from packet" (PFP) is specified), or indicate that matching traffic should be bypassed or discarded, appropriately. (md) Rather than 'or multiple SAs if "populate from packet" (PFP) is specified' wouldn't it be 'or multiple SAs if "populate from packet" (PFP) is specified or if the SAs have been negotiated with a peer whose SPD requires finer SA granularity' ----- In sect 5.2 (inbound traffic processing) on p. 36 list item 2: 2. The packet is examined and demuxed into one of three categories: - If the packet appears to be IPsec protected and it is addressed to this device, an attempt is made to map it to an active SA via the SAD. - Traffic not addressed to this device is directed to BYPASS/DISCARD lookup. If multiple SPDs are employed, the tag assigned to the packet in step 1 is used to select the appropriate SPD-I (and cache) to search. - ICMP traffic directed to this device is directed to "unprotected" ICMP processing (see Section 6). (md) Packets addressed to this device that are not AH, ESP, or ICMP are not accounted for. E.g. IKE. I think they should be added to the second category as so: - Traffic not addressed to this device, or addressed to this device and not AH, ESP, or ICMP, is directed to BYPASS/DISCARD lookup. If multiple SPDs are employed, the tag assigned to the packet in step 1 is used to select the appropriate SPD-I (and cache) to search. A similar change would be needed 2 paragraphs further down in list item 3b. Thanks, Mark From owner-ipsec@lists.tislabs.com Wed Mar 3 09:51:09 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 i23Hp8kj081032; Wed, 3 Mar 2004 09:51:08 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14036 Wed, 3 Mar 2004 12:19:53 -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="utf-8" Subject: Decorrelated SPD and IKEv2 traffic selectors Date: Wed, 3 Mar 2004 17:31:53 -0000 Message-ID: <579E83556A36E44EB2945CCE990B31740111E096@EUR-MSG-02.europe.corp.microsoft.com> Thread-Topic: Decorrelated SPD and IKEv2 traffic selectors Thread-Index: AcQBRWjtGjKFVH9dSnCayQZiIrazig== From: "Michael Roe" To: X-OriginalArrivalTime: 03 Mar 2004 17:31:54.0754 (UTC) FILETIME=[6BE1AE20:01C40145] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id MAA14024 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Now that the architecture defines two forms of the SPD (an ordered one and a decorrelated one), there is the question of which one is used by IKEv2 to construct traffic selectors. draft-ietf-ipesec-ikev2-12 doesn't seem to say. Suppose the ordered SPD looks like this: Local Remote Protocol Action X Y ICMP (type=146..147) Apply (ESP, transport, DES3CBC, HMAC-MD5) [Prefix Solicitation] X * ICMP BYPASS X * UDP (port=IKE) BYPASS X Y MobilityHeader Apply (ESP, transport, DES3CBC, HMAC-MD4) [Binding Update] X * MobilityHeader Apply (ESP, tunnel, DES3CBC, HMAC-MD5) [Return Routability] X * * Apply (ESP, tunnel, NULL, HMAC-MD5) (See draft-ietf-mobileip-mipv6-ha-ipsec-0 for why this is an interesting case...) When it's been decorrelated, it looks something like this (my apologies if I've made a mistake - I did this by hand): Local Remote Protocol Action X Y ICMP BYPASS X Y ICMP (type=0..146) BYPASS X Y ICMP (type=148..255) BYPASS X * UDP (port=IKE) BYPASS X Y ICMP (type=146..147) Apply (ESP, transport, DES3CBC, HMAC-MD5) X Y MobilityHeader Apply (ESP, tunnel, DES3CBC, HMAC-MD5) X Y MobilityHeader } Apply (ESP, tunnel, DES3CBC, HMAC-MD5) X * UDP (port=0..499) } X * UDP (port=501..65535)} X * UDP (port=OPAQUE) } X * 2..16 } Apply (ESP, tunnel, NULL, HMAC-MD5) X * 18..134 } X * 136..255 } When IKEv2 negotiates the last SA, which selectors does it send? A single selector with protocol=0 (representing the ANY in the ordered SPD), or the long list of selectors in the decorrelated SPD? (I make it 255 selectors, because ranges of protocol numbers aren't supported in an IKEv2 transport selector) Thanks! Mike PS. If that list of selectors makes the IKE packet larger than the MTU it will get fragmented using IPv6 end-to-end fragmentation, which means that the port number is OPAQUE in non-initial fragments... From owner-ipsec@lists.tislabs.com Wed Mar 3 10:04: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 i23I41IM081957; Wed, 3 Mar 2004 10:04:01 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA15049 Wed, 3 Mar 2004 12:30:40 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 3 Mar 2004 12:49:23 -0500 To: Paul Hoffman / VPNC From: Karen Seo Subject: Re: IPsec -- new versions of AH and ESP Cc: ipsec@lists.tislabs.com, 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 Thank you! >At 1:27 PM -0500 3/1/04, Karen Seo wrote: >>I've re-submitted these 2 drafts to the IETF secretariat. Note: >>Given the ongoing IETF, they may not get posted right away. > >As usual, temporary versions of these documents are available at: > > > > >These files will disappear when the real copies appear in the >Internet Drafts directory. > >--Paul Hoffman, Director >--VPN Consortium From owner-ipsec@lists.tislabs.com Wed Mar 3 10:07: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 i23I7Wfv082281; Wed, 3 Mar 2004 10:07:32 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA15532 Wed, 3 Mar 2004 12:36:23 -0500 (EST) Message-ID: <003c01c40147$bc5eed20$861167c0@adithya> From: "Mohan Parthasarathy" To: "Charles Lynn" , "Mujinga, M" Cc: References: <20040303135941.865E32051E@wolfe.bbn.com> Subject: Re: IPSec on tunneling mechanisms Date: Wed, 3 Mar 2004 09:48:28 -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 > > Can IPSec secure traffic on IPv6 being tunnelled over the IPv4 > > networks, e.g. using 6to4 etc? > > Yes. 2401[bis] uses examples of IPv4 tunneled in IPv4 and IPv6 > tunneled in IPv6 for ease of description, but the other two cases, > IPv4 in IPv6 and IPv6 in IPv4 are also valid. IPsec can be used > in all four scenarios, and IKEv2 can setup the appropriate SAs. > One related question.. Can we use a single pair of SA for IPv4 tunneled in IPv4 and IPv4 tunneled in IPv6 traffic between the two hosts i.e the traffic selector needs to specify a mix of IPv4 and IPv6 selectors ? RFC 3554 is not very clear about this though it supports ID_LIST concept. Though IKev2 supports multiple traffic selectors in a single negotiation, it does not allow the mix. In section 2.9, Two TS payloads appear in each of the messages in the exchange that creates a CHILD_SA pair. Each TS payload contains one or more Traffic Selectors. Each Traffic Selector consists of an address range (IPv4 or IPv6), a port range, and an IP protocol ID. Is that right ? thanks mohan > Charlie From owner-ipsec@lists.tislabs.com Wed Mar 3 13:57: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 i23Lvvh0099608; Wed, 3 Mar 2004 13:57:58 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA28244 Wed, 3 Mar 2004 16:08:12 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <579E83556A36E44EB2945CCE990B31740111E096@EUR-MSG-02.europe.corp.microsoft .com> References: <579E83556A36E44EB2945CCE990B31740111E096@EUR-MSG-02.europe.corp.microsoft .com> Date: Wed, 3 Mar 2004 16:19:44 -0500 To: "Michael Roe" From: Stephen Kent Subject: Re: Decorrelated SPD and IKEv2 traffic selectors 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 Mike, I think the latest version says that when you decorrelate, you keep the decorrelated entries linked together, so that when you match any individual entry, you grab all of the other entries that were created due to decorrelation. we need to do this so that the externally visible operation is identical to what would happen w/o decorrelation, at least so far as the number of SAs that are created and what traffic flows over each SA. We said this in terms of creating SPD-cache and SAD entries, but the same thing shoud be done for IKE interactions. Perhaps it would be better, for IKE, to keep the original SPD entry as well, and pass that back to IKE for use in negotiation. steve From owner-ipsec@lists.tislabs.com Wed Mar 3 18:02: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 i2422vLO015146; Wed, 3 Mar 2004 18:02:57 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA22210 Wed, 3 Mar 2004 20:25:18 -0500 (EST) In-Reply-To: References: <579E83556A36E44EB2945CCE990B31740111E096@EUR-MSG-02.europe.corp.microsoft .com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <00DC9A54-6D7C-11D8-A92C-000393CDFD1A@electric-loft.org> Content-Transfer-Encoding: 7bit Cc: "Michael Roe" , From: Derrell Piper Subject: Re: Decorrelated SPD and IKEv2 traffic selectors Date: Thu, 4 Mar 2004 10:33:56 +0900 To: Stephen Kent X-Mailer: Apple Mail (2.612) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think you want to explicitly state in 2401bis that it is the uncorrelated entry that's passed up to IKE. IKE doesn't need to know anything about the decorrelation but if someone were to choose to pass up the decorrelated entry, we'd have an interoperability issue. Derrell On Mar 4, 2004, at 6:19 AM, Stephen Kent wrote: > I think the latest version says that when you decorrelate, you keep > the decorrelated entries linked together, so that when you match any > individual entry, you grab all of the other entries that were created > due to decorrelation. we need to do this so that the externally > visible operation is identical to what would happen w/o decorrelation, > at least so far as the number of SAs that are created and what traffic > flows over each SA. We said this in terms of creating SPD-cache and > SAD entries, but the same thing shoud be done for IKE interactions. > Perhaps it would be better, for IKE, to keep the original SPD entry as > well, and pass that back to IKE for use in negotiation. From owner-ipsec@lists.tislabs.com Wed Mar 3 18:20: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 i242KQdE016152; Wed, 3 Mar 2004 18:20:29 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA24212 Wed, 3 Mar 2004 20:45:56 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <5.2.0.9.0.20040302190635.020b4430@email> References: <5.2.0.9.0.20040302190635.020b4430@email> Date: Wed, 3 Mar 2004 20:55:59 -0500 To: Mark Duffy From: Stephen Kent Subject: Re: comments on 2401bis-01 - Transport mode by SGs 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 19:13 -0500 3/2/04, Mark Duffy wrote: >I just finished reading through draft-ietf-ipsec-rfc2401bis-01.txt >and I found it much clearer than 2401. A big thank you to the >authors and other contributors! > >I have a few questions on the content which I will spread over >several messages. > >Regarding use of transport mode by security gateways in sect. 4.1 it states: > > A transport mode SA is a security association typically employed > between a pair of hosts to provide end-to-end security services. When > link (vs. end-to-end) security is desired between two intermediate > systems along a path, ... > >It seems a bit of a misnomer to refer to this as "link security" >since it may in fact span multiple links. I propose referring to >this instead as "intermediate system to intermediate system >security." yes, "link" is not a great term, and we can consider something more descriptive. but because the access controls are applied only to what will be the outer header, we need to reinforce the fact that using transport mode here is very different. > ... transport mode MAY be used between security > gateways or between a security gateway and a host. In the latter > case, transport mode may be used to support IP-in-IP [Per96] or GRE > tunneling [FaLiHaMeTr00] over transport mode SAs. > >Even in the former case (SG to SG) shouldn't the use of transport >mode be limited to cases where some in-IP tunnelling mechanism is >used? But, it might not be IP-and-IP or GRE; it could be L2TP, >MPLS-in-IP, etc. So I suggest rewording this passage as follows: > > A transport mode SA is a security association typically employed > between a pair of hosts to provide end-to-end security services. When > security is desired between two intermediate systems along a path or > between an intermediate and an end system, transport mode MAY be used > between security gateways or between a security gateway and a host. > In these cases transport mode may be used to secure any sort of > in-IP tunneling. In these cases the security gateway(s) are in fact > acting as end systems with respect to the in-IP tunnel packets to > which transport mode IPsec is applied. not sure I am complete happy with the wording, but I get your point. we just gave examples for the sorts of tunneling that might be used. it was not intended to be a proscriptive list. > >There are 2 additional mentions of "link security" later in the >section that would also change: > >Change > "... security gateways MAY support a transport mode SA to provide >link security for IP traffic" >to > "... security gateways MAY support a transport mode SA to provide >intermediate system to intermediate system security for tunneled IP >traffic" > >Change > "If it supports transport mode, that should be used only when the >security gateway is acting as a host, e.g., for network management, >or to provide link security." >to > "If it supports transport mode, that should be used only when the >security gateway is acting as a host, e.g., for network management, >or to provide intermediate system to intermediate system security >for tunneled IP traffic." thanks. Steve From owner-ipsec@lists.tislabs.com Wed Mar 3 18:20: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 i242KTlg016153; Wed, 3 Mar 2004 18:20:32 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA24236 Wed, 3 Mar 2004 20:46:04 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <00DC9A54-6D7C-11D8-A92C-000393CDFD1A@electric-loft.org> References: <579E83556A36E44EB2945CCE990B31740111E096@EUR-MSG-02.europe.corp.microsoft .com> <00DC9A54-6D7C-11D8-A92C-000393CDFD1A@electric-loft.org> Date: Wed, 3 Mar 2004 20:54:17 -0500 To: Derrell Piper From: Stephen Kent Subject: Re: Decorrelated SPD and IKEv2 traffic selectors Cc: "Michael Roe" , 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:33 +0900 3/4/04, Derrell Piper wrote: >I think you want to explicitly state in 2401bis that it is the >uncorrelated entry that's passed up to IKE. IKE doesn't need to >know anything about the decorrelation but if someone were to choose >to pass up the decorrelated entry, we'd have an interoperability >issue. > >Derrell OK, we'll make that addition to the text. Steve From owner-ipsec@lists.tislabs.com Wed Mar 3 21:39: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 i245dFrl031215; Wed, 3 Mar 2004 21:39:15 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA07659 Wed, 3 Mar 2004 23:54:50 -0500 (EST) Message-Id: <200403040506.i2456lSj064185@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Mohan Parthasarathy" cc: "Charles Lynn" , "Mujinga, M" , ipsec@lists.tislabs.com Subject: Re: IPSec on tunneling mechanisms In-reply-to: Your message of Wed, 03 Mar 2004 09:48:28 PST. <003c01c40147$bc5eed20$861167c0@adithya> Date: Thu, 04 Mar 2004 06:06:47 +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: One related question.. Can we use a single pair of SA for IPv4 tunneled in IPv4 and IPv4 tunneled in IPv6 traffic between the two hosts i.e the traffic selector needs to specify a mix of IPv4 and IPv6 selectors ? => perhaps you mean IPv4 tunneled in IPv4 and IPv6 tunneled in IPv4? In your description the multiple version addresses are external IKE doesn't know to do this kind of things... Though IKev2 supports multiple traffic selectors in a single negotiation, it does not allow the mix. In section 2.9, => I don't read the section 2.9 this way. Two TS payloads appear in each of the messages in the exchange that creates a CHILD_SA pair. Each TS payload contains one or more Traffic Selectors. Each Traffic Selector consists of an address range (IPv4 or IPv6), a port range, and an IP protocol ID. => so where is the constraint? Is that right ? => I believe it isn't. But note that an implementation can support only one TS... Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu Mar 4 10:22:12 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 i24IMBMY057463; Thu, 4 Mar 2004 10:22:11 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23161 Thu, 4 Mar 2004 12:31:19 -0500 (EST) Message-ID: <001c01c4020f$f059d2c0$6401a8c0@adithya> From: "Mohan Parthasarathy" To: "Francis Dupont" Cc: "Charles Lynn" , "Mujinga, M" , References: <200403040506.i2456lSj064185@givry.rennes.enst-bretagne.fr> Subject: Re: IPSec on tunneling mechanisms Date: Thu, 4 Mar 2004 09:41:34 -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 > In your previous mail you wrote: > > One related question.. Can we use a single pair of SA for IPv4 > tunneled in IPv4 and IPv4 tunneled in IPv6 traffic between the two > hosts i.e the traffic selector needs to specify a mix of IPv4 and IPv6 > selectors ? > > => perhaps you mean IPv4 tunneled in IPv4 and IPv6 tunneled in IPv4? Yes. > In your description the multiple version addresses are external > IKE doesn't know to do this kind of things... > Correct. Assume that the external addresses that IKE runs on are IPv4 and i just want a mix of traffic selectors. > Though IKev2 supports multiple traffic selectors in a single > negotiation, it does not allow the mix. In section 2.9, > > => I don't read the section 2.9 this way. > > Two TS payloads appear in each of the messages in the exchange that > creates a CHILD_SA pair. Each TS payload contains one or more Traffic > Selectors. Each Traffic Selector consists of an address range (IPv4 > or IPv6), a port range, and an IP protocol ID. > > => so where is the constraint? > It says IPv4 or IPv6 above. > Is that right ? > > => I believe it isn't. But note that an implementation can support only > one TS... > Sure. But i don't think the spec is clear on this issue. -mohan > Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Fri Mar 5 04:10: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 i25CAQWH096582; Fri, 5 Mar 2004 04:10:27 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA11288 Fri, 5 Mar 2004 06:19:01 -0500 (EST) Date: Fri, 5 Mar 2004 13:31:03 +0200 Message-Id: <200403051131.i25BV3ji006208@burp.tkv.asdf.org> From: Markku Savela To: ipsec@lists.tislabs.com In-reply-to: <5.2.0.9.0.20040226095435.0208aa50@email> (message from Mark Duffy on Thu, 26 Feb 2004 10:13:37 -0500) Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems References: <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040226095435.0208aa50@email> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've been thinking about this a bit more, and my conclusion is: If you want to apply IPSEC on fragments, and you want to use port selectors then There is no way out of it: then at least one of the IPSEC implementations MUST buffer ALL fragments before it can release any packets to the stacks fragment assembly. Consider mobile node M communicating with server S behing the security gateway SG. Assume S fragments some data going towards M, and assume there is a port specific policy: PORT=A, send in clear PORT=B, use ESP PORT=C, use AH M <==== IPSEC ====> SG <---> S First SG: It has been said it is not acceptable to require SG to do packet assembly before the IPSEC. If so, then NONE of the selectors affecting the M <-> SG traffic can have port selectors. If you have port selectors, you cannot let the packets through until you see the first fragment. (You don't know whether port is A or B). - one argument against SG doing the assembly has been: not all fragments may arrive to the same SG. Only one of the SG's sees the first fragment. => The other can never do the correct thing and fragments are dropped after some timeout or until buffer space runs out. Communication fails randomly, exactly the same way as if SG's were required to assemble packets. - because there is no ordering requirements for fragments, the SG must be prepared to buffer all fragments. It might as well do packet assembly. (Linux sends the first fragment as last!) Second M: When receiving fragments protected with ESP from SG, the IPSEC MUST buffer and hold all fragments until it receives the first fragment. Only then it can check whether the port was A (if port is not A, the packet must be dropped, even if the ESP transformation succeeded). After receiving the first fragment, IPSEC can release the buffered fragments to the fragment assebly of the IP stack. However, it needs to remember the port state to be able to check any remaining fragments. How long it needs to keep this state? Might be just easier to do the assembly in IPSEC, to be sure. IPSEC on M must also hold all clear fragments in similar way, until it knows what IPSEC was to be applied. Additional consideration: the fragments will have SRC=S, DST=M. IPSEC must buffer those too, until it knows the port. It cannot let them through, because someone could send fake fragments to poison the stacks fragment assembly (and place some attack data into supposedly secured communication using port B or C). So, if SG allows IPSEC on fragments, then IPSEC on M needs to be prepared to buffer full packet. It has to implement same safeguards against dos attacks as the standard fragment assembly. An attacker may find some holes by forcing IPSEC to forget some state, and then sending some tailored fake fragments? I guess, supporting port selectors and IPSEC on fragments is possible, but it's lot of work and requires almost full replication of the fragment assemble within IPSEC. It might be hard to make the thing actually secure against attacks. Conclusion: Do not allow port selectors and IPSEC on fragments at same time. Then, the buffering requirements disappear and it is possible to check security of each packet and fragment alone. From owner-ipsec@lists.tislabs.com Fri Mar 5 08:06: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 i25G6218013378; Fri, 5 Mar 2004 08:06:02 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14055 Fri, 5 Mar 2004 10:28:30 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200403040506.i2456lSj064185@givry.rennes.enst-bretagne.fr> References: <200403040506.i2456lSj064185@givry.rennes.enst-bretagne.fr> Date: Fri, 5 Mar 2004 10:10:50 -0500 To: Francis Dupont From: Stephen Kent Subject: Re: IPSec on tunneling mechanisms Cc: "Mohan Parthasarathy" , "Charles Lynn" , "Mujinga, M" , 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 6:06 +0100 3/4/04, Francis Dupont wrote: > In your previous mail you wrote: > > One related question.. Can we use a single pair of SA for IPv4 > tunneled in IPv4 and IPv4 tunneled in IPv6 traffic between the two > hosts i.e the traffic selector needs to specify a mix of IPv4 and IPv6 > selectors ? i think that under IKEv2 and 2401bis, you could define the necessary selectors to accommodate both classes of traffic on a single pair of SAs, through multiple selector payloads. Steve From owner-ipsec@lists.tislabs.com Fri Mar 5 09:42: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 i25HgHMD020640; Fri, 5 Mar 2004 09:42:17 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27895 Fri, 5 Mar 2004 12:02:20 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.2.0.9.0.20040303095222.02090aa0@email> References: <5.2.0.9.0.20040303095222.02090aa0@email> Date: Fri, 5 Mar 2004 12:13:55 -0500 To: Mark Duffy From: Stephen Kent Subject: Re: comments on 2401bis-01 - SAD, pkt processing Cc: kseo@bbn.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 10:24 -0500 3/3/04, Mark Duffy wrote: >In draft-ietf-ipsec-rfc2401bis-01.txt sect. 4.4.3 (re the SAD) on p. 23: > > Note that > implementations SHOULD be able to handle having the counters at > the ends of an SA get out of synch, ... > >(md) Given that the counters will almost certainly be out of sync, >shouldn't that SHOULD be a MUST? seems like a reasonable change to me, since we all agree that the counters will likely not be in perfect sync. >----- > >In sect. 5 on p. 28 re IP Traffic Processing: > > But, if the SPD entries are first > decorrelated, then the resulting entries can safely be cached, and > each cached entry will map to an SA (or multiple SAs if "populate > from packet" (PFP) is specified), or indicate that matching traffic > should be bypassed or discarded, appropriately. > >(md) Rather than 'or multiple SAs if "populate from packet" (PFP) is >specified' wouldn't it be 'or multiple SAs if "populate from packet" >(PFP) is specified or if the SAs have been negotiated with a peer >whose SPD requires finer SA granularity' Actually my text was wrong, because a cached entry maps to exactly one SA, although the original entry might result in multiple SAs, e.g., because of PFP. We'll change the text accordingly. >----- > >In sect 5.2 (inbound traffic processing) on p. 36 list item 2: > > 2. The packet is examined and demuxed into one of three categories: > - If the packet appears to be IPsec protected and it is addressed > to this device, an attempt is made to map it to an active SA > via the SAD. > - Traffic not addressed to this device is directed to > BYPASS/DISCARD lookup. If multiple SPDs are employed, the tag > assigned to the packet in step 1 is used to select the > appropriate SPD-I (and cache) to search. > - ICMP traffic directed to this device is directed to > "unprotected" ICMP processing (see Section 6). > >(md) Packets addressed to this device that are not AH, ESP, or ICMP >are not accounted for. E.g. IKE. I think they should be added to >the second category as so: > - Traffic not addressed to this device, or addressed to this device > and not AH, ESP, or ICMP, is directed to BYPASS/DISCARD lookup. > If multiple SPDs are employed, the tag assigned to the packet in > step 1 is used to select the appropriate SPD-I (and cache) to > search. >A similar change would be needed 2 paragraphs further down in list item 3b. Good point. we do require IKE traffic to have an explicit bypass entry in the SPD. We will change the text accordingly. Steve From owner-ipsec@lists.tislabs.com Fri Mar 5 09:42: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 i25HgQru020657; Fri, 5 Mar 2004 09:42:27 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27901 Fri, 5 Mar 2004 12:02:25 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.2.0.9.0.20040302214818.0208c5b8@email> References: <5.2.0.9.0.20040302214818.0208c5b8@email> Date: Fri, 5 Mar 2004 12:13:46 -0500 To: Mark Duffy From: Stephen Kent Subject: Re: comments on 2401bis-01 - SPD, selectors Cc: kseo@bbn.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 22:55 -0500 3/2/04, Mark Duffy wrote: >In draft-ietf-ipsec-rfc2401bis-01.txt sect. 4.4.1 (re the SPD): > >1. On page 17 it states: "The second choice [bypass] refers to >traffic that is allowed to pass without additional IPsec protection." > If an inbound packet is received with IPsec protection (e.g ESP) >but the SPD calls for "bypass" for that packet, should it be >accepted or dropped? I have always understood that it should be >dropped. But either way the document should make it explicit. a packet will be dropped if it fails to match the selectors defined for the SA via which it was received. the text above also will have the word "additional" removed. >2. On page 18: "If IPsec processing is specified for an entry, a >"populate from packet" (PFP) flag may be asserted for one or more of >the selector types in the SPD entry. If present, the flag applies to >all selectors of the indicated type in the outbound element of the >pair." > What is meant by "all selectors of the indicated type"? Does that >mean, all values in the lists of ranges for the given selector type? >What pair is being referred to? the selector types are: S/D IP address, protocol, S/D port, ICMP type/Code, and the mobility header stuff. the "pair" referred to here was notion of separate inbound vs. outbound directional entries. later discussion showed that this is not an appropriate distinction for SPD-S entries. > Would it be accurate to rephrase that second sentence as "... If >asserted for a given selector type, the flag indicates that the SA >to be created should take its value for that selector type from the >value in the packet; otherwise the SA should takes its value(s) for >that selector from the value(s) in the SPD entry." yes, that's a better way to say it. > Shouldn't it further state that, in the non-PFP case, the actual >selectors negotiated may be narrower than those in the SPD entry, >depending on the SPD policy of the peer? yes, I think that is consistent with IKE v2, and we can add text to that effect. >In sect 4.4.2 (selectors): > >3. On p. 20: "Also, note that the source/destination port >selectors may be labeled as "OPAQUE" to accommodate situations where >these fields are inaccessible because of prior encryption or due to >packet fragmentation." > If the "prior encryption" here refers a packet that is an IPsec >packet then the Next Layer Protocol for the packet will be AH or ESP >and port selectors are *undefined* (not opaque) for such a packet, >right? This looks like a holdover from 2401 where AH and ESP were >not considered next layer (transport) headers. Can we change >"because of prior encryption or due to packet fragmentation" to just >"due to packet fragmentation"? yes, it was a holdover from 2401 and needs to be updated. > >4. On p. 20: "Note: In a non-initial fragment, port values will >not be available. If the SA requires a non-OPAQUE port value, an >arriving fragment MUST be discarded." > If the SA "requires" (allows) the port value ANY, shouldn't that >match non-initial fragments? In section 6 on p. 38 it states: >"fragments not containing port numbers may only match rules having >port selectors of OPAQUE or "ANY". Either p. 20 or p. 38 should be >changed. > IMO either ANY or OPAQUE should match non-initial fragments, so >I'd suggest changing p. 20 to read "Note: In a non-initial >fragment, port values will not be available. If the SA requires a >non-OPAQUE port value other than ANY, an arriving fragment MUST be >discarded." I hope to send out a memo on fragmentation issues soon. one issue is whether to keep OPAQUE, which should be distinct from ANY. If so, then ANY would not match missing port fields, e.g., in a non-initial fragment. >As an editorial comment, since selectors appear in both SPD and SAD >entries, I would further reword that to not be SA-centric: "Note: >In a non-initial fragment, port values will not be available. If a >port selector specifies a non-OPAQUE value other than ANY, it cannot >match packets which are non-initial fragments." good point. Steve From owner-ipsec@lists.tislabs.com Fri Mar 5 09:46: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 i25Hk10b020845; Fri, 5 Mar 2004 09:46:04 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29206 Fri, 5 Mar 2004 12:12:29 -0500 (EST) Message-ID: <002101c402d6$bb0c5120$861167c0@adithya> From: "Mohan Parthasarathy" To: "Francis Dupont" , "Stephen Kent" Cc: "Charles Lynn" , "Mujinga, M" , References: <200403040506.i2456lSj064185@givry.rennes.enst-bretagne.fr> Subject: Re: IPSec on tunneling mechanisms Date: Fri, 5 Mar 2004 09:24: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 > At 6:06 +0100 3/4/04, Francis Dupont wrote: > > In your previous mail you wrote: > > > > One related question.. Can we use a single pair of SA for IPv4 > > tunneled in IPv4 and IPv4 tunneled in IPv6 traffic between the two > > hosts i.e the traffic selector needs to specify a mix of IPv4 and IPv6 > > selectors ? > > i think that under IKEv2 and 2401bis, you could define the necessary > selectors to accommodate both classes of traffic on a single pair of > SAs, through multiple selector payloads. > I am reading section 2.9 of the latest IKEv2 draft. Two TS payloads appear in each of the messages in the exchange that creates a CHILD_SA pair. Each TS payload contains one or more Traffic Selectors. Each Traffic Selector consists of an address range (IPv4 or IPv6), a port range, and an IP protocol ID. In support of the scenario described in section 1.1.3, an initiator may request that the responder assign an IP address and tell the initiator what it is. The "Two" in the first line points to Tsi and Tsr. And each of them contain either IPv4 or IPv6 as mentioned above. So, it is not clear to me as where one can mix IPv4 and IPv6 selectors in a single IPsec SA negotiation. Could you clarify ? thanks mohan > > Steve From owner-ipsec@lists.tislabs.com Fri Mar 5 12:41: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 i25KfhiQ031081; Fri, 5 Mar 2004 12:41:43 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21840 Fri, 5 Mar 2004 15:01:16 -0500 (EST) From: "Bora Akyol" To: Subject: SPD Cache in 2401bis Date: Fri, 5 Mar 2004 12:13:20 -0800 Message-ID: <004a01c402ee$4dbefa10$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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Is it possible to remove all the discussion on SPD-cache out of RFC2401bis and into an informational RFC? The discussion of the cache within the text even pre-faced with the caveat given that the cache is optional detracts from the clarity of the text IMHO. This will leave the SPD as ordered and will also take all discussion of the decorrelation of the SPD out of 2401bis as well. The caching idea has merit by itself and can be either put in an appendix altogether or removed and put into an informational RFC. As far speed of implementation is concerned, there are widely available TCAMs that can do millions of look-ups per second in an ordered database using a 5-tuple or a 6-tuple lookup. Regards, Bora From owner-ipsec@lists.tislabs.com Fri Mar 5 13: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 i25Lwrfe034816; Fri, 5 Mar 2004 13:58:53 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02331 Fri, 5 Mar 2004 16:21:36 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <004a01c402ee$4dbefa10$070a0a0a@amer.cisco.com> References: <004a01c402ee$4dbefa10$070a0a0a@amer.cisco.com> Date: Fri, 5 Mar 2004 16:13:10 -0500 To: "Bora Akyol" From: Stephen Kent Subject: Re: SPD Cache in 2401bis 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 12:13 -0800 3/5/04, Bora Akyol wrote: >Is it possible to remove all the discussion on SPD-cache out of >RFC2401bis and into an informational RFC? no. >The discussion of the cache within the text even pre-faced >with the caveat given that the cache is optional detracts >from the clarity of the text IMHO. I've worked on this for a long time and I find that it is much easier to discuss steady-state processing using caches. This is especially true for discussing how PFP works, for example. We had a cache-less description in 2401. As primary author of that document I can tell you that the one aspect of 2401 that resulted in the most e-mail questions was a direct result of not having a cache-based model. Steve From owner-ipsec@lists.tislabs.com Fri Mar 5 14:32: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 i25MW8B5036881; Fri, 5 Mar 2004 14:32:09 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06939 Fri, 5 Mar 2004 16:56:53 -0500 (EST) From: "Bora Akyol" To: "'Stephen Kent'" Cc: Subject: RE: SPD Cache in 2401bis Date: Fri, 5 Mar 2004 14:08:49 -0800 Message-ID: <005d01c402fe$70397920$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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks, in this case, can we at least include in sections of the text in the packet processing path an alternate description of what an implementation would do if they were not using a cache. For example, page 28-29, items 2 and 3a/b. Since the cache is optional, don't you think we should have a description of the non-optional ordered SPD case? Bora > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Friday, March 05, 2004 1:13 PM > To: Bora Akyol > Cc: ipsec@lists.tislabs.com > Subject: Re: SPD Cache in 2401bis > > > At 12:13 -0800 3/5/04, Bora Akyol wrote: > >Is it possible to remove all the discussion on SPD-cache out of > >RFC2401bis and into an informational RFC? > > no. > > >The discussion of the cache within the text even pre-faced with the > >caveat given that the cache is optional detracts from the clarity of > >the text IMHO. > > I've worked on this for a long time and I find that it is much easier > to discuss steady-state processing using caches. This is especially > true for discussing how PFP works, for example. We had a cache-less > description in 2401. As primary author of that document I can tell > you that the one aspect of 2401 that resulted in the most e-mail > questions was a direct result of not having a cache-based model. > > > Steve > From owner-ipsec@lists.tislabs.com Sat Mar 6 05:48:02 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 i26Dm1OP055972; Sat, 6 Mar 2004 05:48:02 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA22651 Sat, 6 Mar 2004 07:57:20 -0500 (EST) To: kent@bbn.com Cc: bora@cisco.com, ipsec@lists.tislabs.com Subject: Re: SPD Cache in 2401bis In-Reply-To: Your message of "Fri, 5 Mar 2004 16:13:10 -0500" References: X-Mailer: Cue version 0.6 (040210-0635/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040306130924.A1D2958@coconut.itojun.org> Date: Sat, 6 Mar 2004 22:09:24 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >Is it possible to remove all the discussion on SPD-cache out of > >RFC2401bis and into an informational RFC? > no. i think 2401bis is talking about implementation details too much. i agree with bora that SPD-cache issues should be a separate document. there could be multiple ways we can implement SPD lookup portion (and we should be allowed to implement in various ways), for instance. SPD lookup portion won't impact interoperability. wire format part will. therefore, i believe 2401bis should be spiltted into two document: - a document which concentrate onto the on-wire protocol only (mostly references to ESPv3 and AHv2) - a document which concentrate onto implementation specifics (how SPD lookup has to be done, how it should be cached, tunnel mode and transport mode) itojun From owner-ipsec@lists.tislabs.com Sat Mar 6 08:48:04 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 i26Gm3N3064122; Sat, 6 Mar 2004 08:48:04 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05724 Sat, 6 Mar 2004 11:07:45 -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: <16457.64017.269211.415572@fireball.acr.fi> Date: Sat, 6 Mar 2004 18:19:29 +0200 From: Tero Kivinen To: "Mohan Parthasarathy" Cc: "Francis Dupont" , "Stephen Kent" , "Charles Lynn" , "Mujinga, M" , Subject: Re: IPSec on tunneling mechanisms In-Reply-To: <002101c402d6$bb0c5120$861167c0@adithya> References: <200403040506.i2456lSj064185@givry.rennes.enst-bretagne.fr> <002101c402d6$bb0c5120$861167c0@adithya> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 13 min X-Total-Time: 12 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mohan Parthasarathy writes: > I am reading section 2.9 of the latest IKEv2 draft. > > Two TS payloads appear in each of the messages in the exchange that > creates a CHILD_SA pair. Each TS payload contains one or more Traffic > Selectors. Each Traffic Selector consists of an address range (IPv4 > or IPv6), a port range, and an IP protocol ID. In support of the > scenario described in section 1.1.3, an initiator may request that > the responder assign an IP address and tell the initiator what it is. > > The "Two" in the first line points to Tsi and Tsr. And each of them contain > either IPv4 or IPv6 as mentioned above. So, it is not clear to me as where > one can mix IPv4 and IPv6 selectors in a single IPsec SA negotiation. Could > you clarify ? Read the text. It says that there are 2 TS payloads (TSi, and TSr). Each TS payload contains one or more traffic selectors. Each traffic selector contains either IPv4 or IPv6 range, but as each TS payload can contain multiple traffic selectors the TS payloads can have both IPv4 and IPv6 ranges. I.e. TSi = { Traffic selector proto = any, port = 0 - 65535 ipv4 range = 10.0.0.1 - 10.0.0.255 } { Traffic selector proto = any, port = 0 - 65535 ipv6 range = 2001::1 - 2001::ffff:ffff:ffff:ffff } TSr = { Traffic selector proto = any, port = 0 - 65535 ipv4 range = 10.0.0.1 - 10.0.0.255 } { Traffic selector proto = any, port = 0 - 65535 ipv6 range = 2001::1 - 2001::ffff:ffff:ffff:ffff } and the actual packet would be (next payload of prev packet is 44): 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Nxt Payload=45!C! RESERVED ! Payload Length = 64 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! # of TSs = 2 ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! TS Type = 7 !IP Proto ID = 0| Selector Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Port = 0 | End Port = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Starting Address = 10.0.0.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ending Address = 10.0.0.255 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! TS Type = 8 !IP Proto ID = 0| Selector Length = 40 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Port = 0 | End Port = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Starting Address = 2001:0000: | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0000:0000: | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0000:0000: | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0000:0001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ending Address = 2001:0000: | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0000:0000: | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ffff:ffff: | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ffff:ffff | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Nxt Payload=??!C! RESERVED ! Payload Length = 64 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! # of TSs = 2 ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! TS Type = 7 !IP Proto ID = 0| Selector Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Port = 0 | End Port = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Starting Address = 10.0.0.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ending Address = 10.0.0.255 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! TS Type = 8 !IP Proto ID = 0| Selector Length = 40 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Port = 0 | End Port = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Starting Address = 2001:0000: | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0000:0000: | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0000:0000: | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0000:0001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ending Address = 2001:0000: | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0000:0000: | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ffff:ffff: | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ffff:ffff | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Sun Mar 7 11:16: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 i27JGnqM025592; Sun, 7 Mar 2004 11:16:50 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA20134 Sun, 7 Mar 2004 13:29:21 -0500 (EST) Message-ID: <006501c40473$cf3120b0$6401a8c0@adithya> From: "Mohan Parthasarathy" To: "Tero Kivinen" Cc: "Francis Dupont" , "Stephen Kent" , "Charles Lynn" , "Mujinga, M" , References: <200403040506.i2456lSj064185@givry.rennes.enst-bretagne.fr><002101c402d6$bb0c5120$861167c0@adithya> <16457.64017.269211.415572@fireball.acr.fi> Subject: Re: IPSec on tunneling mechanisms Date: Sun, 7 Mar 2004 10:41:31 -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 Tero, Thanks for your detailed clarification. Somehow, i managed to read it wrongly all the times ! -thanks mohan > Mohan Parthasarathy writes: > > I am reading section 2.9 of the latest IKEv2 draft. > > > > Two TS payloads appear in each of the messages in the exchange that > > creates a CHILD_SA pair. Each TS payload contains one or more Traffic > > Selectors. Each Traffic Selector consists of an address range (IPv4 > > or IPv6), a port range, and an IP protocol ID. In support of the > > scenario described in section 1.1.3, an initiator may request that > > the responder assign an IP address and tell the initiator what it is. > > > > The "Two" in the first line points to Tsi and Tsr. And each of them contain > > either IPv4 or IPv6 as mentioned above. So, it is not clear to me as where > > one can mix IPv4 and IPv6 selectors in a single IPsec SA negotiation. Could > > you clarify ? > > Read the text. It says that there are 2 TS payloads (TSi, and TSr). > Each TS payload contains one or more traffic selectors. Each traffic > selector contains either IPv4 or IPv6 range, but as each TS payload > can contain multiple traffic selectors the TS payloads can have both > IPv4 and IPv6 ranges. > > I.e. > > TSi = > { Traffic selector > proto = any, port = 0 - 65535 > ipv4 range = 10.0.0.1 - 10.0.0.255 } > { Traffic selector > proto = any, port = 0 - 65535 > ipv6 range = 2001::1 - 2001::ffff:ffff:ffff:ffff } > TSr = > { Traffic selector > proto = any, port = 0 - 65535 > ipv4 range = 10.0.0.1 - 10.0.0.255 } > { Traffic selector > proto = any, port = 0 - 65535 > ipv6 range = 2001::1 - 2001::ffff:ffff:ffff:ffff } > > and the actual packet would be (next payload of prev packet is 44): > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Nxt Payload=45!C! RESERVED ! Payload Length = 64 ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! # of TSs = 2 ! RESERVED ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! TS Type = 7 !IP Proto ID = 0| Selector Length = 16 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Start Port = 0 | End Port = 65535 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Starting Address = 10.0.0.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ending Address = 10.0.0.255 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! TS Type = 8 !IP Proto ID = 0| Selector Length = 40 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Start Port = 0 | End Port = 65535 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Starting Address = 2001:0000: | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0000:0000: | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0000:0000: | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0000:0001 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ending Address = 2001:0000: | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0000:0000: | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ffff:ffff: | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ffff:ffff | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Nxt Payload=??!C! RESERVED ! Payload Length = 64 ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! # of TSs = 2 ! RESERVED ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! TS Type = 7 !IP Proto ID = 0| Selector Length = 16 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Start Port = 0 | End Port = 65535 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Starting Address = 10.0.0.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ending Address = 10.0.0.255 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! TS Type = 8 !IP Proto ID = 0| Selector Length = 40 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Start Port = 0 | End Port = 65535 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Starting Address = 2001:0000: | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0000:0000: | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0000:0000: | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0000:0001 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ending Address = 2001:0000: | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0000:0000: | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ffff:ffff: | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ffff:ffff | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > -- > kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Sun Mar 7 12:20: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 i27KKHbG029633; Sun, 7 Mar 2004 12:20:17 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26189 Sun, 7 Mar 2004 14:44:08 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <20040306130924.A1D2958@coconut.itojun.org> References: <20040306130924.A1D2958@coconut.itojun.org> Date: Sun, 7 Mar 2004 11:55:54 -0800 To: itojun@itojun.org (Jun-ichiro itojun Hagino), kent@bbn.com From: Paul Hoffman / VPNC Subject: Re: SPD Cache in 2401bis Cc: bora@cisco.com, ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Reading through the current draft, I have to agree with Itojun and Bora. It's hard to say that the cache is optional when it appears in MUST statements, such as in section 5.1. There should either be parallel discussions (simpler ones with the cache, more complicated ones without the cache), or the main document should describe only the mandatory features, and an appendix or different document describe the improvements you get with the optional cache. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Sun Mar 7 12:26: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 i27KQqni029906; Sun, 7 Mar 2004 12:26:52 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27043 Sun, 7 Mar 2004 14:54:50 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References:

Date: Sun, 7 Mar 2004 12:07:02 -0800 To: "David A. McGrew" From: Paul Hoffman / VPNC Subject: Re: [Cfrg] Re: your mail Cc: ipsec@lists.tislabs.com, cfrg@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Nearly two weeks ago, David A. McGrew said: >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. Did that report (with specific changes) actually get sent to the IPsec WG? If not, could the CFRG do that soon? The IKEv2 document is stalled waiting for this. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Sun Mar 7 22:24:28 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 i286ORxA076347; Sun, 7 Mar 2004 22:24:27 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA20355 Mon, 8 Mar 2004 00:48:17 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message Subject: Question with Using AES CCM Mode With IPsec ESP MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Date: Mon, 8 Mar 2004 14:02:53 +0800 Message-ID: Thread-Topic: Question with Using AES CCM Mode With IPsec ESP thread-index: AcP/z4F6YHSo5HHgRzq/AJMeeziUugAjUXgg From: =?big5?B?SmltbXkgSHNpZWggKMHCqN2n+Ck=?= To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id AAA20347 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Mr. Housley: After reading "Using AES CCM Mode With IPsec ESP ," I have two questions about constructing AAD. 1. Is the "64-bit Extended Sequence Number" transmitted? Or only "Low 32-bit of Extended Sequence Number" is transmitted. 2. In "IP Encapsulating Security Payload (ESP) ," it is mentioned that the high 32-bit of Extended Sequence Number is placed after the "Next Header" field. The Location for high 32-bit of Extended Sequence Number is differently defined in and . Could you comment on this? Thank you very much. Jimmy Hsieh From owner-ipsec@lists.tislabs.com Mon Mar 8 07:32: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 i28FWFSN077261; Mon, 8 Mar 2004 07:32:15 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16607 Mon, 8 Mar 2004 09:48:55 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com (Unverified) Message-Id: In-Reply-To: <20040306130924.A1D2958@coconut.itojun.org> References: <20040306130924.A1D2958@coconut.itojun.org> Date: Mon, 8 Mar 2004 09:32:21 -0500 To: itojun@itojun.org (Jun-ichiro itojun Hagino) From: Stephen Kent Subject: Re: SPD Cache in 2401bis 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 10:09 PM +0900 3/6/04, Jun-ichiro itojun Hagino wrote: > > >Is it possible to remove all the discussion on SPD-cache out of >> >RFC2401bis and into an informational RFC? >> no. > > i think 2401bis is talking about implementation details too much. > i agree with bora that SPD-cache issues should be a separate document. > there could be multiple ways we can implement SPD lookup portion > (and we should be allowed to implement in various ways), for instance. > SPD lookup portion won't impact interoperability. wire format part > will. > > therefore, i believe 2401bis should be spiltted into two document: > - a document which concentrate onto the on-wire protocol only > (mostly references to ESPv3 and AHv2) > - a document which concentrate onto implementation specifics > (how SPD lookup has to be done, how it should be cached, tunnel mode > and transport mode) > >itojun I appreciate the suggestion that 2401/2401bis has more detail than some folks would like. However, a protocol spec is not just a matter of the bits on the wire format; it also includes a model (e.g., a state machine) for how one processes outbound and inbound traffic for the protocol. Thus it is essential that 2401bis include such a model. On that basis I have to disagree with your suggestion on restructuring. Steve From owner-ipsec@lists.tislabs.com Mon Mar 8 09:01: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 i28H1dTR082803; Mon, 8 Mar 2004 09:01:40 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26246 Mon, 8 Mar 2004 11:23:39 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: <20040306130924.A1D2958@coconut.itojun.org> Date: Mon, 8 Mar 2004 11:31:40 -0500 To: Paul Hoffman / VPNC From: Stephen Kent Subject: Re: SPD Cache in 2401bis Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:55 AM -0800 3/7/04, Paul Hoffman / VPNC wrote: >Reading through the current draft, I have to agree with Itojun and >Bora. It's hard to say that the cache is optional when it appears in >MUST statements, such as in section 5.1. There should either be >parallel discussions (simpler ones with the cache, more complicated >ones without the cache), or the main document should describe only >the mandatory features, and an appendix or different document >describe the improvements you get with the optional cache. > >--Paul Hoffman, Director >--VPN Consortium paul, Fair criticism. It would be ideal if we could provide parallel descriptions, or relegate one to an appendix, but it is additional, non-trivial work. In 2401 we did not do an adequate job of describing how to handle some cases, e.g., named SPD entries and PFP entries. Even for simple SPD entries the notion of going back to the SPD to lookup each outbound packet is clearly something that scales poorly for bigger SPDs and/or high speeds. (Of course all of this is only a concern for BITS/BITW/SG implementations. native host implementations have an intrinsic form of caching anyway.) A motivation for introducing caching was to offer a model that scales better, as well as describing a simpler model. Decorrelation is needed for caching. For named SPD entries, there is a need to create a new entry to match outbound traffic, and if we create it in the SPD, we have to address the question of exactly where it belongs relative to the named entry that gave rise to the transient entry. The processing model for IPsec is not a proscription for implementation. It gives details of one way to implement IPsec. The intent is that a compliant implementation should behave in an identical manner, as viewed by the IPsec peer and by the user/admin, no matter how it is implemented locally. We need at least one model to provide a reference, and it is preferable if the model is as simple as possible, to make it easy to describe and to understand. Steve From owner-ipsec@lists.tislabs.com Mon Mar 8 12:03: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 i28K3W51095755; Mon, 8 Mar 2004 12:03:33 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA08725 Mon, 8 Mar 2004 14:15:19 -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: <16460.51481.931296.945354@fireball.acr.fi> Date: Mon, 8 Mar 2004 21:27:21 +0200 From: Tero Kivinen To: Stephen Kent Cc: Paul Hoffman / VPNC , ipsec@lists.tislabs.com Subject: Re: SPD Cache in 2401bis In-Reply-To: References: <20040306130924.A1D2958@coconut.itojun.org> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 10 min X-Total-Time: 9 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > In 2401 we did not do an adequate job of describing how to handle > some cases, e.g., named SPD entries and PFP entries. Even for simple > SPD entries the notion of going back to the SPD to lookup each > outbound packet is clearly something that scales poorly for bigger > SPDs and/or high speeds. (Of course all of this is only a concern for > BITS/BITW/SG implementations. native host implementations have an > intrinsic form of caching anyway.) I think most of the implementations are doing and are going to do the processing differently what is described in the rfc2401. This happens regardless how the processing is described there. The method used tries to be identical from the outside view, but might offer different extensions and optimizations depending on the scenario the specific ipsec implementation is aimed for. Security gateway supporting 10000 vpn-clients will have completely different optimizations compared to the sgw aimed for connecting 2 branch offices together with one tunnel. I do not think rfc2401 needs to define the scalable and efficient procedure, it needs to describe the processing as clearly as possible, and then we might have another document (or the appendix) describing all kind of optimizations etc which can be used to make it scalable and optimal for different uses. > The processing model for IPsec is not a proscription for > implementation. It gives details of one way to implement IPsec. The > intent is that a compliant implementation should behave in an > identical manner, as viewed by the IPsec peer and by the user/admin, > no matter how it is implemented locally. We need at least one model > to provide a reference, and it is preferable if the model is as > simple as possible, to make it easy to describe and to understand. Yes. It needs to be as simple as possible, it does not necessarely need to be efficient or scalable. If it happens to be both even better, but no extra complexity should be added to the model to make it more scalable or efficient. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Mon Mar 8 12:38: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 i28KciKb098395; Mon, 8 Mar 2004 12:38:44 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13295 Mon, 8 Mar 2004 15:03:30 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16460.51481.931296.945354@fireball.acr.fi> References: <20040306130924.A1D2958@coconut.itojun.org> <16460.51481.931296.945354@fireball.acr.fi> Date: Mon, 8 Mar 2004 14:30:52 -0500 To: Tero Kivinen From: Stephen Kent Subject: Re: SPD Cache in 2401bis 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 9:27 PM +0200 3/8/04, Tero Kivinen wrote: >Stephen Kent writes: >> In 2401 we did not do an adequate job of describing how to handle >> some cases, e.g., named SPD entries and PFP entries. Even for simple >> SPD entries the notion of going back to the SPD to lookup each >> outbound packet is clearly something that scales poorly for bigger >> SPDs and/or high speeds. (Of course all of this is only a concern for >> BITS/BITW/SG implementations. native host implementations have an >> intrinsic form of caching anyway.) > >I think most of the implementations are doing and are going to do the >processing differently what is described in the rfc2401. This happens >regardless how the processing is described there. The method used >tries to be identical from the outside view, but might offer different >extensions and optimizations depending on the scenario the specific >ipsec implementation is aimed for. That is completely consistent with what I said later re the purpose of the model. >Security gateway supporting 10000 vpn-clients will have completely >different optimizations compared to the sgw aimed for connecting 2 >branch offices together with one tunnel. sure. >I do not think rfc2401 needs to define the scalable and efficient >procedure, it needs to describe the processing as clearly as possible, >and then we might have another document (or the appendix) describing >all kind of optimizations etc which can be used to make it scalable >and optimal for different uses. > >> The processing model for IPsec is not a proscription for >> implementation. It gives details of one way to implement IPsec. The >> intent is that a compliant implementation should behave in an >> identical manner, as viewed by the IPsec peer and by the user/admin, >> no matter how it is implemented locally. We need at least one model >> to provide a reference, and it is preferable if the model is as >> simple as possible, to make it easy to describe and to understand. > >Yes. It needs to be as simple as possible, it does not necessarely >need to be efficient or scalable. If it happens to be both even >better, but no extra complexity should be added to the model to make >it more scalable or efficient. I think we are in agreement. My feeling is that the cache-based model meets that criteria, i.e., it is simpler to explain in detail, and happens to scale well. Steve From owner-ipsec@lists.tislabs.com Tue Mar 9 11:00: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 i29J0rVt057983; Tue, 9 Mar 2004 11:00:53 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27094 Tue, 9 Mar 2004 13:08:18 -0500 (EST) Message-ID: From: "Robertson, Geoff" To: "'ipsec@lists.tislabs.com'" Subject: status of IPsec MIBs Date: Tue, 9 Mar 2004 13:14:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/related; boundary="----_=_NextPart_000_01C40602.6BC413D0"; type="multipart/alternative" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C40602.6BC413D0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40602.6BC413D0" ------_=_NextPart_001_01C40602.6BC413D0 Content-Type: text/plain Hello, I was writing to the forum because I haven't been able to find out the current status of two IPsec MIBs: IPSEC-FLOW-MONITOR-MIB (draft-ietf-ipsec-flow-monitoring-mib-0X.txt) And IPSEC-SA-MON-MIB (draft-ietf-ipsec-monitor-mib-0X.txt) Will these MIBs be released as RFCs anytime in the foreseeable future? Thank you for any help you can give, Geoffrey Robertson _____ "There is nothing more important than our customers." Geoffrey Robertson Software Engineer Email: groberts@aprisma.com 273 Corporate Drive Portsmouth, New Hampshire 03801 Tel: 603-334-2165 Fax: 603-334-2934 ------_=_NextPart_001_01C40602.6BC413D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" = xmlns=3D"http://www.w3.org/TR/REC-html40"> Hello, = I was writing to the forum because I haven't been able to = find out the current status of two IPsec MIBs: &nb= sp; IPSEC-FLOW-MONITOR-MIB (draft-ietf-ipsec-flow-monitoring-mib-0X.txt) And = &nb= sp; IPSEC-SA-MON-MIB (draft-ietf-ipsec-monitor-mib-0X.txt) Will = these MIBs be released as RFCs anytime in the foreseeable future? = Thank you for any help you can give, = Geoffrey Robertson "There is nothing more important than our customers." Geoffrey Robertson Software Engineer Email: <3d.htm>groberts@aprisma.com 273 Corporate = Drive Portsmouth, = New = Hampshire = 03801 Tel: 603-334-2165 Fax: 603-334-2934 ------_=_NextPart_001_01C40602.6BC413D0-- ------_=_NextPart_000_01C40602.6BC413D0 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="image001.gif" Content-ID: R0lGODlhjgArALMKAMjIyP///6ioqN/f3/dKC/Ly8fzErvypivmDVv3d0P///wAAAAAAAAAAAAAA AAAAACH5BAEAAAoALAAAAACOACsAAAT/UIVJq7046827/2BIKaRonmiqqqS0vmEBz2tL35hBEIiM /x0bEJfY7RDDJEaohOmMhKY0wJymikakNVndnp4977ArNvnKPzJ6zaaW2iEDwgA3L9+YweAzAAj+ fwADZxd9foCChBVPBHR5AIeBexcFkJaXmJB6ihuCE5V6ABVqAQV/nBYDgIGrApMVqquQspRQWhWV ra2vE5G6v4ioFqaiE6HFE6SxvIWSqYiwkoS5AsgTWEbTiIOlBX1/vJGaoat65OAch5ODkKN4uKvC ptUZsQJnftYW6hXYOwkVoGE4VIHfPnTP7mmwp8+CmkP5MsyTB2jSPGbR6FHwRwCgsUAa/yZSiEjp 1EBXGvIhvOMCniuRJRXmAeTjokSD16AQOBOrIS5CJIeZvBA0oTeNLIlqLEpBZIGnT7+ttNnUG8Nh OoEGEqbUJ8yDPgP4mbTS4btSQ782NQnM01qUH3fVyjJMnKBNGZh+Ggp2psxYGboU1SvSkCVuQuGK pZUBAd1CvmQp0otWZl+l4RS7a1lZm+W9nzlQDWDP2QXHOw6ENDeLZkGkLlHpBZwx6UjYvXCrFV22 21ULB4w48vA7t1e+rxuOxXyByTwAk5Hv3jA6seYAjDxSQIxhnmXK0xfr61n3T3M8vi4xBs01Jsbt IPtlq13PtfHuyG/ra6W+olkX3iESmf9l4UnUW0b6FDDfW+95Zw14+d0HH38DEiIERBhJhUx1vF2H IFY8KFXNIFGJo9VxoUk4QTDDaLhZZe9NWFOEIR04IUaO3ZJRW9GhKJtiBeYmwIukxViQNXqIkOQG S1rgmGrdGbINKpUI02RdQBn5iVvJnFXHBsEN92UKpIxpgQ7amXlCmWrmlGabIbDZZgJhwGmCnHPa uaaXevaJghB9rKNJL5D4UGgplsiQKKJi7dHHU4lwuR1iT33STaVWGYMYXt5w0iSlVZVSCqc+UCpD TRgJUQ10pLmi0EuE9vERWYag1ehieozYDi6CiGLIHr2aI5YnoIgCigy/FlRrsqwWKRbapKwm2Suy 0Pna63+xzvrqoe3M6EM1KJlyaz7Lcbfls9BVQtolinKjbrqJFKnuSCSKxWiz0iK7DjvOBipKoYoI cZSjI66IWDsWyeRKt0N6kslNDkOK6KKDVtJtvJtY443D95YKrL6aqpukYaNK6oYEqljcakAHz7LX tyqbogqwmNxEr6wBLFxMs1XCOynOvWz8bL7GVAuys9U6uqzERC4K9LDNHoqooUKvW4w5wkbZlNTQ LWlIVKQp6snXvLJqsdiTDOpsv25hPTEzePop9wZxz203tnfn7QEJEQAAOw== ------_=_NextPart_000_01C40602.6BC413D0-- From owner-ipsec@lists.tislabs.com Tue Mar 9 18:55:49 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 i2A2tnYT088967; Tue, 9 Mar 2004 18:55:49 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA21915 Tue, 9 Mar 2004 21:10:37 -0500 (EST) Date: Wed, 10 Mar 2004 11:21:47 +0900 From: Satoshi Inoue To: ipsec@lists.tislabs.com Subject: Re: AH and mutable fields, how deep to look? Message-Id: <20040310112147.76803a75.inoue@ntes.ipv6.nec.co.jp> In-Reply-To: References: <200312091018.hB9AIl0l029185@burp.tkv.asdf.org> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk # It's a bit of an old issue, but never mind :-) On Wed, 10 Dec 2003 18:11:32 -0500 Stephen Kent wrote: > The intent was to treat everything after AH as opaque, in IPv6 as > well as IPv4. What change to the graphics would help convey this > better? Isn't it better to write about this as `diffs from rfc2402' in rfc2402bis? I think there should also be some descriptions on interop probs that this might cause. From owner-ipsec@lists.tislabs.com Fri Mar 12 10:30:47 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 i2CIUkce056661; Fri, 12 Mar 2004 10:30:47 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03137 Fri, 12 Mar 2004 12:29:37 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200403051131.i25BV3ji006208@burp.tkv.asdf.org> References: <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040226095435.0208aa50@email> <200403051131.i25BV3ji006208@burp.tkv.asdf.org> Date: Fri, 12 Mar 2004 12:41:15 -0500 To: Markku Savela 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 At 1:31 PM +0200 3/5/04, Markku Savela wrote: >I've been thinking about this a bit more, and my conclusion is: > >If > you want to apply IPSEC on fragments, >and > you want to use port selectors >then > There is no way out of it: then at least one of the IPSEC > implementations MUST buffer ALL fragments before it can > release any packets to the stacks fragment assembly. > >Consider mobile node M communicating with server S behing the security >gateway SG. Assume S fragments some data going towards M, and assume >there is a port specific policy: > > PORT=A, send in clear > PORT=B, use ESP > PORT=C, use AH > > M <==== IPSEC ====> SG <---> S I assume an unstated part of this policy is that the S/D IP addresses are all the same, e.g., M and S and that the protocol is ANY or the same. also, only one port is cited above, so let's assume it is the destination port, since that is likely to be well known, whereas the source port is likely to be ANY. it's not clear why one would construct this policy, in practice, but it is legitimate in the abstract. >First SG: It has been said it is not acceptable to require SG to do >packet assembly before the IPSEC. If so, then NONE of the selectors >affecting the M <-> SG traffic can have port selectors. more precisely, all of the traffic between M and SG must be treated uniformly wrt ports, otherwise non-initial fragments cannot be assured the intended treatment. of course, one could also state that IF there were a total ordering on security, then affording non-initial fragments the most secure treatment would not "under protect" any traffic, although it might "over protect" it. so, the characterization above is not quite right. >If you have port selectors, you cannot let the packets through until >you see the first fragment. (You don't know whether port is A or >B). but, as noted above, I could choose to map non-initial fragments to the ESP SA, if my concern were to not under protect any traffic. >- one argument against SG doing the assembly has been: not all > fragments may arrive to the same SG. Only one of the SG's sees the > first fragment. => The other can never do the correct thing and > fragments are dropped after some timeout or until buffer space runs > out. Communication fails randomly, exactly the same way as if SG's > were required to assemble packets. this paragraph sounded OK until the last sentence, which then seems to be comparing the strategy to itself? >- because there is no ordering requirements for fragments, the SG must > be prepared to buffer all fragments. It might as well do packet > assembly. (Linux sends the first fragment as last!) > >Second M: When receiving fragments protected with ESP from SG, the >IPSEC MUST buffer and hold all fragments until it receives the first >fragment. Only then it can check whether the port was A (if port is >not A, the packet must be dropped, even if the ESP transformation >succeeded). not clear that this is true. there is a fragment reassembly overlap attack to worry about, but that could be addressed separately. if so, then it's not clear that allowing fragments through on an SA is bad, if they pass the non-port field selector checks, and if the initial fragment, when it arrives, passes all the selector checks. >After receiving the first fragment, IPSEC can release the buffered >fragments to the fragment assebly of the IP stack. However, it needs >to remember the port state to be able to check any remaining >fragments. How long it needs to keep this state? Might be just easier >to do the assembly in IPSEC, to be sure. see comment above. >IPSEC on M must also hold all clear fragments in similar way, until it >knows what IPSEC was to be applied. each IPsec packet carries an SPI that maps it to an indicated SA, and the crypto checks will fail if it is mapped to the wrong SA. so the statement above is not correct. >Additional consideration: the fragments will have SRC=S, DST=M. IPSEC >must buffer those too, until it knows the port. It cannot let them >through, because someone could send fake fragments to poison the >stacks fragment assembly (and place some attack data into supposedly >secured communication using port B or C). see earlier comment. >So, if SG allows IPSEC on fragments, then IPSEC on M needs to be >prepared to buffer full packet. It has to implement same safeguards >against dos attacks as the standard fragment assembly. An attacker may >find some holes by forcing IPSEC to forget some state, and then >sending some tailored fake fragments? see earlier comment. >I guess, supporting port selectors and IPSEC on fragments is possible, >but it's lot of work and requires almost full replication of the >fragment assemble within IPSEC. It might be hard to make the thing >actually secure against attacks. > >Conclusion: Do not allow port selectors and IPSEC on fragments at same >time. Then, the buffering requirements disappear and it is possible to >check security of each packet and fragment alone. I'm almost ready to send my analysis of the various issues, which hopefully will help clarify the arguments you have made above, as well as others. I agree that there is no magic bullet, but some details of your arguments here are not quite right. Steve From owner-ipsec@lists.tislabs.com Fri Mar 12 10:37: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 i2CIb0Yd056921; Fri, 12 Mar 2004 10:37:00 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13037 Fri, 12 Mar 2004 12:57:23 -0500 (EST) Message-ID: From: "Robertson, Geoff" To: "Robertson, Geoff" , "'ipsec@lists.tislabs.com'" Subject: RE: status of IPsec MIBs Date: Fri, 12 Mar 2004 13:08:20 -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 Sorry about that William. My question involved the status of two MIBs which The Efficient Networks routers support. (now owned by Siemens Subscriber Networks) IPSEC-FLOW-MONITOR-MIB (draft-ietf-ipsec-flow-monitoring-mib-0X.txt) And IPSEC-SA-MON-MIB (draft-ietf-ipsec-monitor-mib-0X.txt) Will these MIBs be released as RFCs anytime in the foreseeable future? Thank you for any help you can give, Geoffrey Robertson From owner-ipsec@lists.tislabs.com Fri Mar 12 14:42: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 i2CMgiaX070575; Fri, 12 Mar 2004 14:42:44 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08400 Fri, 12 Mar 2004 16:57:47 -0500 (EST) From: "Frank Herchet (mailings)" To: Subject: IPsec and racoon in tunnel-mode Date: Fri, 12 Mar 2004 22:57:15 +0100 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200403122257.21422.mailings@herchet.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id QAA08311 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, possibly somone can help me. i'm trying to secure a connection between two hosts. i'v configured setkey: - ----------------------------------------------------------------------- # /usr/sbin/setkey -f # Flush the SAD and SPD flush; spdflsuh; spdadd 192.168.1.10[any] 192.168.1.12[any] any -P out ipsec esp/transport/192.168.1.10-192.168.1.12/require ah/transport/192.168.1.10-192.168.1.12/require; spdadd 192.168.1.12[any] 192.168.1.10[any] any -P in ipsec esp/transport/192.168.1.12-192.168.1.10/require ah/transport/192.168.1.12-192.168.1.10/require; - ----------------------------------------------------------------------- and racoon.conf - ----------------------------------------------------------------------- remote 192.168.1.12 { exchange_mode main; proposal { encryption_algorithm 3des; hash_algorithm md5; authentication_method pre_shared_key; dh_group modp1024; } } sainfo address 192.168.1.0/24 any address 192.168.1.0/24 any { pfs_group modp768; encryption_algorithm 3des; authentication_algorithm hmac_md5; compression_algorithm deflate; } - ----------------------------------------------------------------------- after starting racoon and trying to ping the other host, i get these messages and no connection: 2004-03-12 22:58:19: DEBUG: pfkey.c:195:pfkey_handler(): get pfkey ACQUIRE message 2004-03-12 22:58:19: DEBUG: pfkey.c:1548:pk_recvacquire(): suitable outbound SP found: 192.168.1.12/32[0] 192.168.1.10/32[0] proto=any dir=out. 2004-03-12 22:58:19: DEBUG: policy.c:183:cmpspidxstrict(): sub:0xbffff480: 192.168.1.10/32[0] 192.168.1.12/32[0] proto=any dir=in 2004-03-12 22:58:19: DEBUG: policy.c:184:cmpspidxstrict(): db :0x809f490: 192.168.1.10/32[0] 192.168.1.12/32[0] proto=any dir=in 2004-03-12 22:58:19: DEBUG: pfkey.c:1564:pk_recvacquire(): suitable inbound SP found: 192.168.1.10/32[0] 192.168.1.12/32[0] proto=any dir=in. 2004-03-12 22:58:19: DEBUG: pfkey.c:1603:pk_recvacquire(): new acquire 192.168.1.12/32[0] 192.168.1.10/32[0] proto=any dir=out 2004-03-12 22:58:19: ERROR: pfkey.c:1633:pk_recvacquire(): failed to get sainfo. can smeone help me please ? what i've done wrong ? thx Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iQCVAwUBQFIyP/qrCi15ZonmAQLWAAP+JY5m+x+MX/UIYJL79Lo/y/rEP99aBqCZ Rb/uPnREG9UI1wuq2fYA4cGmb9syM4PZodnN3h+8BSICNTtzkihDw5vSv/OdzLt4 9YAvVC0vGDQ296Al2Nlk9oHbo16tDB9fGnmXnhjM7H8iJ8GX/OEqn7N+JSmiAEk1 S4/Wq7Y6HN8= =qnqC -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Mar 12 16:05: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 i2D05BXL074773; Fri, 12 Mar 2004 16:05:11 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA10275 Fri, 12 Mar 2004 18:24:34 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200403122216.i2CMGFJG016385@burp.tkv.asdf.org> References: <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040226095435.0208aa50@email> <200403051131.i25BV3ji006208@burp.tkv.asdf.org> <200403122216.i2CMGFJG016385@burp.tkv.asdf.org> Date: Fri, 12 Mar 2004 17:59:37 -0500 To: Markku Savela 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 At 12:16 AM +0200 3/13/04, Markku Savela wrote: > > From: Stephen Kent >> At 1:31 PM +0200 3/5/04, Markku Savela wrote: > >> >Consider mobile node M communicating with server S behing the security >> >gateway SG. Assume S fragments some data going towards M, and assume >> >there is a port specific policy: >> > >> > PORT=A, send in clear >> > PORT=B, use ESP >> > PORT=C, use AH >> > >> > M <==== IPSEC ====> SG <---> S > >> >First SG: It has been said it is not acceptable to require SG to do >> >packet assembly before the IPSEC. If so, then NONE of the selectors >> >affecting the M <-> SG traffic can have port selectors. >> >> more precisely, all of the traffic between M and SG must be treated >> uniformly wrt ports, otherwise non-initial fragments cannot be >> assured the intended treatment. of course, one could also state that >> IF there were a total ordering on security, then affording >> non-initial fragments the most secure treatment would not "under >> protect" any traffic, although it might "over protect" it. so, the >> characterization above is not quite right. > >>From a set of ESP and AH choices, how do you order them? Which ESP is >better protection over another ESP? Is AH better than ESP without >authentication? didn't you note my comment above re IF you could totally order? Frankly, I think that in practise this is possible, even though it is not in principle. > >> >If you have port selectors, you cannot let the packets through until >> >you see the first fragment. (You don't know whether port is A or >> >B). >> >> but, as noted above, I could choose to map non-initial fragments to >> the ESP SA, if my concern were to not under protect any traffic. > >Yes, but at least my current implementation rejects packets that are >protected validly with ESP or AH, but policy calls for no protection >(or if policy calls for different protection). that's an interesting "feature." I can understand why you might choose to do that, e.g., for fault detection and isolation, but I'm not sure it is needed from a security perspective. > >> >IPSEC on M must also hold all clear fragments in similar way, until it > > >knows what IPSEC was to be applied. >> >> each IPsec packet carries an SPI that maps it to an indicated SA, and >> the crypto checks will fail if it is mapped to the wrong SA. so the >> statement above is not correct. > >Yes, but it must hold clear packets, until it knows their ports. If it >lets a non initial clear packets (no SPI, just plain data, it might be >port=A), through to packet assembly, an attacker can create the >following assembled packet: > > ================== attack data from clear packets > ** data from real ESP protected packet > >If the attack data comes before the ESP packet(s), only the still >missing parts in the assembly are filled from the protected data (and >this could be as little as the TCP header -- the first attack content >can begin at the payload offset 8). > in the case of v4, it is possible for a receiver to perform a simple sanity check on offset values to reject this sort of attack. since the PMTU min for v4 is 576, and since the max header size is 60 bytes, one could adopt a conservative value such as 128 for the offset in a non-initial fragment, and prevent reassembly attacks. this check can be applied to all non-initial fragments, whether they arrive via an SA or as bypass traffic. Steve From owner-ipsec@lists.tislabs.com Sun Mar 14 06:29: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 i2EETgIB026985; Sun, 14 Mar 2004 06:29:42 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA03739 Sun, 14 Mar 2004 08:28:59 -0500 (EST) Date: Sun, 14 Mar 2004 15:40:40 +0200 Message-Id: <200403141340.i2EDeetm003016@burp.tkv.asdf.org> From: Markku Savela To: kent@bbn.com CC: ipsec@lists.tislabs.com In-reply-to: (message from Stephen Kent on Fri, 12 Mar 2004 17:59:37 -0500) Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems References: <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040226095435.0208aa50@email> <200403051131.i25BV3ji006208@burp.tkv.asdf.org> <200403122216.i2CMGFJG016385@burp.tkv.asdf.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Before going into details, just to restate my view of how dealing with fragments should be stated in the RFC: 1. The IPSEC that is applied to all fragments must be exactly the same that would be applied to the same packet when fully assembled. 2. Implementaion can limit support for IPSEC on fragments to policies that don't use port selectors. Above simple and clear, and does not lead to very convoluted additional specifications. > From: Stephen Kent > >>From a set of ESP and AH choices, how do you order them? Which ESP is > >better protection over another ESP? Is AH better than ESP without > >authentication? > > didn't you note my comment above re IF you could totally order? > Frankly, I think that in practise this is possible, even though it is > not in principle. We are supposed to define RFC. There is no room for hand wawing. For interoperability, you would need write RFC that exactly spells out the ordering rules, so that each implementation ends up picking the same one. > >Yes, but it must hold clear packets, until it knows their ports. If it > >lets a non initial clear packets (no SPI, just plain data, it might be > >port=A), through to packet assembly, an attacker can create the > >following assembled packet: > > > > ================== attack data from clear packets > > ** data from real ESP protected packet > > > >If the attack data comes before the ESP packet(s), only the still > >missing parts in the assembly are filled from the protected data (and > >this could be as little as the TCP header -- the first attack content > >can begin at the payload offset 8). > > > > in the case of v4, it is possible for a receiver to perform a simple > sanity check on offset values to reject this sort of attack. since > the PMTU min for v4 is 576, and since the max header size is 60 > bytes, one could adopt a conservative value such as 128 for the > offset in a non-initial fragment, and prevent reassembly attacks. > this check can be applied to all non-initial fragments, whether they > arrive via an SA or as bypass traffic. This is not acceptable for security. Whatever you choose 60, 128 or more, it still leaves the hole open. And, eventually, if the payback is large enough, someone will invent a way to utilize it. From owner-ipsec@lists.tislabs.com Sun Mar 14 10:00: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 i2EI0Z8W036069; Sun, 14 Mar 2004 10:00:35 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA26720 Sun, 14 Mar 2004 12:06:35 -0500 (EST) Message-Id: <200403141718.i2EHIGSj096994@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Frank Herchet (mailings)" cc: ipsec@lists.tislabs.com Subject: Re: IPsec and racoon in tunnel-mode In-reply-to: Your message of Fri, 12 Mar 2004 22:57:15 +0100. <200403122257.21422.mailings@herchet.net> Date: Sun, 14 Mar 2004 18:18:16 +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: sainfo address 192.168.1.0/24 any address 192.168.1.0/24 any { => the sainfo should be equal to the negociated phase 2 ID payloads, i.e., in transport mode /32 (or /128) is required. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Sun Mar 14 17:52: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 i2F1q7Jr060045; Sun, 14 Mar 2004 17:52:08 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10938 Fri, 12 Mar 2004 17:04:43 -0500 (EST) Date: Sat, 13 Mar 2004 00:16:15 +0200 Message-Id: <200403122216.i2CMGFJG016385@burp.tkv.asdf.org> From: Markku Savela To: kent@bbn.com CC: ipsec@lists.tislabs.com In-reply-to: (message from Stephen Kent on Fri, 12 Mar 2004 12:41:15 -0500) Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems References: <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040226095435.0208aa50@email> <200403051131.i25BV3ji006208@burp.tkv.asdf.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Stephen Kent > At 1:31 PM +0200 3/5/04, Markku Savela wrote: > >Consider mobile node M communicating with server S behing the security > >gateway SG. Assume S fragments some data going towards M, and assume > >there is a port specific policy: > > > > PORT=A, send in clear > > PORT=B, use ESP > > PORT=C, use AH > > > > M <==== IPSEC ====> SG <---> S > >First SG: It has been said it is not acceptable to require SG to do > >packet assembly before the IPSEC. If so, then NONE of the selectors > >affecting the M <-> SG traffic can have port selectors. > > more precisely, all of the traffic between M and SG must be treated > uniformly wrt ports, otherwise non-initial fragments cannot be > assured the intended treatment. of course, one could also state that > IF there were a total ordering on security, then affording > non-initial fragments the most secure treatment would not "under > protect" any traffic, although it might "over protect" it. so, the > characterization above is not quite right. >From a set of ESP and AH choices, how do you order them? Which ESP is better protection over another ESP? Is AH better than ESP without authentication? > >If you have port selectors, you cannot let the packets through until > >you see the first fragment. (You don't know whether port is A or > >B). > > but, as noted above, I could choose to map non-initial fragments to > the ESP SA, if my concern were to not under protect any traffic. Yes, but at least my current implementation rejects packets that are protected validly with ESP or AH, but policy calls for no protection (or if policy calls for different protection). > >IPSEC on M must also hold all clear fragments in similar way, until it > >knows what IPSEC was to be applied. > > each IPsec packet carries an SPI that maps it to an indicated SA, and > the crypto checks will fail if it is mapped to the wrong SA. so the > statement above is not correct. Yes, but it must hold clear packets, until it knows their ports. If it lets a non initial clear packets (no SPI, just plain data, it might be port=A), through to packet assembly, an attacker can create the following assembled packet: ================== attack data from clear packets ** data from real ESP protected packet If the attack data comes before the ESP packet(s), only the still missing parts in the assembly are filled from the protected data (and this could be as little as the TCP header -- the first attack content can begin at the payload offset 8). From owner-ipsec@lists.tislabs.com Sun Mar 14 17:52:09 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 i2F1q9DD060054; Sun, 14 Mar 2004 17:52:09 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA12137 Sun, 14 Mar 2004 08:49:48 -0500 (EST) Date: Sun, 14 Mar 2004 16:01:27 +0200 Message-Id: <200403141401.i2EE1Rqk003078@burp.tkv.asdf.org> From: Markku Savela To: kent@bbn.com CC: ipsec@lists.tislabs.com In-reply-to: (message from Stephen Kent on Fri, 12 Mar 2004 17:59:37 -0500) Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems References: <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040226095435.0208aa50@email> <200403051131.i25BV3ji006208@burp.tkv.asdf.org> <200403122216.i2CMGFJG016385@burp.tkv.asdf.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Stephen Kent > >Yes, but at least my current implementation rejects packets that are > >protected validly with ESP or AH, but policy calls for no protection > >(or if policy calls for different protection). > > that's an interesting "feature." I can understand why you might > choose to do that, e.g., for fault detection and isolation, but I'm > not sure it is needed from a security perspective. This "feature" may have real uses. The following example is a bit artificial, but it may serve for now: A mobile node M is talking to a server S, hosting some database application. S is behind a normal Firewall (FW), which the admins configure to pass IPSEC traffic to S, knowing it only *accepts* and requires the database traffic to be protected. M <============ FW ====== DataBaseAccess ===> S S is also hosting other services (WEB, SMTP, etc), which are used in clear and it is assumed that the FW filters dangerous stuff from clear traffic. If M gets infected with something, M could quite easily send some harmful stuff using the Database IPSEC connection, if S accepts anything else that just happens to be validly protected by the IPSEC. From owner-ipsec@lists.tislabs.com Mon Mar 15 02:53: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 i2FArhxP059834; Mon, 15 Mar 2004 02:53:43 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA15557 Mon, 15 Mar 2004 04:59:11 -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: <16469.33068.11002.890402@fireball.acr.fi> Date: Mon, 15 Mar 2004 12:10:52 +0200 From: Tero Kivinen To: Stephen Kent Cc: Markku Savela , 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> <5.2.0.9.0.20040226095435.0208aa50@email> <200403051131.i25BV3ji006208@burp.tkv.asdf.org> <200403122216.i2CMGFJG016385@burp.tkv.asdf.org> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 11 min X-Total-Time: 11 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > > ================== attack data from clear packets > > ** data from real ESP protected packet > > > >If the attack data comes before the ESP packet(s), only the still > >missing parts in the assembly are filled from the protected data (and > >this could be as little as the TCP header -- the first attack content > >can begin at the payload offset 8). > in the case of v4, it is possible for a receiver to perform a simple > sanity check on offset values to reject this sort of attack. since > the PMTU min for v4 is 576, and since the max header size is 60 > bytes, one could adopt a conservative value such as 128 for the > offset in a non-initial fragment, and prevent reassembly attacks. > this check can be applied to all non-initial fragments, whether they > arrive via an SA or as bypass traffic. How about the following attack. The A is the sender behind SGW1, The B is the receiver behind SGW2. The connection between SGW1 and SGW2 is protected by the ESP for port 25 and all other traffic is sent in clear. This means SGW1 and SGW2 will accept non-first fragments in clear: A ----- SGW1 <====== M ====> SGW2 ---- B A sends 2000 byte packet fragmented to 2 pieces p1 and p2, each 1000 bytes. A -> B (first fragment, bytes 0-1000) A -> B (non-first fragment, bytes 1001-2000) The SGW1 will encrypt the packets (lets say it uses the rule that all non-first fragments are sent using the ESP, i.e. receiving identical protection than the first-fragments). SGW1 -> SGW2 (ESP Tunnel A->B, first fragment, bytes 0-1000) SGW1 -> SGW2 (ESP Tunnel A->B, non-first fragment, bytes 1001-2000) Attacker M deletes the second packet from the wire, and replaces it with clear text packet: A -> B (different non-first fragment, bytes 1001-2000) SGW2 will decrypt the first fragment, and let the second packet go through in clear (the policy said that there is only ESP protection for port 25, so the non-first framgment is not against the policy). B will receive 2 fragments A -> B (first fragment, bytes 0-1000) A -> B (different non-first fragment, bytes 1001-2000) where the first one is really from the other end the second one was inserted in by the attacker. There are 2 ways for the SGW2 to protect against this attack: 1) Require ESP protection for all non-first fragment 2) Do partial or full reassembly for all fragments going through (not only those protected by ESP) and verify that the packets match the policy. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Mon Mar 15 03:21:32 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 i2FBLVnZ062095; Mon, 15 Mar 2004 03:21:31 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA24912 Mon, 15 Mar 2004 05:29:55 -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: <16469.34946.246577.912093@fireball.acr.fi> Date: Mon, 15 Mar 2004 12:42:10 +0200 From: Tero Kivinen To: Markku Savela Cc: kent@bbn.com, ipsec@lists.tislabs.com Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems In-Reply-To: <200403141340.i2EDeetm003016@burp.tkv.asdf.org> References: <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040226095435.0208aa50@email> <200403051131.i25BV3ji006208@burp.tkv.asdf.org> <200403122216.i2CMGFJG016385@burp.tkv.asdf.org> <200403141340.i2EDeetm003016@burp.tkv.asdf.org> 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 Markku Savela writes: > Before going into details, just to restate my view of how dealing with > fragments should be stated in the RFC: > > 1. The IPSEC that is applied to all fragments must be exactly the same > that would be applied to the same packet when fully assembled. > > 2. Implementaion can limit support for IPSEC on fragments to policies > that don't use port selectors. > > Above simple and clear, and does not lead to very convoluted > additional specifications. I agree. The above is simple and it covers the most common cases (i.e. if you do not want to do the first option, then simply do not support fragments and port selectors). Also if your setup is such that option 1 is not possible (for example load balancing between multiple security gateways) do not allow port selectors or do not allow fragments. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Mon Mar 15 09:17: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 i2FHH5JW081709; Mon, 15 Mar 2004 09:17:06 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA29801 Mon, 15 Mar 2004 11:26:32 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200403141340.i2EDeetm003016@burp.tkv.asdf.org> References: <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040226095435.0208aa50@email> <200403051131.i25BV3ji006208@burp.tkv.asdf.org> <200403122216.i2CMGFJG016385@burp.tkv.asdf.org> <200403141340.i2EDeetm003016@burp.tkv.asdf.org> Date: Mon, 15 Mar 2004 11:30:07 -0500 To: Markku Savela 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 At 3:40 PM +0200 3/14/04, Markku Savela wrote: >Before going into details, just to restate my view of how dealing with >fragments should be stated in the RFC: > >1. The IPSEC that is applied to all fragments must be exactly the same > that would be applied to the same packet when fully assembled. I agree that this would be ideal, but it would not be awful, from a communication security perspective, if we applied "better" protection to fragments. Yes, I realize that the protection suites might be a lattice vs. totally ordered, in principle, but in practice I think this is not like to be true. >2. Implementaion can limit support for IPSEC on fragments to policies > that don't use port selectors. We are in complete agreement on this point. >Above simple and clear, and does not lead to very convoluted >additional specifications. > >> From: Stephen Kent > >> >>From a set of ESP and AH choices, how do you order them? Which ESP is >> >better protection over another ESP? Is AH better than ESP without >> >authentication? >> >> didn't you note my comment above re IF you could totally order? >> Frankly, I think that in practise this is possible, even though it is >> not in principle. > >We are supposed to define RFC. There is no room for hand wawing. For >interoperability, you would need write RFC that exactly spells out the >ordering rules, so that each implementation ends up picking the same >one. Well, since fragment reassembly will not always be possible at an intermediate point, and that was your proposal, I don't think it is "hand waving" to suggest an artificially imposed total ordering vs. assuming that all fragments will arrive at a specific SG. > >> >Yes, but it must hold clear packets, until it knows their ports. If it >> >lets a non initial clear packets (no SPI, just plain data, it might be >> >port=A), through to packet assembly, an attacker can create the >> >following assembled packet: >> > >> > ================== attack data from clear packets >> > ** data from real ESP protected packet >> > >> >If the attack data comes before the ESP packet(s), only the still >> >missing parts in the assembly are filled from the protected data (and >> >this could be as little as the TCP header -- the first attack content >> >can begin at the payload offset 8). >> > >> >> in the case of v4, it is possible for a receiver to perform a simple >> sanity check on offset values to reject this sort of attack. since >> the PMTU min for v4 is 576, and since the max header size is 60 >> bytes, one could adopt a conservative value such as 128 for the >> offset in a non-initial fragment, and prevent reassembly attacks. >> this check can be applied to all non-initial fragments, whether they >> arrive via an SA or as bypass traffic. > >This is not acceptable for security. Whatever you choose 60, 128 or >more, it still leaves the hole open. And, eventually, if the payback >is large enough, someone will invent a way to utilize it. What hole? if I choose 128 bytes that I know definitively that no non-initial fragment can overwrite port fields, because the max IP header length is bounded and well short of this size. Steve From owner-ipsec@lists.tislabs.com Mon Mar 15 09:17: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 i2FHH6Lo081710; Mon, 15 Mar 2004 09:17:06 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA29812 Mon, 15 Mar 2004 11:26:34 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200403141401.i2EE1Rqk003078@burp.tkv.asdf.org> References: <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040226095435.0208aa50@email> <200403051131.i25BV3ji006208@burp.tkv.asdf.org> <200403122216.i2CMGFJG016385@burp.tkv.asdf.org> <200403141401.i2EE1Rqk003078@burp.tkv.asdf.org> Date: Mon, 15 Mar 2004 11:04:07 -0500 To: Markku Savela 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 At 4:01 PM +0200 3/14/04, Markku Savela wrote: > > From: Stephen Kent > >> >Yes, but at least my current implementation rejects packets that are >> >protected validly with ESP or AH, but policy calls for no protection >> >(or if policy calls for different protection). >> >> that's an interesting "feature." I can understand why you might >> choose to do that, e.g., for fault detection and isolation, but I'm >> not sure it is needed from a security perspective. > >This "feature" may have real uses. The following example is a bit >artificial, but it may serve for now: > > A mobile node M is talking to a server S, hosting some database > application. S is behind a normal Firewall (FW), which the admins > configure to pass IPSEC traffic to S, knowing it only *accepts* and > requires the database traffic to be protected. > > M <============ FW ====== DataBaseAccess ===> S the diagram is missing a SG, between the FW and S, right? > S is also hosting other services (WEB, SMTP, etc), which are used in > clear and it is assumed that the FW filters dangerous stuff from > clear traffic. > > If M gets infected with something, M could quite easily send some > harmful stuff using the Database IPSEC connection, if S accepts > anything else that just happens to be validly protected by the IPSEC. OK, this is a better explanation. the concern is that if we carry traffic other than what was intended to travel via the SA, then even if we are offering it better protection en route, we may violate the access control scheme at the receiver, if the receiver is configured to pass non-IPsec traffic via one path, and IPsec via another. Steve From owner-ipsec@lists.tislabs.com Mon Mar 15 09:18: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 i2FHI8QE081755; Mon, 15 Mar 2004 09:18:09 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA29963 Mon, 15 Mar 2004 11:26:58 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16469.33068.11002.890402@fireball.acr.fi> References: <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040226095435.0208aa50@email> <200403051131.i25BV3ji006208@burp.tkv.asdf.org> <200403122216.i2CMGFJG016385@burp.tkv.asdf.org> <16469.33068.11002.890402@fireball.acr.fi> Date: Mon, 15 Mar 2004 11:36:06 -0500 To: Tero Kivinen From: Stephen Kent Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems Cc: Markku Savela , 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:10 PM +0200 3/15/04, Tero Kivinen wrote: >Stephen Kent writes: >> > ================== attack data from clear packets >> > ** data from real ESP protected packet >> > >> >If the attack data comes before the ESP packet(s), only the still >> >missing parts in the assembly are filled from the protected data (and >> >this could be as little as the TCP header -- the first attack content >> >can begin at the payload offset 8). >> in the case of v4, it is possible for a receiver to perform a simple >> sanity check on offset values to reject this sort of attack. since >> the PMTU min for v4 is 576, and since the max header size is 60 >> bytes, one could adopt a conservative value such as 128 for the >> offset in a non-initial fragment, and prevent reassembly attacks. >> this check can be applied to all non-initial fragments, whether they >> arrive via an SA or as bypass traffic. > >How about the following attack. The A is the sender behind SGW1, The B >is the receiver behind SGW2. The connection between SGW1 and SGW2 is >protected by the ESP for port 25 and all other traffic is sent in >clear. This means SGW1 and SGW2 will accept non-first fragments in >clear: > >A ----- SGW1 <====== M ====> SGW2 ---- B > >A sends 2000 byte packet fragmented to 2 pieces p1 and p2, each 1000 >bytes. > > A -> B (first fragment, bytes 0-1000) > A -> B (non-first fragment, bytes 1001-2000) > >The SGW1 will encrypt the packets (lets say it uses the rule that all >non-first fragments are sent using the ESP, i.e. receiving identical >protection than the first-fragments). > > SGW1 -> SGW2 (ESP Tunnel A->B, first fragment, bytes 0-1000) > SGW1 -> SGW2 (ESP Tunnel A->B, non-first fragment, bytes 1001-2000) > >Attacker M deletes the second packet from the wire, and replaces it >with clear text packet: > > A -> B (different non-first fragment, bytes 1001-2000) > >SGW2 will decrypt the first fragment, and let the second packet go >through in clear (the policy said that there is only ESP protection >for port 25, so the non-first framgment is not against the policy). > > >B will receive 2 fragments > > A -> B (first fragment, bytes 0-1000) > A -> B (different non-first fragment, bytes 1001-2000) > >where the first one is really from the other end the second one was >inserted in by the attacker. There are 2 ways for the SGW2 to protect >against this attack: > > 1) Require ESP protection for all non-first fragment > 2) Do partial or full reassembly for all fragments going > through (not only those protected by ESP) and verify that > the packets match the policy. the proposal to carry all non-initial fragments on an SA between two sites would require that a receiver reject all plaintext fragments that appear to be from a site with which IPsec protection was employed. that seems to be consistent with #1 above. #2 would work, in the contexts where there is only one SG serving a site. Steve Steve From owner-ipsec@lists.tislabs.com Mon Mar 15 11:24: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 i2FJOu78088656; Mon, 15 Mar 2004 11:24:56 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13563 Mon, 15 Mar 2004 13:26:36 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16469.63524.987000.714615@gargle.gargle.HOWL> Date: Mon, 15 Mar 2004 13:38:28 -0500 From: Paul Koning To: kent@bbn.com Cc: msa@burp.tkv.asdf.org, ipsec@lists.tislabs.com Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems References: <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040226095435.0208aa50@email> <200403051131.i25BV3ji006208@burp.tkv.asdf.org> <200403122216.i2CMGFJG016385@burp.tkv.asdf.org> <200403141340.i2EDeetm003016@burp.tkv.asdf.org> 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> At 3:40 PM +0200 3/14/04, Markku Savela wrote: >> Before going into details, just to restate my view of how dealing >> with fragments should be stated in the RFC: >> >> 1. The IPSEC that is applied to all fragments must be exactly the >> same that would be applied to the same packet when fully >> assembled. Stephen> I agree that this would be ideal, but it would not be awful, Stephen> from a communication security perspective, if we applied Stephen> "better" protection to fragments. True from a comsec point of view. Not necessarily true from a legal compliance point of view, if you're subject to regulations that restrict the use of certain algorithms for certain traffic. I believe Tero made that point some time ago. paul From owner-ipsec@lists.tislabs.com Mon Mar 15 12:38: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 i2FKcfIT093649; Mon, 15 Mar 2004 12:38:41 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12052 Mon, 15 Mar 2004 14:55:17 -0500 (EST) To: ipsec@lists.tislabs.com CC: Tero Kivinen Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems In-Reply-To: Message from Tero Kivinen of "Mon, 15 Mar 2004 12:42:10 +0200." <16469.34946.246577.912093@fireball.acr.fi> References: <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040226095435.0208aa50@email> <200403051131.i25BV3ji006208@burp.tkv.asdf.org> <200403122216.i2CMGFJG016385@burp.tkv.asdf.org> <200403141340.i2EDeetm003016@burp.tkv.asdf.org> <16469.34946.246577.912093@fireball.acr.fi> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Mon, 15 Mar 2004 15:05:05 -0500 Message-ID: <16329.1079381105@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tero" == Tero Kivinen writes: >> Before going into details, just to restate my view of how dealing >> with fragments should be stated in the RFC: >> >> 1. The IPSEC that is applied to all fragments must be exactly the >> same that would be applied to the same packet when fully >> assembled. >> >> 2. Implementaion can limit support for IPSEC on fragments to >> policies that don't use port selectors. >> >> Above simple and clear, and does not lead to very convoluted >> additional specifications. Tero> I agree. The above is simple and it covers the most common Tero> cases (i.e. if you do not want to do the first option, then Tero> simply do not support fragments and port selectors). Also if Tero> your setup is such that option 1 is not possible (for example Tero> load balancing between multiple security gateways) do not Tero> allow port selectors or do not allow fragments. -- I concur. The requirements: 1) port-selectors 2) support fragments 3) do gateway or BITW are conflicting. Pick two. - -- ] 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 iQCVAwUBQFYMb4qHRg3pndX9AQEs0gP/XUtGc1c7TMWOS6C6lkd8gtr2a7C7F1Oj jUnxoUh/V038rVIQe54EgVjOTDa2Loa7/8poBz1RQITh4H9eBsA6DLL40S0rxOK1 dZaB0/aF0VCDvfIFdZprteEpa+sYNroXGL/hsPj5EermbrX8kLBbQNKqSLIJxMTr rE8kovD4AbM= =L3E9 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Mar 16 03:18:38 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 i2GBIc4u022537; Tue, 16 Mar 2004 03:18:38 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA03953 Tue, 16 Mar 2004 05:13: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: <16470.54798.104913.734982@fireball.acr.fi> Date: Tue, 16 Mar 2004 12:25:18 +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: <16329.1079381105@marajade.sandelman.ottawa.on.ca> References: <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040226095435.0208aa50@email> <200403051131.i25BV3ji006208@burp.tkv.asdf.org> <200403122216.i2CMGFJG016385@burp.tkv.asdf.org> <200403141340.i2EDeetm003016@burp.tkv.asdf.org> <16469.34946.246577.912093@fireball.acr.fi> <16329.1079381105@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 11 min X-Total-Time: 12 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson writes: > The requirements: > 1) port-selectors > 2) support fragments > 3) do gateway or BITW > > are conflicting. Pick two. Actually no. Change the 3rd requirement to: 3) do multipath gateway or BITW solution, where fragments of a packet can go out from different SGW. You can do gateways and BITWs without problems, but you cannot do that if you want to support cases where you have multiple SGWs and fragments of the packet can be split between those SGWs. How often have you seen that scenario? There are ways to get even that working, either make sure the all fragments end up to the same SGW (easy in the load-balancing case, simply make sure the balancer uses algorithm that will put all fragments to the same SGW every time, as there are other benefits for that those boxes usually try to do that anyways (i.e. they try to keep one TCP/IP stream to use the same path to get TCP/IP work better). If you cannot have that, then you would need communication between the boxes about the initial fragments. Again I think that we are now talking about the 0.01% case thus we can safely ignore it, and say that do whatever you like. So to rephrase that statement: If IPSEC policy decision (AH, ESP, bypass, drop) is applied to fragments where policy has tunnel mode port selectors, then all fragments must have exactly the same processing that would be applied to the same packet when fully assembled. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Tue Mar 16 06:50: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 i2GEovj9035879; Tue, 16 Mar 2004 06:50:57 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08789 Tue, 16 Mar 2004 08:58:50 -0500 (EST) Date: Tue, 16 Mar 2004 08:58:50 -0500 (EST) From: owner-ipsec@lists.tislabs.com Message-Id: <200403161358.IAA08789@lists.tislabs.com> 214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id OAA26118; Thu, 11 Mar 2 004 14:35:49 -0500 (EST) org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1B1RZZ-0005GG-00; Thu, 11 Mar 2004 09:54:09 -0500 Date: Thu, 11 Mar 2004 09:54:08 -0500 From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Cc: postmaster@lists.tislabs.com Subject: RESENT: Message from CFRG concerning proposed change in IKEv2 Message-ID: <20040311145408.GA11512@thunk.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline 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 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline It has come to our attention that for some reason this e-mail message from David McGrew mysteriously didn't get sent to the ipsec list mailing list, so I am resending it. I'm also cc'ing this note to the postmaster at lists.tislabs.com so they can investigate why this note didn't make it through. - Ted --FCuugMFkClbJLl1L Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from po14.mit.edu (po14.mit.edu [18.7.21.72]) by po14.mit.edu (Cyrus v2.1.5) with LMTP; Mon, 01 Mar 2004 10:48:35 -050 0 X-Sieve: CMU Sieve 2.2 Received: from pacific-carrier-annex.mit.edu by po14.mit.edu (8.12.4/4.7) id i21 FmY5u000184; Mon, 1 Mar 2004 10:48:34 -0500 (EST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id i21FmXHm00 7467 for ; Mon, 1 Mar 2004 10:48:33 -0500 (EST) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 01 Mar 2004 07:59:49 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171 .71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i21FmTuA002541; Mon, 1 Mar 2004 07:48:29 -0800 (PST) Received: from [10.34.251.102] (stealth-10-34-251-102.cisco.com [10.34.251.102]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AQT57036; Mon, 1 Mar 2004 07:46:57 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9FBFC5D4-6B97-11D8-A301-0003935495EC@cisco.com> Content-Transfer-Encoding: 7bit Cc: canetti , ipsec@lists.tislabs.com, cfrg@ietf.org, Hugo Krawczyk From: "David A. McGrew" Subject: Re: [Cfrg] Re: your mail Date: Mon, 1 Mar 2004 10:46:37 -0500 To: byfraser@cisco.com, "Theodore Ts'o" X-Mailer: Apple Mail (2.606) X-Spam-Score: -4.9 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Ted, Bard, please accept this terse summary as the CFRG consensus. Ran and I have heard it echoed both on and off of the list, without any significant contention. Best regards, 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. --FCuugMFkClbJLl1L-- From owner-ipsec@lists.tislabs.com Tue Mar 16 08:24: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 i2GGOEVA042210; Tue, 16 Mar 2004 08:24:14 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18065 Tue, 16 Mar 2004 10:42:07 -0500 (EST) Message-Id: <5.2.0.9.2.20040316104111.03852bd0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 16 Mar 2004 10:45:59 -0500 To: ipsec@lists.tislabs.com From: Russ Housley Subject: CFRG Recommendation: IKEv2 Key Derivation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The CFRG considered Hugo's comments on IKEv2 Key Derivation. They support the changes recommended by Hugo. For some reason, their posting to the IPsec mailing list has never appeared here. Russ = = = = = = = = = > >Ted, Barb, > >Please accept this terse summary as the CFRG consensus. Ran and I have >heard it echoed both on and off of the list, without any significant >contention. > >Best regards, > >David > >>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. > From owner-ipsec@lists.tislabs.com Tue Mar 16 10:35: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 i2GIZoAx052863; Tue, 16 Mar 2004 10:35:51 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04079 Tue, 16 Mar 2004 12:47:36 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Final editing changes to IKEv2 From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Tue, 16 Mar 2004 12:54:27 -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 The following represent the final changes that we believe the IPSEC working group has developed a consensus to make to IKEv2. If anyone has any problems to these set of changes, please make them known within 48 hours. Otherwise, they will represent editing instructions to the IKEv2 document editor before we submit this document to the Area Director for IETF Last Call. 1. Make the changes to IKEv2 cryptographic change which were proposed by Hugo, and which were signed off by CFRG: https://www1.ietf.org/mail-archive/working-groups/cfrg/current/msg00366.html 2. Add an additional round trip when utilizing EAP to avoid the ambiguity of what "after having sufficient information to compute the key" might mean. This is commonly done in most other applications that utilize EAP. http://www.vpnc.org/ietf-ipsec/mail-archive/msg02719.html 3. Add a notify message which specifies whether or not TFC padding is done in ESPv2. http://www.vpnc.org/ietf-ipsec/mail-archive/msg02695.html A suggestion has has been made for efficiency's sake that sense of the proposal made in the above URL be reversed, since the expectation is that normally the RFC padding will be supported: ESP_TFC_PADDING_NOT_SUPPORTED 16394 This notification asserts that the sending endpoint will NOT accept packets that contain Flow Confidetiality (TFC) padding. 4. Clarification about encoding the icmp type/code (bit-packing issue) from Charlie Lynn http://www.vpnc.org/ietf-ipsec/mail-archive/msg02701.html 5. Make the reference to UDP encaps I-D be normative, and change reference to the NAT Requirements I-D be informative. http://www.vpnc.org/ietf-ipsec/mail-archive/msg02607.html 6. Incorporate the list and description of the IANA registries found in draft-ietf-ipsec-ikev2-iana-01.txt into IANA Considerations section of the IKEv2 I-D. In adddition, include as the allocation rules for all of the IKEv2 registries the policy "Expert Review" required, as defined in RFC2434. The actual initial contents of the registries themselves will *not* be included in IANA considerations section. Those will be provided to the IANA via the draft-ietf-ipsec-ikev2-iana I-D. 7. Update copyright statement and IPR statements per new texts found in RFC 3667-3669 Ted and Barbara From owner-ipsec@lists.tislabs.com Tue Mar 16 11:19:47 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 i2GJJgtp054964; Tue, 16 Mar 2004 11:19:42 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17295 Tue, 16 Mar 2004 13:22:56 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Remaining open issues for RFC-2401bis From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Tue, 16 Mar 2004 13:29:34 -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 an attempt to try to drive rfc2401bis to closure, the following represent the open issues with the draft. Please let us know if we have missed anything. As you will note, we are starting a working-group last call on the new process model, and selector name clarification issues for the end of the week. For the rest of the issues, we would like to encourage the working group to focus the discussion and try to come to a consensus as soon as possible. We are am particularly concerned by the fact that there has been essentially no discussion for issue #91 (Incoming ICMP handling). If we do not get any support for issue #91, we propose that we revert to RFC 2401 text with respect to this issue. - Ted and Barbara 1. New processing model (issues #44, #45) There appears to be current consensus on the list about the overall approach, although there have been some requests to clarify the text. If any disagree with the general direction utilized by the processing model, please make your concerns known by the end of the week. At that time, issues #44 and #45 will be marked as closed in the roundup database. People who have suggestions on how to clarify any part of the specification are encouraged to continue make them. 2. fragmentation handling (issue #92, #88) Actively being discussed. Steve Kent is preparing a five page exposition on the issues that will hopefully help to focus the discussion. 3. Incoming ICMP error message handling (issue #91) There has currently been no discussion on issue #91. If we don't get movement, we may need to go back to the RFC 2401 text, which makes it be a local matter. If so, we will need to add back the path mtu handling text which was dropped in the -01 version of the ID. 4. selector name clarification (issue #93) Seems straightforward, and there has been no disagreement on the mailing list. If any disagree with the text suggested by Karen on February 25th, please make your conerns known by the end of the week. 5. Defined ICMP response to unprotected inbound packets that require protection. (Issue #83) This was initially raised by Steve Kent and Karen Seo, and accepted by the working group. It was later withdrawn by Steve because of performance concerns in high-speed applications. Possible outcomes: 1. The working group explicitly chooses to drop this issue. In this case, what to do in the case where an inbound packet is dropped is a local issue, with the text being completely silent about what should happen when a packet is discarded. 2. The "SHOULD be capable of generating an ICMP message" is changed to "MAY", with the definition of the ICMP packet to be sent (should the implementation so choose and/or is configured to do so) being defined in RFC 2401bis. From owner-ipsec@lists.tislabs.com Tue Mar 16 21:42: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 i2H5gDIt090250; Tue, 16 Mar 2004 21:42:13 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA02083 Tue, 16 Mar 2004 18:05:00 -0500 (EST) To: Tero Kivinen cc: ipsec@lists.tislabs.com Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems In-Reply-To: Message from Tero Kivinen of "Tue, 16 Mar 2004 12:25:18 +0200." <16470.54798.104913.734982@fireball.acr.fi> References: <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040226095435.0208aa50@email> <200403051131.i25BV3ji006208@burp.tkv.asdf.org> <200403122216.i2CMGFJG016385@burp.tkv.asdf.org> <200403141340.i2EDeetm003016@burp.tkv.asdf.org> <16469.34946.246577.912093@fireball.acr.fi> <16329.1079381105@marajade.sandelman.ottawa.on.ca> <16470.54798.104913.734982@fireball.acr.fi> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Tue, 16 Mar 2004 18:16:46 -0500 Message-ID: <20808.1079479006@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tero" == Tero Kivinen writes: >> The requirements: >> 1) port-selectors >> 2) support fragments >> 3) do gateway or BITW >> >> are conflicting. Pick two. Tero> Actually no. Change the 3rd requirement to: Tero> 3) do multipath gateway or BITW solution, where fragments of a Tero> packet can go out from different SGW. I'm assuming that assembling fragments at either end for checking is too expensive for high speed boxes that won't wish to queue. That's what we were told on the list. Tero> You can do gateways and BITWs without problems, but you cannot Tero> do that if you want to support cases where you have multiple Tero> SGWs and fragments of the packet can be split between those SGWs. Right, I agree. But aren't the gateways/BITWs going to assemble the fragments in this case? Tero> How often have you seen that scenario? I have yet to see it. All redundant situations I've seen have a warm spare, ready to take over. No load balancing. Tero> So to rephrase that statement: Tero> If IPSEC policy decision (AH, ESP, bypass, drop) is applied to Tero> fragments where policy has tunnel mode port selectors, then all Tero> fragments must have exactly the same processing that would be applied Tero> to the same packet when fully assembled. I agree. - -- ] 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 iQCVAwUBQFeK3YqHRg3pndX9AQFMrQQAhVY4gN5KbOth0rcdrzoCuAiucR6zIY6N EL+Gi1G9Nz2tu/JLpdmV6VaKM2r5jtgcC32JnLiXs4i3fBaqFbSRq9bPygSaKLBu 4R8ZY7mZC2yocDM0fnHAgeIFvagnYVlMzAAi+wr/mHNhow+0+VWi8zBlMjF+XsWH 2ECIjyjygB8= =qjPJ -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Mar 17 02:55: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 i2HAtDkJ089744; Wed, 17 Mar 2004 02:55:14 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA25838 Wed, 17 Mar 2004 04:59:46 -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: <16472.9336.218048.615149@fireball.acr.fi> Date: Wed, 17 Mar 2004 12:12:08 +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: <20808.1079479006@marajade.sandelman.ottawa.on.ca> References: <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040226095435.0208aa50@email> <200403051131.i25BV3ji006208@burp.tkv.asdf.org> <200403122216.i2CMGFJG016385@burp.tkv.asdf.org> <200403141340.i2EDeetm003016@burp.tkv.asdf.org> <16469.34946.246577.912093@fireball.acr.fi> <16329.1079381105@marajade.sandelman.ottawa.on.ca> <16470.54798.104913.734982@fireball.acr.fi> <20808.1079479006@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 18 min X-Total-Time: 18 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson writes: > I'm assuming that assembling fragments at either end for checking is > too expensive for high speed boxes that won't wish to queue. I don't really belive that. I think there are boxes out there that can handle 100 MBit/s or even 1 Gbit/s NFS traffic without problems. All the packets there are fragments (8kB or similar UDP packets), thus they can reassembly there without problems, and propably even without any hardware help. I do not belive it is that hard to do the partial reassembly even in faster links, especially as it will need special hardware to do the IPsec encryption at those speeds, and adding partial reassembly for those few packets that really are fragmented shouldn't be problem. > That's what we were told on the list. Ok, I will tell you otherwise, do you belive me :-) Anyways, if your box is too slow to handle the traffic at full speed, when there are couple of fragments around, then you either advertise it with lower speed (not very likely), or you simply ignore the problem, and say that we do not support fragments with port selectors. > Tero> You can do gateways and BITWs without problems, but you cannot > Tero> do that if you want to support cases where you have multiple > Tero> SGWs and fragments of the packet can be split between those SGWs. > Right, I agree. But aren't the gateways/BITWs going to assemble the > fragments in this case? They need to do partial reassembly, meaning that in normal case (fragments in order, no dropped packets), the cost is 4+4+2+4 (src ip, dst ip, id, used spi) bytes per fragment for few seconds. If you are using 1GBit/s link and sending 8 kB packets fragmented to 6 pieces, that will mean 16k packet/s. If we assume the total memory needed per fragment is 32 bytes, and you want to keep them full ttl seconds (say 64 seconds), then you will need 32 MB of buffers to store that information. If only 1% of packets are fragments, and they all miss first fragment for some reason, then you need 66 MB of buffer space to store the non-first fragments for 64 seconds. Does anybody have any statistics how much of the packets in the net are fragmented? > Tero> If IPSEC policy decision (AH, ESP, bypass, drop) is applied to > Tero> fragments where policy has tunnel mode port selectors, then all > Tero> fragments must have exactly the same processing that would be applied > Tero> to the same packet when fully assembled. > > I agree. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Wed Mar 17 06:13: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 i2HEDIa5006245; Wed, 17 Mar 2004 06:13:19 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA29820 Wed, 17 Mar 2004 08:21:22 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <87F811B4-7817-11D8-9FD5-000A95834BAA@checkpoint.com> Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com From: Yoav Nir Subject: Re: Final editing changes to IKEv2 Date: Wed, 17 Mar 2004 15:32:26 +0200 To: "Theodore Ts'o" X-Mailer: Apple Mail (2.613) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is one message that proposed two options, and did not receive any responses. Is this a consensus? Anyway, EAP is originally a PPP protocol. The last message (success/failure) is not meant to be reliable. If it is lost, its existence can be inferred in PPP by what happens next (IPCP in case of success, or LCP terminate in case of failure). There is never any response to the EAP success message, so there is no need for the IKE machine to send it to the client as soon as it is received. If the EAP machine first sends the Authentication success, and afterwards sends the key (or the reverse), the IKE machine should buffer whichever comes first until the other arrives, and then send both the EAP success and the auth payload in one message just as it is specified in -12. It should be possible to resolve the ambiguity by saying that the client sends the AUTH payload as soon as it can, while the server sends it in the last packet along with the Success/Failure message. I don't see a reason to add an extra roundtrip. On Mar 16, 2004, at 7:54 PM, Theodore Ts'o wrote: > > The following represent the final changes that we believe the IPSEC > working group has developed a consensus to make to IKEv2. If anyone > has any problems to these set of changes, please make them known within > 48 hours. Otherwise, they will represent editing instructions to the > IKEv2 document editor before we submit this document to the Area > Director for IETF Last Call. > > 2. Add an additional round trip when utilizing EAP to avoid the > ambiguity of what "after having sufficient information to compute > the > key" might mean. This is commonly done in most other applications > that utilize EAP. > > http://www.vpnc.org/ietf-ipsec/mail-archive/msg02719.html > From owner-ipsec@lists.tislabs.com Wed Mar 17 06:13:21 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 i2HEDIvB006244; Wed, 17 Mar 2004 06:13:19 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA26165 Wed, 17 Mar 2004 08:09:10 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Final editing changes to IKEv2 Date: Wed, 17 Mar 2004 13:14:15 -0000 Message-ID: <579E83556A36E44EB2945CCE990B3174011DD343@EUR-MSG-02.europe.corp.microsoft.com> Thread-Topic: Final editing changes to IKEv2 Thread-Index: AcQLguXGarmeKOSzRmqTcen1hkNHjAAndStQ From: "Michael Roe" To: X-OriginalArrivalTime: 17 Mar 2004 13:14:12.0413 (UTC) FILETIME=[BD642ED0:01C40C21] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id IAA26098 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 4. Clarification about encoding the icmp type/code > (bit-packing issue) from > Charlie Lynn > > http://www.vpnc.org/ietf-ipsec/mail-archive/msg02701.html > > I agree with this change. But Charlie's original message also asked for clarification of how the mobility header type is encoded. I think we should adopt Charlie's suggestion for encoding the mobility header type as well (note that it isn't obvious, so interoperability problems are likely if it isn't described) >> 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). Thanks! Mike From owner-ipsec@lists.tislabs.com Wed Mar 17 09:50: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 i2HHoYfY021241; Wed, 17 Mar 2004 09:50:34 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00039 Wed, 17 Mar 2004 11:47:54 -0500 (EST) To: ipsec@lists.tislabs.com cc: Tero Kivinen Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems In-Reply-To: Message from Tero Kivinen of "Wed, 17 Mar 2004 12:12:08 +0200." <16472.9336.218048.615149@fireball.acr.fi> References: <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040226095435.0208aa50@email> <200403051131.i25BV3ji006208@burp.tkv.asdf.org> <200403122216.i2CMGFJG016385@burp.tkv.asdf.org> <200403141340.i2EDeetm003016@burp.tkv.asdf.org> <16469.34946.246577.912093@fireball.acr.fi> <16329.1079381105@marajade.sandelman.ottawa.on.ca> <16470.54798.104913.734982@fireball.acr.fi> <20808.1079479006@marajade.sandelman.ottawa.on.ca> <16472.9336.218048.615149@fireball.acr.fi> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Wed, 17 Mar 2004 11:37:34 -0500 Message-ID: <902.1079541454@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tero" == Tero Kivinen writes: Tero> Michael Richardson writes: >> I'm assuming that assembling fragments at either end for checking >> is too expensive for high speed boxes that won't wish to queue. Tero> I don't really belive that. I think there are boxes out there At 1Gb/s, I believe it. At 10Gb/s, it is presently hard. Not impossible, but hard. Once 10Gb/s is solved, it will be hard at 40Gb/s (assuming OC768 is the next step). But, if in the functional design specification, we say: 1) cope with fragments 2) have port-selectors 3) be BITW/gateway pick two, is the *requirement*, then vendors can build the 40Gb/s box tomorrow that can't do port-selectors, and the one that can, the following week. Tero> that can handle 100 MBit/s or even 1 Gbit/s NFS traffic Tero> without problems. All the packets there are fragments (8kB or There is a reason that NFS appliance want to move to TCP rather than UDP (and NFSv4 supports that). There are lots of TCP offload engines out there, and probably some that can do IPsec as well. With PMTU they can optimize the packet size, and they don't have to deal with fragments. Further, if they in-board IPsec, then they aren't a gateway/BITW, so they can make sure that every fragment gets the same treatment. Tero> Does anybody have any statistics how much of the packets in Tero> the net are fragmented? It varries by which part of the network you look at. (And I recall a discussion like this at my desk with you, TMO, TATU in fall of 1997...) The backbone doesn't have a lot of UDP traffic, except for DNS, which is kept artificially below the fragmentation limit. Enterprise networks that might be extended over IPsec VPNs are a different matter. SANs that get extended might have further different properties. - -- ] 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 iQCVAwUBQFh+zYqHRg3pndX9AQH2IQQA3em4FdcKqij20QderSMZ8lRhUCpSFdow vyujMUb6rWSb4xCosf22cm3tyEn3x+Xn79ZkOXpCFb7pWsXNixFRwj0b7XyOy5um QWDcQmzar4NR+kj1h5e+UHf0BMZcu5cy7+ueV+E/jahdoc0WrLztdAfVTjKIap6S 8nx4GonZazg= =d7gx -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Mar 17 12:24:38 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 i2HKOZZX034173; Wed, 17 Mar 2004 12:24:36 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13967 Wed, 17 Mar 2004 14:23:59 -0500 (EST) Message-Id: <5.2.0.9.2.20040317142349.03955638@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 17 Mar 2004 14:26:24 -0500 To: Tero Kivinen From: Russ Housley Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems Cc: ipsec@lists.tislabs.com In-Reply-To: <16472.9336.218048.615149@fireball.acr.fi> References: <20808.1079479006@marajade.sandelman.ottawa.on.ca> <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040226095435.0208aa50@email> <200403051131.i25BV3ji006208@burp.tkv.asdf.org> <200403122216.i2CMGFJG016385@burp.tkv.asdf.org> <200403141340.i2EDeetm003016@burp.tkv.asdf.org> <16469.34946.246577.912093@fireball.acr.fi> <16329.1079381105@marajade.sandelman.ottawa.on.ca> <16470.54798.104913.734982@fireball.acr.fi> <20808.1079479006@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You may be able to find some data at http://www.caida.org. Steve Bellovin and I are not convinced that general numbers are really going to provide much insight. NFS, for example, is a prime user of fragments, but one will not see much NFS traffic on the wide-area Internet. However, a VPN might be a very different story. Russ At 12:12 PM 3/17/2004 +0200, Tero Kivinen wrote: >Does anybody have any statistics how much of the packets in the net >are fragmented? From owner-ipsec@lists.tislabs.com Wed Mar 17 12:27: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 i2HKRuQS034836; Wed, 17 Mar 2004 12:27:56 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16262 Wed, 17 Mar 2004 10:58:29 -0500 (EST) Message-Id: <5.2.0.9.0.20040317104825.021ecdf0@localhost> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 17 Mar 2004 11:10:13 -0500 To: Tero Kivinen , Michael Richardson From: Mark Duffy Subject: Re: Traffic selectors, fragments, ICMP messages and security policy problems Cc: ipsec@lists.tislabs.com In-Reply-To: <16472.9336.218048.615149@fireball.acr.fi> References: <20808.1079479006@marajade.sandelman.ottawa.on.ca> <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040226095435.0208aa50@email> <200403051131.i25BV3ji006208@burp.tkv.asdf.org> <200403122216.i2CMGFJG016385@burp.tkv.asdf.org> <200403141340.i2EDeetm003016@burp.tkv.asdf.org> <16469.34946.246577.912093@fireball.acr.fi> <16329.1079381105@marajade.sandelman.ottawa.on.ca> <16470.54798.104913.734982@fireball.acr.fi> <20808.1079479006@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:12 PM 3/17/2004 +0200, Tero Kivinen wrote: >They need to do partial reassembly, meaning that in normal case >(fragments in order, no dropped packets), the cost is 4+4+2+4 (src ip, >dst ip, id, used spi) bytes per fragment for few seconds. If you are >using 1GBit/s link and sending 8 kB packets fragmented to 6 pieces, >that will mean 16k packet/s. If we assume the total memory needed per >fragment is 32 bytes, and you want to keep them full ttl seconds (say >64 seconds), then you will need 32 MB of buffers to store that >information. Ah, but if the fragments do not arrive in order, or some are missing, the situation is different, much different. Even though this might not be naturally common, it happens sometimes. And, it might be common as a malicious attack. Devices would have to be built to handle it. >If only 1% of packets are fragments, and they all miss first fragment >for some reason, then you need 66 MB of buffer space to store the >non-first fragments for 64 seconds. > >Does anybody have any statistics how much of the packets in the net >are fragmented? I believe the 1% number is very low for IPsec packets, due to the frequency of adding ESP to 1500 byte cleartext packets and then transmitting the ESP packets over ethernet. And, the typical % of fragmented packets is probably irrelevant anyway; malicious attacks are a more serious consideration. I stand by the statement that requiring logical "reassembly" is anathema to high-speed implementations. --Mark From owner-ipsec@lists.tislabs.com Wed Mar 17 16:35:27 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 i2I0ZPst080572; Wed, 17 Mar 2004 16:35:25 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA23874 Wed, 17 Mar 2004 18:50:52 -0500 (EST) Date: Wed, 17 Mar 2004 18:59:08 -0500 From: "Theodore Ts'o" To: Michael Roe Cc: ipsec@lists.tislabs.com Subject: Re: Final editing changes to IKEv2 Message-ID: <20040317235908.GC3484@thunk.org> References: <579E83556A36E44EB2945CCE990B3174011DD343@EUR-MSG-02.europe.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <579E83556A36E44EB2945CCE990B3174011DD343@EUR-MSG-02.europe.corp.microsoft.com> 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 Wed, Mar 17, 2004 at 01:14:15PM -0000, Michael Roe wrote: > I agree with this change. But Charlie's original message also asked > for clarification of how the mobility header type is encoded. > I think we should adopt Charlie's suggestion for encoding the mobility > header type as well (note that it isn't obvious, so interoperability > problems are likely if it isn't described) Currently IKEv2 specifies that for ESP and AH, SA's always exist in pairs. So there's a higher level issue which is whether or not unidirectional traffic selectors should be supported in the first place. I'll note that Charlie Lynn's suggestion (setting the responder's traffic selectors to Opaque) doesn't seem to make sense since whether or not the selectors should be unidrectional or not is orthoganal to what the responder's ip port/address range would be. In any case, adding support for a unidrectional traffic selector would appear to be adding new feature to IKEv2, at a time when we're trying come to closure on the specification. Is this something that has to be done in the base spec, or should we do this as a later extension to IKEv2? - Ted From owner-ipsec@lists.tislabs.com Thu Mar 18 07:00:38 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 i2IF0cwN061737; Thu, 18 Mar 2004 07:00:38 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27746 Thu, 18 Mar 2004 09:18:57 -0500 (EST) From: ebooth@cisco.com Date: Thu, 18 Mar 2004 15:01:46 +0200 To: ipsec@lists.tislabs.com Subject: Re: Document Message-ID: MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk

From owner-ipsec@lists.tislabs.com Thu Mar 18 07:03:57 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 i2IF3rxn061908; Thu, 18 Mar 2004 07:03:57 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27723 Thu, 18 Mar 2004 09:18:39 -0500 (EST) From: ebooth@cisco.com Date: Thu, 18 Mar 2004 14:59:29 +0200 To: ipsec@lists.tislabs.com Subject: Re: Document Message-ID: MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk

From owner-ipsec@lists.tislabs.com Thu Mar 18 12:26: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 i2IKQdPr084639; Thu, 18 Mar 2004 12:26:40 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA23432 Thu, 18 Mar 2004 08:16:10 -0500 (EST) From: Pasi.Eronen@nokia.com X-Scanned: Thu, 18 Mar 2004 15:21:50 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE 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: Final editing changes to IKEv2 Date: Thu, 18 Mar 2004 15:21:36 +0200 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C39DD@esebe023.ntc.nokia.com> Thread-Topic: Final editing changes to IKEv2 Thread-Index: AcQMLV+ykNxB3J8+Q6ijbolLuxi8nAAu46eQ To: , Cc: X-OriginalArrivalTime: 18 Mar 2004 13:21:38.0116 (UTC) FILETIME=[F176D040:01C40CEB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id IAA23400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Having the responder send the AUTH payload and EAP-Success in the same message is OK. However, this does not solve the initiator's case. "As soon as it can" is still a bit ambigous, and in draft -12 the initiator sends the AUTH payload _before_ receiving EAP-Success. But EAP peer state machine currently "exports" the key only _after_ receiving EAP-Success. So it seems that we need to either slightly change how EAP works or add another roundtrip. Both options are certainly feasible, but IMHO the latter requires less work... Best regards, Pasi > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of ext Yoav Nir > Sent: Wednesday, March 17, 2004 3:32 PM > To: Theodore Ts'o > Cc: ipsec@lists.tislabs.com > Subject: Re: Final editing changes to IKEv2 > > > > This is one message that proposed two options, and did not > receive any > responses. Is this a consensus? > > Anyway, EAP is originally a PPP protocol. The last message > (success/failure) is not meant to be reliable. If it is lost, its > existence can be inferred in PPP by what happens next (IPCP > in case of > success, or LCP terminate in case of failure). There is never any > response to the EAP success message, so there is no need for the IKE > machine to send it to the client as soon as it is received. > > If the EAP machine first sends the Authentication success, and > afterwards sends the key (or the reverse), the IKE machine should > buffer whichever comes first until the other arrives, and then send > both the EAP success and the auth payload in one message just > as it is > specified in -12. > > It should be possible to resolve the ambiguity by saying that the > client sends the AUTH payload as soon as it can, while the > server sends > it in the last packet along with the Success/Failure message. > I don't > see a reason to add an extra roundtrip. > > On Mar 16, 2004, at 7:54 PM, Theodore Ts'o wrote: > > > > > The following represent the final changes that we believe the IPSEC > > working group has developed a consensus to make to IKEv2. If anyone > > has any problems to these set of changes, please make them > known within > > 48 hours. Otherwise, they will represent editing > instructions to the > > IKEv2 document editor before we submit this document to the Area > > Director for IETF Last Call. > > > > 2. Add an additional round trip when utilizing EAP to avoid the > > ambiguity of what "after having sufficient information > to compute > > the > > key" might mean. This is commonly done in most other > applications > > that utilize EAP. > > > > http://www.vpnc.org/ietf-ipsec/mail-archive/msg02719.html > > > > From owner-ipsec@lists.tislabs.com Thu Mar 18 13:10: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 i2ILAFho087490; Thu, 18 Mar 2004 13:10:16 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05488 Thu, 18 Mar 2004 15:31:31 -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: <16474.2569.140956.564782@fireball.acr.fi> Date: Thu, 18 Mar 2004 22:43:53 +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.20040318093600.021c3808@email> References: <5.2.0.9.0.20040317104825.021ecdf0@localhost> <20808.1079479006@marajade.sandelman.ottawa.on.ca> <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040226095435.0208aa50@email> <200403051131.i25BV3ji006208@burp.tkv.asdf.org> <200403122216.i2CMGFJG016385@burp.tkv.asdf.org> <200403141340.i2EDeetm003016@burp.tkv.asdf.org> <16469.34946.246577.912093@fireball.acr.fi> <16329.1079381105@marajade.sandelman.ottawa.on.ca> <16470.54798.104913.734982@fireball.acr.fi> <5.2.0.9.0.20040318093600.021c3808@email> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 25 min X-Total-Time: 24 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark Duffy writes: > At 11:44 AM 3/18/2004 +0200, Tero Kivinen wrote: > > > I believe the 1% number is very low for IPsec packets, due to the > > frequency > > > of adding ESP to 1500 byte cleartext packets and then transmitting the ESP > > > packets over ethernet. > > > >That fragmentation happens after IPsec, thus it not concern here. We > >are now talking about the packets arriving to the SGW which are > >already fragmented at that point. If PMTU etc works perfectly there > >should not ever be any TCP packets that are fragmented, and most of > >the UDP traffic is for small packets, with only exception of the NFS > >etc. > > That fragmentation can happen before IPsec, and is highly likely to in > high-speed implementations. I do not think ESP inside ESP it that common case, even in high-speed implementations. If the fragmentation is because of the ESP header being added, then it happens INSIDE SGW, thus the SGW will have the complete packet to base the policy decisions on. Actually SGW has already done the policy decision because it knows it is going to apply ESP on the packet. I repeat, that fragmentation is not in question here. > And PMTU discovery does not work perfectly. I read one of those articles (http://www.caida.org/outreach/papers/2002/Frag/) found from the http://www.caida.org/, and it said the fragmentation is about 0.2-0.8 % of the packets and around 0.6%-1.6% of bytes in the core network. 89% of the fragmented packets arrived in order and ware complete. 7.8% arrived in the reverse order, and 1.6% had some out of order fragments. That leaves 1.6% of fragmented packets in state which could not be reassembled (and which might be missing the first fragment). They also assumed 15 seconds for reassembly timeout, I used 64 seconds in my previous calculations, thus my calculations ware 4 times too big. There was also very little TCP fragmentation (1.6% of bytes in fragmented packets, meaning around 0.03% of total traffic), most of the fragments was because UDP (72% of fragmented bytes), ICMP (12% of fragmented bytes) etc. Those numbers will be different when checking the traffic inside the VPN, but I do not think the number of fragments are going to change that much, unless you run NFS over UDP over the VPN. Those numbers can be used to calculate the good sizes for the reassembly queues etc, so that it works fine under normal load. > I agree with your statement here in a general sense and indeed that is how > many things work. But here there are several options on the table that > would allow the protocol to be *more* resistant to attack, such that > legitimate fragments do not suffer as a result of such an attack. (The > options I mean are the approaches that do not call for an IPsec > implementation to "reassemble" fragmented packets.) Yes, if we drop all fragments, then legitimate fragments does not even notice if there is attack going on or not :-) Note, that if there is any attacks using fragments, then that attack is coming from the inside of the VPN, thus you might have other problems in that case too. > I can accept an approach where a SG can do either port-selectors or > fragments. I agree that. We shouldn't make the fragmentation processing with port selectors MUST, you can simply not support port-selectors or not support fragments, but if you implement then both, I think we want it to have identical security properties than normal traffic. > However, I would prefer to do both, without reassembly. This > could be accomplished by several means that have been discussed on this > list including having a separate SA for fragments, or allowing non-initial > fragments to be sent under a different policy entry than other packets > (e.g. one with port selectors of "opaque".) I.e. you propose using different policy for parts of the traffic. I consider that a security hole. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Thu Mar 18 15:39:32 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 i2INdUCf098649; Thu, 18 Mar 2004 15:39:30 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13537 Thu, 18 Mar 2004 17:53:30 -0500 (EST) Message-Id: <5.2.0.9.0.20040318173814.040a3d28@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 18 Mar 2004 17:59:52 -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: <16474.2569.140956.564782@fireball.acr.fi> References: <5.2.0.9.0.20040318093600.021c3808@email> <5.2.0.9.0.20040317104825.021ecdf0@localhost> <20808.1079479006@marajade.sandelman.ottawa.on.ca> <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040226095435.0208aa50@email> <200403051131.i25BV3ji006208@burp.tkv.asdf.org> <200403122216.i2CMGFJG016385@burp.tkv.asdf.org> <200403141340.i2EDeetm003016@burp.tkv.asdf.org> <16469.34946.246577.912093@fireball.acr.fi> <16329.1079381105@marajade.sandelman.ottawa.on.ca> <16470.54798.104913.734982@fireball.acr.fi> <5.2.0.9.0.20040318093600.021c3808@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:43 PM 3/18/2004 +0200, Tero Kivinen wrote: >Mark Duffy writes: > > At 11:44 AM 3/18/2004 +0200, Tero Kivinen wrote: > > > > I believe the 1% number is very low for IPsec packets, due to the > > > frequency > > > > of adding ESP to 1500 byte cleartext packets and then transmitting > the ESP > > > > packets over ethernet. > > > > > >That fragmentation happens after IPsec, thus it not concern here. We > > >are now talking about the packets arriving to the SGW which are > > >already fragmented at that point. If PMTU etc works perfectly there > > >should not ever be any TCP packets that are fragmented, and most of > > >the UDP traffic is for small packets, with only exception of the NFS > > >etc. > > > > That fragmentation can happen before IPsec, and is highly likely to in > > high-speed implementations. > >I do not think ESP inside ESP it that common case, even in high-speed >implementations. If the fragmentation is because of the ESP header >being added, then it happens INSIDE SGW, thus the SGW will have the >complete packet to base the policy decisions on. Actually SGW has >already done the policy decision because it knows it is going to apply >ESP on the packet. I was not talking about ESP in ESP. I was talking about this: . SG receives large (e.g. 1500 B) plaintext packet. . SG policy says encrypt. . Path MTU from SG to remote SG is known to be 1500 B. . SG does "red-side" fragmentation (of plaintext pkt) to avoid need to reassemble at remote SG . SG encrypts each fragment. . Yes, SG has the complete packet and *could* use the port selectors to find the policy to use for all fragments. But since the receiver (assuming it does not do the pseudo-reassemble) will evaluate the SPD for non-initial fragments with opaque ports, the sender should do so too. That way the sender and receiver are treating the non-initial fragments the same. I believe this is the behavior RFC 2401 calls for in sect. 4.4.2. My point here is still that the percentage of packets at the receiving SG that are fragments may be substantial, since the fragmentation is a direct result of the IPsec overhead. --Mark From owner-ipsec@lists.tislabs.com Thu Mar 18 16:22: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 i2J0MIU8001264; Thu, 18 Mar 2004 16:22:18 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16695 Thu, 18 Mar 2004 18:43:32 -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: <16474.14033.611171.786006@fireball.acr.fi> Date: Fri, 19 Mar 2004 01:54:57 +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.20040318173814.040a3d28@email> References: <5.2.0.9.0.20040318093600.021c3808@email> <5.2.0.9.0.20040317104825.021ecdf0@localhost> <20808.1079479006@marajade.sandelman.ottawa.on.ca> <5.2.0.9.0.20040225161626.020c34e0@email> <5.2.0.9.0.20040226095435.0208aa50@email> <200403051131.i25BV3ji006208@burp.tkv.asdf.org>