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> <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.20040318173814.040a3d28@email> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 8 min X-Total-Time: 7 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark Duffy writes: > . SG receives large (e.g. 1500 B) plaintext packet. > . SG policy says encrypt. And at that point SG policy also says, that use this SA for the traffic I assume? > . 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. using the SA selected earlier, which means that each fragment will be sent inside the same SA as I proposed. Do you propose that SG should do second policy lookup at that point, to find out how to send the fragments? > . 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. Wasn't the red-side fragmentation forbidden in the RFC2401? I think it was added only in rfc2401bis, or do I remember incorrectly? At least we have issue 88 that seems to change the rfc2401bis so that it allows red-side fragmentation. Actually red-side fragmentation seems to be only usefull if the responder does not care about checking the non-first fragments. If the responder still wants to verify that all fragments match the policy, then red-side fragmentation does not help. > 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. The better option would be implement proper path MTU discovery in the SG, i.e. send packet too big with suitable smaller mtu to the sender. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Thu Mar 18 17:47:23 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J1lL5S007216; Thu, 18 Mar 2004 17:47:21 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA23809 Thu, 18 Mar 2004 20:04:39 -0500 (EST) From: uri@lucent.com Date: Fri, 19 Mar 2004 09:15:30 +0800 To: ipsec@lists.tislabs.com Subject: Fax Message Received 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 17:50: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 i2J1o09H007407; Thu, 18 Mar 2004 17:50:01 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA24136 Thu, 18 Mar 2004 20:08:36 -0500 (EST) From: uri@lucent.com Date: Fri, 19 Mar 2004 09:16:19 +0800 To: ipsec@lists.tislabs.com Subject: Re: Incoming Fax 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 17:57:07 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 i2J1v7qZ007710; Thu, 18 Mar 2004 17:57:07 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA25282 Thu, 18 Mar 2004 20:18:46 -0500 (EST) From: "Bora Akyol" To: "'Mark Duffy'" , "'Tero Kivinen'" Cc: "'Michael Richardson'" , Subject: RE: Traffic selectors, fragments, ICMP messages and security policy problems Date: Thu, 18 Mar 2004 17:30:37 -0800 Message-ID: <003901c40d51$c8235f90$070a0a0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <5.2.0.9.0.20040318173814.040a3d28@email> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark Can you please qualify what you mean by high speed and also how many tunnels at that speed? Do you mean 1Gbps, 10 Gbps or 100 Gbps? How many tunnels at that speed and packet size. Once we define what "high speed" means, hopefully we can get a good understanding of what are the issues that are detrimental to the high speed implementation. Thanks Bora From owner-ipsec@lists.tislabs.com Thu Mar 18 20:10: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 i2J4ABgH017401; Thu, 18 Mar 2004 20:10:11 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA07551 Thu, 18 Mar 2004 22:29:34 -0500 (EST) From: uri@lucent.com Date: Thu, 18 Mar 2004 23:24:32 +0800 To: ipsec@lists.tislabs.com Subject: Encrypted 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 21:11:08 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 i2J5B2PS022112; Thu, 18 Mar 2004 21:11:03 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA14628 Thu, 18 Mar 2004 23:25:25 -0500 (EST) Message-Id: <5.2.0.9.0.20040318093600.021c3808@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 18 Mar 2004 10:00:15 -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: <16473.28530.844843.922779@fireball.acr.fi> 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.20040317104825.021ecdf0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:44 AM 3/18/2004 +0200, Tero Kivinen wrote: >Mark Duffy writes: > > >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. > >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. And PMTU discovery does not work perfectly. > > And, the typical % of fragmented packets is > > probably irrelevant anyway; malicious attacks are a more serious > > consideration. > >The typical % of fragmented packets is important, as we need to make >sure the protocol works fine in normal case. If there is an attacker, >we simply need to make sure the protocol can still work, and it does >not crash or run out of memory, but the performance does not have to >be optimal (i.e. we might want to drop some of the non-first fragments >in those cases, just like the normal host reassembly will do >currently). 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.) > > I stand by the statement that requiring logical "reassembly" is > anathema to > > high-speed implementations. > >And you still claim that we do need port-selectors and fragments in >those high-speed implementations? I can accept an approach where a SG can do either port-selectors or fragments. 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".) --Mark From owner-ipsec@lists.tislabs.com Thu Mar 18 22:05: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 i2J64o93027851; Thu, 18 Mar 2004 22:04:50 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA18368 Fri, 19 Mar 2004 00:06:52 -0500 (EST) Message-Id: <5.2.0.9.0.20040318233012.00a95e00@localhost> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 19 Mar 2004 00:16:11 -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.14033.611171.786006@fireball.acr.fi> References: <5.2.0.9.0.20040318173814.040a3d28@email> <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.20040318173814.040a3d28@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 01:54 AM 3/19/2004 +0200, Tero Kivinen wrote: >Mark Duffy writes: > > . SG receives large (e.g. 1500 B) plaintext packet. > > . SG policy says encrypt. > >And at that point SG policy also says, that use this SA for the >traffic I assume? > > > . 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. > >using the SA selected earlier, which means that each fragment will be >sent inside the same SA as I proposed. not necessarily the same SA, see below ("Yes, SG has...") >Do you propose that SG should do second policy lookup at that point, >to find out how to send the fragments? it could do another policy lookup for non-initial fragments. That depends on how we (2401bis) end up deciding that fragments are to be handled. > > . 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. > >Wasn't the red-side fragmentation forbidden in the RFC2401? I think it >was added only in rfc2401bis, or do I remember incorrectly? At least >we have issue 88 that seems to change the rfc2401bis so that it allows >red-side fragmentation. I believe 2401 prohibited red-side fragmentation. But the prohibition was a bit vacuous in the sense that from further downstream, red-side fragmentation by a SG is indistinguishable from fragmentation of the plaintext packets upstream of the SG. 2401bis serves to legitimize the practice. >Actually red-side fragmentation seems to be only usefull if the >responder does not care about checking the non-first fragments. If the >responder still wants to verify that all fragments match the policy, >then red-side fragmentation does not help. I disagree. Red side frag by the sender helps if the receiver checks the subsequent fragments on their own individual merits (with opaque port selectors). And it even helps if the receiver will "reassemble" the fragments so it can determine the port selectors to use for non-initial fragments -- because as you yourself pointed out earlier in this thread for in-order fragments the receiver would only need to save the (src addr, dest addr, ident, SPI), not buffer nor actually reassemble the fragments. > > 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. > >The better option would be implement proper path MTU discovery in the >SG, i.e. send packet too big with suitable smaller mtu to the sender. That's great when it works, but often it doesn't e.g. ICMPs are dropped by firewalls, hosts don't do it right, etc. Also AFAIK if the originator of the datagrams does not set the DF bit, the network is obliged to fragment, not discard and send icmp dest unreachable. Tero, we've gotten a bit sidetracked today but I think we are basically coming from different positions on the fundamental question of whether a SG that wants to support fragments must either disallow port selectors or do reassembly, or is there a 3rd option to give the non-initial fragments different protection than the initial one. I'd like to wait and see Steve's memo on this which it sounds like we will see soon. --Mark From owner-ipsec@lists.tislabs.com Thu Mar 18 22:05: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 i2J65jmk028077; Thu, 18 Mar 2004 22:05:47 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA19641 Fri, 19 Mar 2004 00:24:19 -0500 (EST) Message-Id: <5.2.0.9.0.20040319001843.021c89f8@localhost> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 19 Mar 2004 00:35:52 -0500 To: "Bora Akyol" , "'Tero Kivinen'" From: Mark Duffy Subject: RE: Traffic selectors, fragments, ICMP messages and security policy problems Cc: "'Michael Richardson'" , In-Reply-To: <003901c40d51$c8235f90$070a0a0a@amer.cisco.com> References: <5.2.0.9.0.20040318173814.040a3d28@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Bora, I don't want to put numbers to it because I don't think they matter. I would simply characterize a "high speed" implementation as one pushing the current limits of the technology at any point in time. For any speed and price range, it will always be "easier" (more feasible, cheaper, faster for the price, shorter time to market, etc. -- pick your metric) to build a device that treats each packet (or fragment) on its own than to build a device that treats packets based on other packets that have been or will be seen. A requirement to collect fragments in order to evaluate port selector policy will serve to reduce the availabilty of high speed implementations. Mark At 05:30 PM 3/18/2004 -0800, Bora Akyol wrote: >Mark > >Can you please qualify what you mean by high speed and also how many >tunnels at that speed? > >Do you mean 1Gbps, 10 Gbps or 100 Gbps? How many tunnels at that speed >and packet size. > >Once we define what "high speed" means, hopefully we can get a good >understanding of >what are the issues that are detrimental to the high speed >implementation. > >Thanks > >Bora From owner-ipsec@lists.tislabs.com Thu Mar 18 22:28:02 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J6S07o034616; Thu, 18 Mar 2004 22:28:00 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA23858 Fri, 19 Mar 2004 00:46:41 -0500 (EST) Date: Fri, 19 Mar 2004 07:59:16 +0200 From: Yoav Nir Subject: RE: Final editing changes to IKEv2 To: ipsec@lists.tislabs.com Message-id: <8E16ECCC-796A-11D8-9973-000393AD410A@netvision.net.il> MIME-version: 1.0 X-Mailer: Apple Mail (2.609) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How about this: The responder (gateway) sends the AUTH and the child-sa response in a response message following the initiator (client) AUTH payload. If the client has the EAP machine integrated, this is before receiving the EAP success. If it isn't then we may need an extra round trip. If the client can't tell that the EAP neg has ended until she gets the EAP-success (imagine a protocol where the server sends several personal questions), then the extra round-trip in necessary. I think in the general case the extra round trip will not be necessary, but gateways will be required to support both cases. Is this OK? Yoav > > 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 From owner-ipsec@lists.tislabs.com Thu Mar 18 23:01: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 i2J716Kr049935; Thu, 18 Mar 2004 23:01:07 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA28836 Fri, 19 Mar 2004 01:07:50 -0500 (EST) From: "Bora Akyol" To: "'Mark Duffy'" , "'Tero Kivinen'" Cc: "'Michael Richardson'" , Subject: RE: Traffic selectors, fragments, ICMP messages and security policy problems Date: Thu, 18 Mar 2004 22:19:02 -0800 Message-ID: <000d01c40d7a$14585140$070a0a0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <5.2.0.9.0.20040319001843.021c89f8@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi While I agree with your general statement, if the question is whether the RFC2401 (bis) is implementable at "very high speed" then the answer is yes. I was in a development team for such a high speed implementation during the last couple of years (this stated here not to claim knowledge over ALL implementations but as to describe my personal experience). Can we build even faster hardware and cheaper with a basic subset of traffic selectors then don't require 5 tuple lookups. My answer to that is also yes again based on my experience. Heck even if we allowed port ranges but limited them to masks, this would still result in efficiencies in hardware based lookups, but will not solve the hw problem. While adding port ranges, etc is great and is applicable in a percentage of applications (example. secure only logging traffic between two hosts, thanks to someone on this list for bringing this up), if one can build 10 Gbps hardware with this specification, it is likely possible to build 40 Gbps hardware with a much concise set of features. With Ipv6 only hosts are allowed to fragment and PMTU is required so this issue is unique to IPv4, and if all 2401bis hosts+SGs are required to be compliant with path MTU discovery, then is there still a problem? In your example, PMTU discovery should take care of the reception of a 1500 byte ethernet frame and then running out of space. Instead, the SG should sent the correct ICMP message which should make the host reduce the MTU automatically (at least in this ideal world :-) I guess we almost need a "capability negotiation" as part of IKE and then define subset of capabilities for different types of hosts/gateways. This way, you can do both. Kind of like BGP capabilities. Regards, Bora > -----Original Message----- > From: Mark Duffy [mailto:mduffy@quarrytech.com] > Sent: Thursday, March 18, 2004 9:36 PM > To: Bora Akyol; 'Tero Kivinen' > Cc: 'Michael Richardson'; ipsec@lists.tislabs.com > Subject: RE: Traffic selectors, fragments, ICMP messages and > security policy problems > > > Hi Bora, > > I don't want to put numbers to it because I don't think they > matter. I > would simply characterize a "high speed" implementation as > one pushing the > current limits of the technology at any point in time. > > For any speed and price range, it will always be "easier" > (more feasible, > cheaper, faster for the price, shorter time to market, etc. > -- pick your > metric) to build a device that treats each packet (or > fragment) on its own > than to build a device that treats packets based on other > packets that have > been or will be seen. > > A requirement to collect fragments in order to evaluate port selector > policy will serve to reduce the availabilty of high speed > implementations. > > Mark > > > At 05:30 PM 3/18/2004 -0800, Bora Akyol wrote: > >Mark > > > >Can you please qualify what you mean by high speed and also how many > >tunnels at that speed? > > > >Do you mean 1Gbps, 10 Gbps or 100 Gbps? How many tunnels at > that speed > >and packet size. > > > >Once we define what "high speed" means, hopefully we can get a good > >understanding of what are the issues that are detrimental to > the high > >speed implementation. > > > >Thanks > > > >Bora > From owner-ipsec@lists.tislabs.com Fri Mar 19 01:35:17 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J9ZGVu003158; Fri, 19 Mar 2004 01:35:16 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA18856 Fri, 19 Mar 2004 03:52:00 -0500 (EST) From: uri@lucent.com Date: Fri, 19 Mar 2004 17:00:01 +0800 To: ipsec@lists.tislabs.com Subject: RE: Text message 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 Fri Mar 19 01:39: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 i2J9dVBO004677; Fri, 19 Mar 2004 01:39:32 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA20441 Fri, 19 Mar 2004 03:59:11 -0500 (EST) From: uri@lucent.com Date: Fri, 19 Mar 2004 17:02:59 +0800 To: ipsec@lists.tislabs.com Subject: Re: Hello 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 Fri Mar 19 01:48:14 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 i2J9m24h007688; Fri, 19 Mar 2004 01:48:02 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA22140 Fri, 19 Mar 2004 04:08:21 -0500 (EST) From: uri@lucent.com Date: Fri, 19 Mar 2004 17:14:07 +0800 To: ipsec@lists.tislabs.com Subject: Fax Message Received 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 Fri Mar 19 07:39:49 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 i2JFdi6f038321; Fri, 19 Mar 2004 07:39:44 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA22840 Fri, 19 Mar 2004 09:50:22 -0500 (EST) Message-ID: <405B0391.3090302@kolumbus.fi> Date: Fri, 19 Mar 2004 16:28:33 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoav Nir , Pasi Eronen Cc: ipsec@lists.tislabs.com Subject: Re: Final editing changes to IKEv2 References: <8E16ECCC-796A-11D8-9973-000393AD410A@netvision.net.il> In-Reply-To: <8E16ECCC-796A-11D8-9973-000393AD410A@netvision.net.il> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (EAP WG co-chair hat on) I think it would be good if we could avoid having two different EAP clients depending on whether EAP is used in IKEv2 or for, say, 802.11 authentication. The behaviour of EAP is defined in draft-ietf-rfc2284bis-09.txt (recently approved by IESG) and draft-ietf-eap-statemachine-02.pdf (completed WG last call). As Pasi states, the client state machine currently exports keys only after having received the success packet. Pasi, I think in this case this behaviour is only what the state machine says, not something that is required in the protocol document that IESG approved. Or? Changing the protocol document is not a good idea, but is there a way to change the state machine so that it would provide the client side key sooner? Would this be possible without impacts to either the protocol definition or the interface towards methods or 802.11 state machines and protocols (which we spent a lot of time to get right)? If yes, maybe we should consider what Yoav says below. If no, I think the right thing is to add the roundtrip and not create differently behaving EAP implementations depending on for what purpose they are... --Jari Yoav Nir wrote: > How about this: > > The responder (gateway) sends the AUTH and the child-sa response in a > response message following the initiator (client) AUTH payload. > > If the client has the EAP machine integrated, this is before receiving > the EAP success. If it isn't then we may need an extra round trip. If > the client can't tell that the EAP neg has ended until she gets the > EAP-success (imagine a protocol where the server sends several personal > questions), then the extra round-trip in necessary. > > I think in the general case the extra round trip will not be necessary, > but gateways will be required to support both cases. > > Is this OK? > > Yoav > >> >> 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... From owner-ipsec@lists.tislabs.com Fri Mar 19 07:43: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 i2JFh7hp038474; Fri, 19 Mar 2004 07:43:22 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24690 Fri, 19 Mar 2004 10:05:34 -0500 (EST) Date: Fri, 19 Mar 2004 17:17:55 +0200 From: Yoav Nir Subject: Re: Final editing changes to IKEv2 In-reply-to: <405B0391.3090302@kolumbus.fi> To: Jari Arkko Cc: Pasi Eronen , ipsec@lists.tislabs.com Message-id: <992FE35C-79B8-11D8-9973-000393AD410A@netvision.net.il> MIME-version: 1.0 X-Mailer: Apple Mail (2.609) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <8E16ECCC-796A-11D8-9973-000393AD410A@netvision.net.il> <405B0391.3090302@kolumbus.fi> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Well, at least in the case of non-KG EAP methods, the EAP state machine exports no key to the client, so there is no reason to delay the AUTH payload until after the EAP success message. I've just looked in draft-ietf-eap-statemachine-02.pdf. There is a strange inconsistency on page 11. The key is exported in eapKeyData "when keying material becomes available". However, the eapKeyAvailable is set to true only "in the SUCCESS state". Why is it that the peer cannot use the eapKeyData if it is available before the success message arrived? To sum up my objections, can we skip the extra roundtrip if the client either has no key (non-KG method) or already has the key (for KG methods) ? On 19/03/2004, at 16:28, Jari Arkko wrote: > > (EAP WG co-chair hat on) > > I think it would be good if we could avoid having two > different EAP clients depending on whether EAP is used > in IKEv2 or for, say, 802.11 authentication. From owner-ipsec@lists.tislabs.com Fri Mar 19 10:12:40 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JICOGL048381; Fri, 19 Mar 2004 10:12:24 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10237 Fri, 19 Mar 2004 12:15:35 -0500 (EST) Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685ED6@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Jari Arkko'" , Yoav Nir , Pasi Eronen Cc: ipsec@lists.tislabs.com Subject: RE: Final editing changes to IKEv2 Date: Fri, 19 Mar 2004 17:59:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi jari, in the past people have worried a lot about the number of roundtrips. so far there was no protocol example where the keys have to be exported before receiving the eap-success message. ikev2, however, seems to be one. to be more specific the following two variants are on the table (if we use eap-aka as an eap method within ikev2): Variant I: AUTH payload sent by the initiator before receiving the EAP success message. Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP-Request/AKA-Challenge (AT_RAND, AT_AUTN, AT_MAC) } HDR, SK {EAP-Response/AKA-Challenge(AT_RES, AT_MAC), AUTH} --> <-- HDR, SK {EAP-Success, AUTH, SAr2, TSi, TSr } Variant II: AUTH payload sent by the initiator after receiving the EAP success message. consequence: one additional roundtrip Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP-Request/AKA-Challenge (AT_RAND, AT_AUTN, AT_MAC) } HDR, SK {EAP-Response/AKA-Challenge(AT_RES, AT_MAC)} --> <-- HDR, SK {EAP-Success, AUTH} HDR, SK { AUTH } --> <-- HDR, SK { SAr2, TSi, TSr } you mention that 'Changing the protocol document is not a good idea'. which protocol document do you mean? a) draft-ietf-rfc2284bis-09.txt or b) draft-ietf-ipsec-ikev2-12.txt are there modifications required to either (a) or (b)? i don't think so. is there something in the text of (a) which addresses our issue here? (b) is vague about when the auth payload has to be sent. hence it would only be a clarification. hence, this issue seems to be more applicable to the state machine. pasi or some other state machine authors might want to comment on this issue. i agree with yoav that responders should be prepared to handle both cases. if the eap client is integrated into the ikev2 implementation then the additional roundtrip can be avoided. your concern about the two different eap client implementations might not be an issue in most cases (particularly if i think about the non-standardized api which caused me some troubles - but that's another story). ciao hannes > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Friday, March 19, 2004 3:29 PM > To: Yoav Nir; Pasi Eronen > Cc: ipsec@lists.tislabs.com > Subject: Re: Final editing changes to IKEv2 > > > > (EAP WG co-chair hat on) > > I think it would be good if we could avoid having two > different EAP clients depending on whether EAP is used > in IKEv2 or for, say, 802.11 authentication. > > The behaviour of EAP is defined in > draft-ietf-rfc2284bis-09.txt (recently approved by > IESG) and draft-ietf-eap-statemachine-02.pdf (completed > WG last call). As Pasi states, the client state machine > currently exports keys only after having received the > success packet. > > Pasi, I think in this case this behaviour is only what > the state machine says, not something that is required > in the protocol document that IESG approved. Or? > > Changing the protocol document is not a good idea, but > is there a way to change the state machine so that it > would provide the client side key sooner? Would this be > possible without impacts to either the protocol definition > or the interface towards methods or 802.11 state machines > and protocols (which we spent a lot of time to get right)? > > If yes, maybe we should consider what Yoav says below. > If no, I think the right thing is to add the roundtrip > and not create differently behaving EAP implementations > depending on for what purpose they are... > > --Jari > > Yoav Nir wrote: > > How about this: > > > > The responder (gateway) sends the AUTH and the child-sa > response in a > > response message following the initiator (client) AUTH payload. > > > > If the client has the EAP machine integrated, this is > before receiving > > the EAP success. If it isn't then we may need an extra > round trip. If > > the client can't tell that the EAP neg has ended until she gets the > > EAP-success (imagine a protocol where the server sends > several personal > > questions), then the extra round-trip in necessary. > > > > I think in the general case the extra round trip will not > be necessary, > > but gateways will be required to support both cases. > > > > Is this OK? > > > > Yoav > > > >> > >> 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... > > > From owner-ipsec@lists.tislabs.com Fri Mar 19 10:21:34 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JILVP9049076; Fri, 19 Mar 2004 10:21:31 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA12140 Fri, 19 Mar 2004 12:41:56 -0500 (EST) Message-ID: <005401c40ddb$0bd4f080$861167c0@adithya> From: "Mohan Parthasarathy" To: , "Theodore Ts'o" References: Subject: Re: Remaining open issues for RFC-2401bis Date: Fri, 19 Mar 2004 09:53:11 -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 > 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. > I asked for a clarification for which i got no response. For one of the cases, d. a user's name in a local system context (this corresponds to ID_KEY_ID in IKEv2) ID_KEY_ID carries opque octet stream. So, why limit this to user's name ? It looks like RFC 2401 supported OPAQUE values but i could be reading it wrongly. -mohan From owner-ipsec@lists.tislabs.com Fri Mar 19 11:18:55 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JJIoDc053657; Fri, 19 Mar 2004 11:18:50 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16317 Fri, 19 Mar 2004 13:18:40 -0500 (EST) Date: Fri, 19 Mar 2004 20:30:44 +0200 From: Yoav Nir Subject: Re: Final editing changes to IKEv2 In-reply-to: <2A8DB02E3018D411901B009027FD3A3F04685ED6@mchp905a.mch.sbs.de> To: Tschofenig Hannes Cc: Pasi Eronen , ipsec@lists.tislabs.com, "'Jari Arkko'" Message-id: <88DBF187-79D3-11D8-9973-000393AD410A@netvision.net.il> MIME-version: 1.0 X-Mailer: Apple Mail (2.609) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <2A8DB02E3018D411901B009027FD3A3F04685ED6@mchp905a.mch.sbs.de> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How about this: The client will send the AUTH payload as soon as it can, this can be before or after the EAP-success message, depending on protocol and implementation. The server will cache the AUTH payload as soon as it is received. It will only verify the client's AUTH and send the {AUTH, SAr2, TSi, TSr} when both conditions are met: (1) The EAP success has been received from the EAP state machine, and (2) The AUTH payload has been received from the peer. If we go against draft-ietf-rfc2284bis-09 and use OTP or GTC to transfer cleartext passwords (which is OK because the channel is encrypted) there is no key and the client can send the AUTH payload in message #5, and the whole exchange can be done by message #6. If some method generates a key, but the EAP state machine cannot figure it out before getting the success message, then there is no choice, and we need an extra roundtrip after the success message. Does this sound reasonable? On 19/03/2004, at 18:59, Tschofenig Hannes wrote: > hi jari, > > in the past people have worried a lot about the number of roundtrips. > so far > there was no protocol example where the keys have to be exported before > receiving the eap-success message. ikev2, however, seems to be one. > > to be more specific the following two variants are on the table (if we > use > eap-aka as an eap method within ikev2): > > Variant I: > > AUTH payload sent by the initiator before receiving the EAP success > message. > > > Initiator Responder > ----------- ----------- > HDR, SAi1, KEi, Ni --> > > <-- HDR, SAr1, KEr, Nr, [CERTREQ] > > HDR, SK {IDi, [CERTREQ,] [IDr,] > SAi2, TSi, TSr} --> > > <-- HDR, SK {IDr, [CERT,] AUTH, > EAP-Request/AKA-Challenge (AT_RAND, AT_AUTN, AT_MAC) > } > > HDR, SK {EAP-Response/AKA-Challenge(AT_RES, AT_MAC), AUTH} > --> > > <-- HDR, SK {EAP-Success, AUTH, > SAr2, TSi, TSr } > > > Variant II: > > AUTH payload sent by the initiator after receiving the EAP success > message. > consequence: one additional roundtrip > > Initiator Responder > ----------- ----------- > HDR, SAi1, KEi, Ni --> > > <-- HDR, SAr1, KEr, Nr, [CERTREQ] > > HDR, SK {IDi, [CERTREQ,] [IDr,] > SAi2, TSi, TSr} --> > > <-- HDR, SK {IDr, [CERT,] AUTH, > EAP-Request/AKA-Challenge (AT_RAND, AT_AUTN, AT_MAC) > } > > HDR, SK {EAP-Response/AKA-Challenge(AT_RES, AT_MAC)} --> > > <-- HDR, SK {EAP-Success, AUTH} > > HDR, SK { AUTH } --> > > <-- HDR, SK { SAr2, TSi, TSr } > > > you mention that 'Changing the protocol document is not a good idea'. > which > protocol document do you mean? > a) draft-ietf-rfc2284bis-09.txt or > b) draft-ietf-ipsec-ikev2-12.txt > > are there modifications required to either (a) or (b)? i don't think > so. > > is there something in the text of (a) which addresses our issue here? > (b) is vague about when the auth payload has to be sent. hence it > would only > be a clarification. > > hence, this issue seems to be more applicable to the state machine. > pasi or > some other state machine authors might want to comment on this issue. > > i agree with yoav that responders should be prepared to handle both > cases. > if the eap client is integrated into the ikev2 implementation then the > additional roundtrip can be avoided. your concern about the two > different > eap client implementations might not be an issue in most cases > (particularly > if i think about the non-standardized api which caused me some > troubles - > but that's another story). > > ciao > hannes > > >> -----Original Message----- >> From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] >> Sent: Friday, March 19, 2004 3:29 PM >> To: Yoav Nir; Pasi Eronen >> Cc: ipsec@lists.tislabs.com >> Subject: Re: Final editing changes to IKEv2 >> >> >> >> (EAP WG co-chair hat on) >> >> I think it would be good if we could avoid having two >> different EAP clients depending on whether EAP is used >> in IKEv2 or for, say, 802.11 authentication. >> >> The behaviour of EAP is defined in >> draft-ietf-rfc2284bis-09.txt (recently approved by >> IESG) and draft-ietf-eap-statemachine-02.pdf (completed >> WG last call). As Pasi states, the client state machine >> currently exports keys only after having received the >> success packet. >> >> Pasi, I think in this case this behaviour is only what >> the state machine says, not something that is required >> in the protocol document that IESG approved. Or? >> >> Changing the protocol document is not a good idea, but >> is there a way to change the state machine so that it >> would provide the client side key sooner? Would this be >> possible without impacts to either the protocol definition >> or the interface towards methods or 802.11 state machines >> and protocols (which we spent a lot of time to get right)? >> >> If yes, maybe we should consider what Yoav says below. >> If no, I think the right thing is to add the roundtrip >> and not create differently behaving EAP implementations >> depending on for what purpose they are... >> >> --Jari >> >> Yoav Nir wrote: >>> How about this: >>> >>> The responder (gateway) sends the AUTH and the child-sa >> response in a >>> response message following the initiator (client) AUTH payload. >>> >>> If the client has the EAP machine integrated, this is >> before receiving >>> the EAP success. If it isn't then we may need an extra >> round trip. If >>> the client can't tell that the EAP neg has ended until she gets the >>> EAP-success (imagine a protocol where the server sends >> several personal >>> questions), then the extra round-trip in necessary. >>> >>> I think in the general case the extra round trip will not >> be necessary, >>> but gateways will be required to support both cases. >>> >>> Is this OK? >>> >>> Yoav >>> >>>> >>>> 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... >> >> >> > From owner-ipsec@lists.tislabs.com Fri Mar 19 17:27: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 i2K1RqF6077132; Fri, 19 Mar 2004 17:27:54 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA29149 Fri, 19 Mar 2004 19:46:27 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: <005401c40ddb$0bd4f080$861167c0@adithya> References: <005401c40ddb$0bd4f080$861167c0@adithya> Date: Fri, 19 Mar 2004 20:04:45 -0500 To: "Mohan Parthasarathy" From: Karen Seo Subject: Re: Remaining open issues for RFC-2401bis Cc: , "Theodore Ts'o" , 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 Mohan, I'm sorry. It's my fault that you didn't get a prompt reply. I wrote up something and then got distracted by other tasks. Reply below.... > > 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. >> >I asked for a clarification for which i got no response. For one of the cases, > >d. a user's name in a local system context > (this corresponds to ID_KEY_ID in IKEv2) > >ID_KEY_ID carries opque octet stream. So, why limit this to user's name ? >It looks like RFC 2401 supported OPAQUE values but i could be reading >it wrongly. > Well, if we allow this to be any octet string, then it presents complications for the user/management interface. So we'd like to limit it to a text string containing alphanumeric characters, but not a binary string, etc. Karen From owner-ipsec@lists.tislabs.com Fri Mar 19 17:40:44 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2K1efNB077513; Fri, 19 Mar 2004 17:40:42 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA00515 Fri, 19 Mar 2004 20:02:32 -0500 (EST) Date: Fri, 19 Mar 2004 19:12:39 -0600 From: Nicolas Williams To: Karen Seo Cc: Mohan Parthasarathy , ipsec@lists.tislabs.com, "Theodore Ts'o" Subject: Re: Remaining open issues for RFC-2401bis Message-ID: <20040320011239.GQ26957@binky.central.sun.com> Mail-Followup-To: Karen Seo , Mohan Parthasarathy , ipsec@lists.tislabs.com, Theodore Ts'o References: <005401c40ddb$0bd4f080$861167c0@adithya> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, Mar 19, 2004 at 08:04:45PM -0500, Karen Seo wrote: > > > 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. > >> > >I asked for a clarification for which i got no response. For one of the > >cases, > > > >d. a user's name in a local system context > > (this corresponds to ID_KEY_ID in IKEv2) > > > >ID_KEY_ID carries opque octet stream. So, why limit this to user's name ? > >It looks like RFC 2401 supported OPAQUE values but i could be reading > >it wrongly. > > > Well, if we allow this to be any octet string, > then it presents complications for the user/management > interface. So we'd like to limit it to a text string > containing alphanumeric characters, but not a binary > string, etc. I thought ID_KEY_ID was supposed to be the public key of the cert... From owner-ipsec@lists.tislabs.com Fri Mar 19 19:32: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 i2K3WS9N084319; Fri, 19 Mar 2004 19:32:28 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA15877 Fri, 19 Mar 2004 21:49:00 -0500 (EST) From: "Bora Akyol" To: "'Karen Seo'" , "'Mohan Parthasarathy'" Cc: , "'Theodore Ts'o'" Subject: RE: Remaining open issues for RFC-2401bis Date: Fri, 19 Mar 2004 19:00:50 -0800 Message-ID: <003501c40e27$8d3f0f10$020a0a0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 8bit or 7bit text string? > Well, if we allow this to be any octet string, > then it presents complications for the user/management > interface. So we'd like to limit it to a text string > containing alphanumeric characters, but not a binary > string, etc. > > Karen > From owner-ipsec@lists.tislabs.com Fri Mar 19 19:35: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 i2K3ZfXj084511; Fri, 19 Mar 2004 19:35:42 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01737 Fri, 19 Mar 2004 15:16:53 -0500 (EST) Message-ID: <405B578C.6000109@kolumbus.fi> Date: Fri, 19 Mar 2004 22:26:52 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes , Pasi Eronen Cc: ipsec@lists.tislabs.com Subject: Re: Final editing changes to IKEv2 References: <2A8DB02E3018D411901B009027FD3A3F04685ED6@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F04685ED6@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hannes, (I do worry about number of roundtrips.) When I said that changing the protocol document would be a bad idea, I was referring to draft-ietf-rfc2284bis-09.txt which has already been approved by IESG; changes to draft- ietf-eap-statemachine-02.pdf or draft-ietf-ipsec-ikev2-12.txt would, however, still be possible, as long as they don't break something else. And I do think making EAP behave the same way in different contexts is valuable. About the solution: I'm ready to go either way on this issue, and of course if its possible we should use the smaller number of roundtrips. But at this point I'd wait for Pasi, who is one of the authors of the state machine document, to comment on whether he thinks the change would have impacts elsewhere, e.g., 802.11 interface. Pasi? I will also post a note of this discussion to the EAP WG mailing list in case other folks wish to comment. --Jari Tschofenig Hannes wrote: > hi jari, > > in the past people have worried a lot about the number of roundtrips. so far > there was no protocol example where the keys have to be exported before > receiving the eap-success message. ikev2, however, seems to be one. > > to be more specific the following two variants are on the table (if we use > eap-aka as an eap method within ikev2): > > Variant I: > > AUTH payload sent by the initiator before receiving the EAP success message. > > > Initiator Responder > ----------- ----------- > HDR, SAi1, KEi, Ni --> > > <-- HDR, SAr1, KEr, Nr, [CERTREQ] > > HDR, SK {IDi, [CERTREQ,] [IDr,] > SAi2, TSi, TSr} --> > > <-- HDR, SK {IDr, [CERT,] AUTH, > EAP-Request/AKA-Challenge (AT_RAND, AT_AUTN, AT_MAC) } > > HDR, SK {EAP-Response/AKA-Challenge(AT_RES, AT_MAC), AUTH} --> > > <-- HDR, SK {EAP-Success, AUTH, > SAr2, TSi, TSr } > > > Variant II: > > AUTH payload sent by the initiator after receiving the EAP success message. > consequence: one additional roundtrip > > Initiator Responder > ----------- ----------- > HDR, SAi1, KEi, Ni --> > > <-- HDR, SAr1, KEr, Nr, [CERTREQ] > > HDR, SK {IDi, [CERTREQ,] [IDr,] > SAi2, TSi, TSr} --> > > <-- HDR, SK {IDr, [CERT,] AUTH, > EAP-Request/AKA-Challenge (AT_RAND, AT_AUTN, AT_MAC) } > > HDR, SK {EAP-Response/AKA-Challenge(AT_RES, AT_MAC)} --> > > <-- HDR, SK {EAP-Success, AUTH} > > HDR, SK { AUTH } --> > > <-- HDR, SK { SAr2, TSi, TSr } > > > you mention that 'Changing the protocol document is not a good idea'. which > protocol document do you mean? > a) draft-ietf-rfc2284bis-09.txt or > b) draft-ietf-ipsec-ikev2-12.txt > > are there modifications required to either (a) or (b)? i don't think so. > > is there something in the text of (a) which addresses our issue here? > (b) is vague about when the auth payload has to be sent. hence it would only > be a clarification. > > hence, this issue seems to be more applicable to the state machine. pasi or > some other state machine authors might want to comment on this issue. > > i agree with yoav that responders should be prepared to handle both cases. > if the eap client is integrated into the ikev2 implementation then the > additional roundtrip can be avoided. your concern about the two different > eap client implementations might not be an issue in most cases (particularly > if i think about the non-standardized api which caused me some troubles - > but that's another story). > > ciao > hannes > > > >>-----Original Message----- >>From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] >>Sent: Friday, March 19, 2004 3:29 PM >>To: Yoav Nir; Pasi Eronen >>Cc: ipsec@lists.tislabs.com >>Subject: Re: Final editing changes to IKEv2 >> >> >> >>(EAP WG co-chair hat on) >> >>I think it would be good if we could avoid having two >>different EAP clients depending on whether EAP is used >>in IKEv2 or for, say, 802.11 authentication. >> >>The behaviour of EAP is defined in >>draft-ietf-rfc2284bis-09.txt (recently approved by >>IESG) and draft-ietf-eap-statemachine-02.pdf (completed >>WG last call). As Pasi states, the client state machine >>currently exports keys only after having received the >>success packet. >> >>Pasi, I think in this case this behaviour is only what >>the state machine says, not something that is required >>in the protocol document that IESG approved. Or? >> >>Changing the protocol document is not a good idea, but >>is there a way to change the state machine so that it >>would provide the client side key sooner? Would this be >>possible without impacts to either the protocol definition >>or the interface towards methods or 802.11 state machines >>and protocols (which we spent a lot of time to get right)? >> >>If yes, maybe we should consider what Yoav says below. >>If no, I think the right thing is to add the roundtrip >>and not create differently behaving EAP implementations >>depending on for what purpose they are... >> >>--Jari >> >>Yoav Nir wrote: >> >>>How about this: >>> >>>The responder (gateway) sends the AUTH and the child-sa >> >>response in a >> >>>response message following the initiator (client) AUTH payload. >>> >>>If the client has the EAP machine integrated, this is >> >>before receiving >> >>>the EAP success. If it isn't then we may need an extra >> >>round trip. If >> >>>the client can't tell that the EAP neg has ended until she gets the >>>EAP-success (imagine a protocol where the server sends >> >>several personal >> >>>questions), then the extra round-trip in necessary. >>> >>>I think in the general case the extra round trip will not >> >>be necessary, >> >>>but gateways will be required to support both cases. >>> >>>Is this OK? >>> >>>Yoav >>> >>> >>>>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... >> >> >> > From owner-ipsec@lists.tislabs.com Fri Mar 19 20:45:50 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2K4jmRp088636; Fri, 19 Mar 2004 20:45:48 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA24523 Fri, 19 Mar 2004 23:04:08 -0500 (EST) Message-Id: <200403200415.i2K4FlQU007773@thunk.east.sun.com> From: Bill Sommerfeld To: Karen Seo cc: "Mohan Parthasarathy" , ipsec@lists.tislabs.com, "Theodore Ts'o" Subject: Re: Remaining open issues for RFC-2401bis In-Reply-To: Your message of "Fri, 19 Mar 2004 20:04:45 EST." Reply-to: sommerfeld@east.sun.com Date: Fri, 19 Mar 2004 23:15:47 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Well, if we allow this to be any octet string, > then it presents complications for the user/management > interface. So we'd like to limit it to a text string > containing alphanumeric characters, but not a binary > string, etc. current best practice for ietf protocols is that strings which are intended for human display in protocols should come with language tags. (why do I know? sshv2 bit this bullet a while ago...). see rfc3066 - Bill From owner-ipsec@lists.tislabs.com Sat Mar 20 08:13:26 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2KGDQtQ000416; Sat, 20 Mar 2004 08:13:26 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA03162 Sat, 20 Mar 2004 10:18:01 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200403200415.i2K4FlQU007773@thunk.east.sun.com> References: <200403200415.i2K4FlQU007773@thunk.east.sun.com> Date: Sat, 20 Mar 2004 07:30:32 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Remaining open issues for RFC-2401bis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:15 PM -0500 3/19/04, Bill Sommerfeld wrote: > > Well, if we allow this to be any octet string, >> then it presents complications for the user/management >> interface. So we'd like to limit it to a text string >> containing alphanumeric characters, but not a binary >> string, etc. > >current best practice for ietf protocols is that strings which are >intended for human display in protocols should come with language >tags. (why do I know? sshv2 bit this bullet a while ago...). see >rfc3066 That is a mis-reading of RFC 3066. RFC 3066 shows how to do it if there is a need for using different languages: it does *not* recommend adding language tags to any particular text. Language tags should be used on free text that is meant to be read and understood by a reader where the ambiguity might cause problems. That is not true for names. Having said that, if we have a field that is supposed to handle human-generated names such as "account names" (the words used in IKEv2), it needs to handle the names of people whose language is other than English. IKEv2 says "octet stream", and it means "octet stream"; it does not mean "octet stream where we impose this particular text encoding and then limit it further by saying which characters are and are not allowed". This is an exact-lookup field; if the user/management interface can't handle all values that might appear, that is a problem with the interface, not the protocol. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Sat Mar 20 13:15:59 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2KLFvlK013980; Sat, 20 Mar 2004 13:15:59 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23020 Sat, 20 Mar 2004 15:25:01 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16476.43829.910000.394906@gargle.gargle.HOWL> Date: Sat, 20 Mar 2004 15:36:05 -0500 From: Paul Koning To: bora@cisco.com Cc: kseo@bbn.com, mohanp@sbcglobal.net, ipsec@lists.tislabs.com, tytso@mit.edu Subject: RE: Remaining open issues for RFC-2401bis References: <003501c40e27$8d3f0f10$020a0a0a@amer.cisco.com> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Bora" == Bora Akyol writes: Bora> 8bit or 7bit text string? >> Well, if we allow this to be any octet string, then it presents >> complications for the user/management interface. So we'd like to >> limit it to a text string containing alphanumeric characters, but >> not a binary string, etc. 7 bit text string? Surely you're joking. If something is supposed to be human-interpreted text then there's only one answer, namely UTF-8. paul From owner-ipsec@lists.tislabs.com Sat Mar 20 13:59:07 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2KLx4MH016415; Sat, 20 Mar 2004 13:59:05 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00679 Sat, 20 Mar 2004 16:14:16 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <16476.43829.910000.394906@gargle.gargle.HOWL> References: <003501c40e27$8d3f0f10$020a0a0a@amer.cisco.com> <16476.43829.910000.394906@gargle.gargle.HOWL> Date: Sat, 20 Mar 2004 13:25:53 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: RE: Remaining open issues for RFC-2401bis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:36 PM -0500 3/20/04, Paul Koning wrote: >If something is supposed to be human-interpreted text then there's >only one answer, namely UTF-8. But IKEv2 doesn't say it is text. The exact words from the IKEv2 draft are: An opaque octet stream which may be used to pass an account name or to pass vendor-specific information necessary to do certain proprietary types of identification. "Octet stream" means "octet stream", not text. If we mean "text", we should say "text" and give the one text encoding that all implementations must use; obviously, that would be UTF-8. "Vendor-specific information" might not be text. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Sat Mar 20 20:19:43 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2L4JgSn035545; Sat, 20 Mar 2004 20:19:43 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA25952 Sat, 20 Mar 2004 22:30:18 -0500 (EST) From: pkoning@equallogic.com Date: Sun, 21 Mar 2004 11:41:03 +0800 To: ipsec@lists.tislabs.com Subject: Request response 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 Sat Mar 20 23:22: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 i2L7Mt92070863; Sat, 20 Mar 2004 23:22:55 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA06884 Sun, 21 Mar 2004 01:43:01 -0500 (EST) From: pkoning@equallogic.com Date: Sun, 21 Mar 2004 14:53:19 +0800 To: ipsec@lists.tislabs.com Subject: Re: Yahoo! 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 Sat Mar 20 23:24:02 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2L7O2VO071206; Sat, 20 Mar 2004 23:24:02 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA06500 Sun, 21 Mar 2004 01:41:25 -0500 (EST) From: pkoning@equallogic.com Date: Sun, 21 Mar 2004 14:45:34 +0800 To: ipsec@lists.tislabs.com Subject: Re: Thanks :) 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 Sat Mar 20 23:54: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 i2L7snRd081162; Sat, 20 Mar 2004 23:54:52 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA15765 Sun, 21 Mar 2004 02:12:56 -0500 (EST) From: pkoning@equallogic.com Date: Sun, 21 Mar 2004 15:22:33 +0800 To: ipsec@lists.tislabs.com Subject: Re: Thank you! 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 Sun Mar 21 11:59: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 i2LJxwY2061303; Sun, 21 Mar 2004 11:59:58 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19152 Sun, 21 Mar 2004 13:55:44 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16477.59378.140000.370634@gargle.gargle.HOWL> Date: Sun, 21 Mar 2004 14:07:30 -0500 From: Paul Koning To: paul.hoffman@vpnc.org Cc: ipsec@lists.tislabs.com Subject: RE: Remaining open issues for RFC-2401bis References: <003501c40e27$8d3f0f10$020a0a0a@amer.cisco.com> <16476.43829.910000.394906@gargle.gargle.HOWL> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Paul" == Paul Hoffman > writes: Paul> At 3:36 PM -0500 3/20/04, Paul Koning wrote: >> If something is supposed to be human-interpreted text then there's >> only one answer, namely UTF-8. Paul> But IKEv2 doesn't say it is text. The exact words from the Paul> IKEv2 draft are: An opaque octet stream which may be used to Paul> pass an account name or to pass vendor-specific information Paul> necessary to do certain proprietary types of identification. Paul> "Octet stream" means "octet stream", not text. If we mean Paul> "text", we should say "text" and give the one text encoding Paul> that all implementations must use; obviously, that would be Paul> UTF-8. "Vendor-specific information" might not be text. Agreed. And an "octet string" field will of course serve nicely as a container for UTF-8 if a particular vendor wants to put text there. paul From owner-ipsec@lists.tislabs.com Sun Mar 21 22:02:59 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2M62qEh098528; Sun, 21 Mar 2004 22:02:52 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA27945 Mon, 22 Mar 2004 00:08:59 -0500 (EST) Message-ID: <016601c40fcd$5f3cf800$6901a8c0@adithya> From: "Mohan Parthasarathy" To: "Karen Seo" Cc: , "Theodore Ts'o" , References: <005401c40ddb$0bd4f080$861167c0@adithya> Subject: Re: Remaining open issues for RFC-2401bis Date: Sun, 21 Mar 2004 21:20:21 -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 > Mohan, > > I'm sorry. It's my fault that you didn't get a prompt reply. I > wrote up something and then got distracted by other tasks. Reply > below.... > > > > > 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. > >> > >I asked for a clarification for which i got no response. For one of the cases, > > > >d. a user's name in a local system context > > (this corresponds to ID_KEY_ID in IKEv2) > > > >ID_KEY_ID carries opque octet stream. So, why limit this to user's name ? > >It looks like RFC 2401 supported OPAQUE values but i could be reading > >it wrongly. > > > Well, if we allow this to be any octet string, > then it presents complications for the user/management > interface. So we'd like to limit it to a text string > containing alphanumeric characters, but not a binary > string, etc. > The value itself may be generated dynamically and added to the PAD before the IKE exchange starts. All you need is an exact match of this content with the content of the ID payload. If an UI cannot support certain strings, then it won't be used automatically. Why do you have to limit them explicitly ? It might be simpler to leave it as "opaque octet stream" specifying an example e.g. user name. -mohan > Karen From owner-ipsec@lists.tislabs.com Mon Mar 22 10:36:24 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 i2MIaNA7019600; Mon, 22 Mar 2004 10:36:23 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17384 Mon, 22 Mar 2004 12:01:09 -0500 (EST) Message-Id: <5.2.0.9.2.20040322120802.02034d40@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 22 Mar 2004 12:13:36 -0500 To: ipsec@lists.tislabs.com From: Russ Housley Subject: Fwd: Re: Traffic selectors, fragments, ICMP messages and security policy problems Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Apparently my note has been misunderstood by some recipients. The data on www.caida.org is captured on the wide area network. NFS is rarely seen on the wide area network. Rather, it is used locally within an enterprise, or it is carried inside a VPN by remote users who want to appear to be local. My point is that the data on this web site needs to be viewed in this context, and it therefore will provide a skewed view that is not representative of the traffic that will be used with IPsec. I hope this provides clarification, not further digression. Russ >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 > >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 Mon Mar 22 11:45: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 i2MJjvbb024062; Mon, 22 Mar 2004 11:45:58 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27385 Mon, 22 Mar 2004 13:57:51 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Subject: responding to unknown SPIs Date: Mon, 22 Mar 2004 11:09:15 -0800 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406051C@xch-nw-27.nw.nos.boeing.com> Thread-Topic: responding to unknown SPIs Thread-Index: AcQG9BAP0RPMFwkNQQ2OZKyEVWKIpAJTIMkA From: "Henderson, Thomas R" To: X-OriginalArrivalTime: 22 Mar 2004 19:09:16.0153 (UTC) FILETIME=[2B79AE90:01C41041] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA27365 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a request from the HIP WG for some information from IPsec WG participants. At IETF-59, there was some discussion on whether HIP (which functions similar to an IPsec key management protocol) should respond to ESP packets received with an unknown SPI. Some issues raised included: - don't IPsec key management protocols ignore these? (It was pointed out by a participant that the latest draft of IKEv2 has support for responding to them, in the Notify Payload) - what if multiple keying daemons (HIP, IPsec) are running on the same box-- do both respond? - what is the appropriate response, if there is one? (inside/outside SA context, rate limited, request to reestablish the SA?) - is a response dependent on whether the localhost determines that it has rebooted recently? - in practice, if a reboot has occurred, won't applications have lost their context anyway in this case? What is the scenario for which a response is useful? In looking at the latest draft (below), it seems that IKEv2 MAY respond, either within the SA context or outside, to these unknown SPIs, but there is not much further guidance given. In summary, at the HIP WG it was not clear if this was a useful mechanism, so we decided to defer to IPsec WG for guidance. Has it been found to be useful? Thanks, Tom >From http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-12.txt INVALID_SPI 11 MAY be sent in an IKE INFORMATIONAL Exchange when a node receives an ESP or AH packet with an invalid SPI. The Notification Data contains the SPI of the invalid packet. This usually indicates a node has rebooted and forgotten an SA. If this Informational Message is sent outside the context of an IKE_SA, it should only be used by the recipient as a "hint" that something might be wrong (because it could easily be forged). From owner-ipsec@lists.tislabs.com Mon Mar 22 12:50: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 i2MKoWQh028342; Mon, 22 Mar 2004 12:50:32 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA03295 Mon, 22 Mar 2004 15:06:43 -0500 (EST) Message-Id: <200403222017.i2MKHWQU023278@thunk.east.sun.com> From: Bill Sommerfeld To: "Henderson, Thomas R" cc: ipsec@lists.tislabs.com Subject: Re: responding to unknown SPIs In-Reply-To: Your message of "Mon, 22 Mar 2004 11:09:15 PST." <6938661A6EDA8A4EA8D1419BCE46F24C0406051C@xch-nw-27.nw.nos.boeing.com> Reply-to: sommerfeld@east.sun.com Date: Mon, 22 Mar 2004 15:17:32 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To answer an easy point quickly: > - in practice, if a reboot has occurred, won't applications have lost > their context anyway in this case? What is the scenario for which a > response is useful? when communications patterns are such that one side primarily initiates one-way exchanges, and the responder reboots, the initiator will keep sending with a bad SA until it times out. on the other hand, if you can get an authenticated IPsec-level-equivalent of a TCP RST, initiator and responder can resynchronize much more quickly. - Bill From owner-ipsec@lists.tislabs.com Mon Mar 22 15:19: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 i2MNJYFm039576; Mon, 22 Mar 2004 15:19:34 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA16661 Mon, 22 Mar 2004 17:37:27 -0500 (EST) Message-ID: <405F6DF3.8040906@airespace.com> Date: Mon, 22 Mar 2004 14:51:31 -0800 From: "Scott G. Kelly" Organization: Airespace User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" CC: ipsec@lists.tislabs.com Subject: Re: responding to unknown SPIs References: <6938661A6EDA8A4EA8D1419BCE46F24C0406051C@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C0406051C@xch-nw-27.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Mar 2004 22:51:39.0685 (UTC) FILETIME=[3CD71550:01C41060] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think what you do with invalid SPIs and/or resultant notifications depends on a number of factors, and must be left to implementers. Since such packets may represent a DoS attempt, there should be controls on the receiver to prevent naive handling of packets containing invalid SPIs. And in an ideal world, legitimate senders of such packets would detect black holes and adapt accordingly, but this frequently does not occur. I work on a wireless gateway which must support numerous vendors' IPsec clients. I've seen connectivity losses that are not always detected by the client, and sometimes these clients keep sending blindly. Since I can detect under some circumstances whether the client is "okay" or not, I can initiate an IKE SA to this client if appropriate. If it's the first I've seen of that client I can send an initial-contact message which hopefully will encourage the client to get a clue and quit using the old SA. On the other hand, if I've seen this client before, initial-contact is not appropriate, so I need an alternative, which is where the invalid-spi message becomes useful. I think the best we can do from a standards perspective is provide the protocol pieces such that someone who wants to respond to an invalid SPI has the ability to do so _if they choose to_, and invalid-spi notification recipients have similar latitude. I think what key mgmt components are involved is a local implementation matter. Scott Henderson, Thomas R wrote: > This is a request from the HIP WG for some information from IPsec WG > participants. > > At IETF-59, there was some discussion on whether HIP (which functions > similar to an IPsec key management protocol) should respond to ESP > packets received with an unknown SPI. > > Some issues raised included: > - don't IPsec key management protocols ignore these? (It was pointed > out by a participant that the latest draft of IKEv2 has support for > responding to them, in the Notify Payload) > - what if multiple keying daemons (HIP, IPsec) are running on the > same box-- do both respond? > - what is the appropriate response, if there is one? (inside/outside > SA context, rate limited, request to reestablish the SA?) > - is a response dependent on whether the localhost determines that > it has rebooted recently? > - in practice, if a reboot has occurred, won't applications have lost > their context anyway in this case? What is the scenario for which a > response is useful? > > In looking at the latest draft (below), it seems that IKEv2 MAY > respond, either within the SA context or outside, to these > unknown SPIs, but there is not much further guidance given. > > In summary, at the HIP WG it was not clear if this was a useful > mechanism, so we decided to defer to IPsec WG for guidance. Has > it been found to be useful? > > Thanks, > Tom > > > From http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-12.txt > > INVALID_SPI 11 > > MAY be sent in an IKE INFORMATIONAL Exchange when a node > receives an ESP or AH packet with an invalid SPI. The > Notification Data contains the SPI of the invalid packet. > This usually indicates a node has rebooted and forgotten an > SA. If this Informational Message is sent outside the > context of an IKE_SA, it should only be used by the > recipient as a "hint" that something might be wrong (because > it could easily be forged). From owner-ipsec@lists.tislabs.com Mon Mar 22 18:35: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 i2N2Z0JR050039; Mon, 22 Mar 2004 18:35:00 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA04190 Mon, 22 Mar 2004 20:55:32 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: Date: Mon, 22 Mar 2004 21:05:54 -0500 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: 2nd try Cc: Stephen Kent , russ housley 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 This is my second attempt to get this memo out to the list. The first try was late last week. Hopefully this one will be more successful I'm writing this note in an effort to better organize our discussion about handling fragments on the protected side of the IPsec barrier. (This discussion does not address the existing mechanism in IPsec for fragmenting an outbound packet after IPsec processing has been applied and reassembling it at the receiver. These are well understood mechanisms that work, modulo one's ability to get fragments through any firewalls that may be fragment-averse.) We've discussed a number of scenarios and delved into considerable detail, and its easy to lose track of what we are doing and why. I apologize for taking longer than anticipated to complete this note, and for the fact that it has grown to double the size I originally estimated. Steve ----- The Requirement There are three issues that must be resolved re processing of (plaintext) fragments in IPsec: - mapping a non-initial, outbound fragment to the right SA (or finding the right SPD entry) - verifying that a received, non-initial fragment is authorized for the SA via which it is received - mapping outbound and inbound non-initial fragments to the right SPD/cache entry, for bypass/drop traffic. The first and third issues arise because we need a deterministic algorithm for mapping traffic to SAs (and SPD/cache entries). All three issues are important because we want to make sure that non-initial fragments that cross the IPsec boundary do not cause the access control policies in place at the receiver (or transmitter) to be violated. Transport Mode and Fragments First, we note that transport mode SAs have been defined (in 2401bis) to not carry fragments. This is a carryover from 2401, where transport mode SAs always terminated at end points. This is a fundamental requirement because, in the worst case, an IPv4 fragment to which IPsec was applied, might then be fragmented (as a ciphertext packet), en route to the destination. IP fragment reassembly procedures at the IPsec receiver would not be able to distinguish between pre-IPsec fragments and fragments created after IPsec processing. For IPv6, only the sender is allowed to fragment a packet. As for IPv4, an IPsec implementation is allowed to fragment tunnel mode packets after IPsec processing, because it is the sender relative to the (outer) tunnel header. However, unlike IPv4, it would be feasible to carry a plaintext fragment on a transport mode SA, because the fragment header in IPv6 would appear after the AH or ESP header, and thus would not cause confusion at the receiver re reassembly. Specifically, the receiver would not attempt reassembly for the fragment until after IPsec processing. Thus a possible question for the WG is whether 2401bis should relax the prohibition on carriage of fragments on transport mode SAs for IPv6 traffic? I suggest NOT allowing this, as it only adds to our problems, but I thought I would mention it in the name of completeness. When only end systems used transport mode SAs, the prohibition on carriage of fragments was not a problem, since we assumed that the end system could be configured to not offer a fragment to IPsec. For a native host implementation this seems reasonable, and, as someone already noted, 2401 warned that a BITS implementation might have to reassemble fragments before performing an SA lookup. (It would then apply AH or ESP and could re-fragment the packet after IPsec processing.) Because a BITS implementation is assumed to be able to have access to all traffic emanating from its host, even if the host has multiple interfaces, this was deemed a reasonable mandate. In 2401bis, we have explicitly said that it's OK to use transport mode in cases where the IPsec implementation is not the ultimate destination, e.g., between two SGs. In principle, this creates a new opportunity for outbound, plaintext fragments to be mapped to a transport mode SA for IPsec processing. However, in these new contexts in which a transport mode SA is now approved for use, it seems likely that we can continue to prohibit transmission of fragments, as seen by IPsec. For example, in an IP overlay network, packets being sent over transport mode SAs are IP-in-IP tunneled and thus have the necessary inner header to accommodate fragmentation prior to IPsec processing. When carried via a transport mode SA, IPsec would not examine the inner IP header for such traffic, and thus would not consider the packet to be a fragment. Thus it seems reasonable to retain the prohibition on carrying IPv4 fragments on transport mode SAs, even when the source or destination is an SG. Tunnel Mode and Fragments For tunnel mode SAs, it has always been the case that outbound fragments might arrive for processing at an IPsec implementation, although we have not defined a fool-proof mechanism for doing so in all contexts. The need to accommodate fragmented outbound packets can pose a problem because a non-initial fragment generally will not contain the port fields associated with a next layer protocol such as TCP, UDP, or SCTP. Thus, depending on the SPD configuration for a given IPsec implementation, plaintext fragments might or might not pose a problem. For example, if the SPD requires that all traffic between two address ranges is offered IPsec protection (no bypass or drop SPD entries apply to this address range), then it should be easy to carry non-initial fragments on the SA defined for this address range, since the SPD entry implies an intent to carry ALL traffic between the address ranges. But, if there are multiple SPD entries that could match a fragment, and if these entries reference different subsets of port fields (vs. ANY), then it is not possible to map an outbound non-initial fragment to the right entry, unambiguously. (If we choose to allow carriage of fragments on transport mode SAs for IPv6, the problems arises in that context as well.) This problem largely, though not exclusively, motivated the definition of OPAQUE as a selector value for port fields in RFC 2401. The other motivation for OPAQUE is the observation that port fields might not be accessible due to the prior application of IPsec. For example, if a host applied IPsec to its traffic and that traffic arrived at an SG, these fields would be encrypted. The algorithm specified for locating the "next layer protocol" described in 2401 also motivated use of OPAQUE to accommodate an encrypted next layer protocol field in such circumstances. Nonetheless, the primary use of the OPAQUE value was to match traffic selector fields in packets that did not contain port fields (non-initial fragments), or packets in which the port fields were already encrypted (as a result of nested application of IPsec). 2401 was ambiguous in discussing the use of OPAQUE vs. ANY, suggesting in some places that ANY might be an alternative to OPAQUE. We gain additional access control capability by defining both ANY and OPAQUE values. OPAQUE can be defined to match only fields that are not accessible. We could define ANY as the complement of OPAQUE, i.e., it would match all values but only for accessible port fields. If we simplify the procedure employed to locate the next layer protocol in 2401bis, so that we treat ESP and AH as next layer protocols, then the notion of an encrypted next layer protocol field has vanished, and there is also no need to worry about encrypted port fields either. (We probably need to clarify the notion that ESP is not an "extension header" re IPv6, despite the fact that the IPv6 spec calls it that. The same is true for AH.) In that case, OPAQUE will be applicable only to non-initial fragments. If we adopt the definitions above for ANY and OPAQUE, we need to clarify how these values work when the specified protocol does not have port fields, and when ANY is used for the protocol selector. I suggest that if a specific protocol value is used as a selector, and if that protocol has no port fields, then the port field selectors are to be ignored and ANY MUST be specified as the value for the port fields. (In this context, ICMP TYPE and CODE values are lumped together as a single port field (for IKEv2 negotiation), as is the IPv6 Mobility Header TYPE value.) If the protocol selector is ANY, then this should be treated as equivalent to specifying a protocol for which no port fields are defined, and thus the port selectors should be ignored, and MUST be set to ANY. The Problem of Non-Initial Fragments For an SG implementation, it is obvious that fragments might arrive from end systems behind the SG. A BITW implementation also may encounter fragments from a host or gateway behind it. (As noted earlier, native host implementations and BITS implementations probably can avoid the problems described below.) In the worst case, fragments from a packet might arrive at distinct BITW or SG instantiations and thus preclude reassembly as a solution option. Hence, in 2401 we adopted a general requirement that fragments must be accommodated in tunnel mode for all implementations. However, 2401 did not provide a perfect solution. The use of OPAQUE as a selector value for port fields (a SHOULD in 2401) allowed an SA to carry non-initial fragments. Using the features defined in 2401, if one defined an SA between two IPsec (SG or BITW) implementations using the OPAQUE value for both port fields, then all non-initial fragments matching the S/D address and protocol values for the SA would be mapped to that SA. Initial fragments would NOT map to this SA, if we adopt a strict definition of OPAQUE. However, 2401 did not provide detailed guidance on this and thus it may not have been apparent that use of this feature would essentially create a "non-initial fragment only" SA, precisely the solution that the WG recently rejected. In the course of rejecting the "fragment-only" SA approach, it was noted that some subtle problems, problems not considered in 2401, would have to be avoided. For example, an SA of this sort must be configured to offer the "highest quality" security services for any traffic between the indicated S/D addresses (for the specified protocol). This is necessary to ensure that any traffic captured by the fragment-only SA is not offered degraded security relative to what it would have been offered if the packet were not fragmented. A possible problem here is that we may not be able to identify the "highest quality" security services defined for use between two IPsec implementation, since the choice of security protocols, options, and algorithms is a lattice (remember that from algebra?), not a totally ordered set. (We might safely say that BYPASS < AH < ESP w/integrity, but it gets messy if we have multiple ESP encryption or integrity algorithm options.) So, one has to impose a total ordering on these security parameters to make this work, but this can be done locally. However, this conservative strategy has a possible performance down side; if most traffic traversing an IPsec implementation for a given S/D address pair (and specified protocol) is bypassed, then a fragment-only SA for that address pair might cause a dramatic increase in the volume of traffic afforded crypto processing. If the crypto implementation cannot support high traffic rates, this could cause problems. (An IPsec implementation that is capable of line rate or near line rate crypto performance would not be adversely affected by this SA configuration approach, so the performance impact is a potential concern, specific to implementation capabilities.) Another concern is that non-initial fragments sent over a dedicated SA might be used to effect overlapping reassembly attacks, when combined with an apparently acceptable initial fragment. (This sort of attack assumes creation of bogus fragments, and is not a side effect of normal fragmentation.) This concern is easily addressed in IPv4, by checking the fragment offset value to ensure that no non-initial fragments have a small enough offset to overlap port fields that should be contained in the initial fragment. Recall that the IPv4 MTU minimum is 576 bytes, and the max IP header length is 60 bytes, so any ports should be present in the initial fragment. If we require all non-initial fragments to have an offset of say 128 or greater, just to be on the safe side, this should prevent successful attacks of this sort. If the intent is only to protect against this sort of reassembly attack, this check need be implemented only by a receiver. Another possible concern is that in some topologies and SPD configurations this approach might result in an access control surprise. The notion is that if we create an SA to carry ALL (non-initial) fragments then that SA would carry some traffic that might otherwise arrive as plaintext via a separate path, e.g., a path monitored by a proxy firewall. But, this concern arises only if the other path allows initial fragments to traverse it without requiring reassembly, presumably a bad idea for a proxy firewall. Nonetheless, this does represent a potential problem in some topologies and under certain assumptions re SPD and (other) firewall rule sets, and administrators need to be warned of this possibility. IPv6 also has a fragment offset, carried in the fragmentation extension header. However, IPv6 extension headers are variable in length and there is no analogous max header length value that we can use to check non-initial fragments, to reject ones that might be used for an attack of the sort noted above. A receiver would need to maintain state analogous to reassembly state, to provide equivalent protection. So, only for IPv4 it is feasible to impose a fragment offset check that would reject attacks designed to circumvent port field checks by IPsec (or firewalls) when passing non-initial fragments. A less serious concern is that non-initial fragments sent over a non-initial fragment-only SA might represent a DoS opportunity, in that they could be sent when no valid, initial fragment will ever arrive. This might be used to attack hosts behind an SG or BITW device. However, the incremental risk posed by this sort of attack, which can be mounted only by hosts behind an SG or BITW device, seems small. If we interpret the ANY selector value as encompassing OPAQUE, then a single SA with ANY values for both port fields would be able to accommodate all traffic matching the S/D address and protocol traffic selectors, an alternative to using the OPAQUE value. But, using ANY here precludes multiple, distinct SAs between the same IPsec implementations for the same address pairs and protocol. So, it is not an exactly equivalent alternative. Fundamentally, fragment handling problems arise only when more than one SA is defined with the same S/D address and protocol selector values, but with different port field selector values. Bypass/Drop Traffic We also have to address the non-initial fragment processing issue for bypass/drop entries, independent of SA processing. This is largely a local matter for two reasons: 1) we have no means for coordinating SPD entries for such traffic between IPsec implementations since IKE is not invoked; 2) many of these entries refer to traffic that is NOT directed to or received from a location that is using IPsec, so there is no peer IPsec implementation with which to coordinate via any means. However, 2401bis should provide guidance here, consistent with our goal of offering a well-defined, access control function for all traffic, relative to the IPsec boundary. To that end, I suggest that implementations MAY choose to support fragment reassembly for bypass/drop traffic when port fields are specified. An implementation also MUST permit a user or administrator to accept such traffic or reject such traffic using the SPD conventions described at the end of this note. Just say no to ports? It has been suggested that we could avoid the problems described above by not allowing port field selectors to be used in tunnel mode. But the discussion above shows this to be an unnecessarily stringent approach, i.e., since no problems arise for the native OS and BITS implementations. Moreover, some WG members have described scenarios where use of tunnel mode SAs with (non-trivial) port field selectors is appropriate. So the challenge is defining a strategy that can deal with this problem in BITW and SG contexts. Also note that bypass/drop entries in the SPD that make use of ports pose the same problems, irrespective of tunnel vs. transport mode notions. Some folks have suggested that a firewall behind an SG or BITW should be left to enforce port level access controls, and the effects of fragmentation. However, this seems to be an incongruous suggestion in that elsewhere in IPsec (e.g., in IKE payloads) we are concerned about firewalls that always drop fragments! If many (most?) firewalls don't pass fragments in general, why should we expect them deal with fragments in this case? So, this analysis rejects the suggestion of disallowing use of port field selectors with tunnel mode SAs. Other Suggested Solutions One suggestion is to reassemble fragments at the sending IPsec implementation, and thus avoid the problem entirely. This approach is invisible to a receiver and thus could be adopted as a purely local implementation option. A more sophisticated version of this suggestion calls for establishing and maintaining minimal state from each initial fragment encountered, to allow non-initial fragments to be matched to the right SAs or SPD/cache entries. This implies an extension to the current processing model (and the old one). One would intercept all fragments, capture S/D address, protocol, packet ID, and port fields from initial fragments and then use this data to map non-initial fragments to SAs that require port fields. If this approach is employed, the receiver needs to employ an equivalent scheme, as it too must verify that received fragments are consistent with SA selector values. A non-initial fragment that arrives prior to an initial fragment could be cached or discarded, awaiting arrival of the corresponding initial fragment. A downside of both approaches noted above is that they will not always work. When a BITW device or SG is configured in a topology that might allow some fragments for a packet to be processed at different SGs or BITW devices, then there is no guarantee that all fragments will ever arrive at the same IPsec device. This approach also raises possible processing problems. If the sender caches non-initial fragments until the corresponding initial fragment arrives, buffering problems might arise, especially at high speeds. If the non-initial fragments are discarded rather than cached, there is no guarantee that traffic will ever pass, e.g., retransmission will result in different packet IDs that cannot be matched with prior transmissions. In any case, housekeeping procedures will be needed to decide when to delete the fragment state data, adding some complexity to the system. Nonetheless, this is a viable solution in some topologies, and these are likely to be common topologies. Issue #81, which the WG rejected, suggested the convention of creating an SA to carry only non-initial fragments, something that was supported implicitly under the 2401 model via use of OPAQUE port fields, but never clearly articulated in the RFC. The (rejected) text called for each non-initial fragment to be treated as protocol 44 (the IPv6 fragment header protocol ID) by the sender and receiver. This approach has the potential to make IPv4 and v6 fragment handling more uniform, but it does not fundamentally change the problem, nor dies it address the issue of fragment handling for bypass/drop traffic. Given the fragment overlap attack problem that IPv6 poses, it does not seem that it is worth the effort to adopt this strategy. Consistency Earlier the WG agreed (Issue #88) to allow an IPsec BITS, BITW or SG to perform fragmentation prior to IPsec processing, after Mark Duffy explain the motivation for this. If this fragmentation is performed after SA lookup at the sender, there is no "mapping to the right SA" problem. But, the receiver still needs to be able to verify that the non-initial fragments are consistent with the SA via which they are received. Since the initial fragment might be lost en route, the receiver encounters all of the potential problems noted above. Thus, if we are to be consistent in our decisions, we need to say how a receiver will deal with the non-initial fragments that arrive. Conclusions There is no simple, uniform way to handle fragments in all contexts. Different approaches work better in different contexts. Thus I suggest we require support for two approaches, and offer a third, and allow a user or administrator to choose from among these based on topology constraints and security requirements. Hence the following proposed text: 1. All implementations MUST support tunnel mode SAs that pass traffic without regard to port field values. If the SA will carry traffic for specified protocols, the two selector sets MUST be used to specify the port fields for the SA: ANY and OPAQUE. An SA defined in this fashion will carry all traffic for the indicated source/destination addresses and specified protocol(s). If the SA will carry traffic without regard to a specific protocol value (i.e., ANY is specified), then the port field values MUST be set to ANY as well. 2. All implementations MUST support tunnel mode SAs that will carry only non-initial fragments, separate from non-fragmented packets and initial fragments. The OPAQUE value will be used to specify port field selectors for an SA to carry non-initial fragments. Specific port selector values will be used to define SAs to carry initial fragments and non-fragmented packets. This approach can be used if a user or administrator wants to create one or more tunnel mode SAs between the same source/destination addresses that discriminate based on port fields. These SAs MUST have non-trivial protocol selector values, otherwise approach #1 above can be used. Receivers MUST perform a minimum offset check on IPv4 (non-initial) fragments to protect against overlapping fragment attacks when SAs of this type are employed. Because such checks cannot be performed on IPv6 non-initial fragments, users and administrators are advised that carriage of such fragments may be dangerous, and implementers may choose to NOT support such SAs for IPv6 traffic. Also, because a SA of this sort will carry ALL non-initial fragments that match a specified source/destination address pair and protocol value, users and administrators are advised to protect such traffic using ESP (with integrity) and the "strongest" integrity and encryption algorithms available at both peers. (Determination of the "strongest" algorithms requires imposing a total ordering of the available algorithms, a local determination at the discretion of the initiator of the SA.) 3. An implementation MAY choose to support some form of stateful fragment checking for a tunnel mode SA with non-trivial port field values (not ANY or OPAQUE). Implementations that will transmit non-initial fragments on a tunnel mode SA that makes use of non-trivial port selectors MUST notify a peer via an IKE payload (TBD). The peer MUST reject this proposal if it will not accept non-initial fragments in this context. If an implementation does not successfully negotiate transmission of non-initial fragments for such an SA, it MUST NOT send such fragments over the SA. This standard does not specify how peers will deal with such fragments, e.g., via reassembly or other means, at either sender or receiver. However, a receiver MUST drop non-initial fragments that arrive on an SA with non-trivial port selector values unless this feature has been negotiated. Dropping such packets is an auditable event. Note that in configurations where fragments of a packet might be sent or received via different security gateways or BITW implementations, stateful strategies for tracking fragments may fail. From owner-ipsec@lists.tislabs.com Mon Mar 22 19:24:40 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2N3OdpP054523; Mon, 22 Mar 2004 19:24:40 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA07102 Mon, 22 Mar 2004 21:49:18 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: References: <200403200415.i2K4FlQU007773@thunk.east.sun.com> Date: Mon, 22 Mar 2004 21:35:54 -0500 To: Paul Hoffman / VPNC From: Stephen Kent Subject: Re: Remaining open issues for RFC-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 Paul, Since all ID's sent via IKE are used for access control, it seems reasonable to assume that, in general, people have interacted with a management interface to enter these IDs. So, unless there is a need to transmit an arbitrary octet string for ID purposes, it would be more appropriate to constrain this to something that a user has a good chance of getting right. The IKE v2 specs says (page 55) "An opaque octet stream which may be used to pass an account name or to pass vendor-specific information necessary to do certain proprietary types of identification." This hardly sounds like an arbitrary byte string. IKE is very sloppy re choice of IDs, and this has not been fixed in IKEv2. for example, in addition to explicit support for e-mail addresses, IP addresses, and distinguished names, IOKEv2 calls for support of the general name construct. But, this construct already encompasses all of the preceding name types, plus others that seem very unlikely to ever be of interest in our context, e.g., EDI Party names! So, my suggestion is that we be a bit more restrictive with the supported name types. In that spirit, if we need to keep this as an arbitrary byte string, we ought to provide some rationale for that decision. Steve From owner-ipsec@lists.tislabs.com Mon Mar 22 21:16: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 i2N5GSv4061196; Mon, 22 Mar 2004 21:16:29 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA13791 Mon, 22 Mar 2004 23:39:07 -0500 (EST) Message-ID: <405FC0DE.2040402@roc.co.in> Date: Tue, 23 Mar 2004 10:15:18 +0530 From: Ravi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent CC: ipsec@lists.tislabs.com, russ housley Subject: Re: 2nd try References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I like to thank Steve for thorough,detailed and clear description on the problem. I could understand the whole background, even though I did not go through quite a number of emails on this subject in recent time. It is true that port selectors are being used in IPSEC policies to give differential security for different kinds of traffic. Also, I noticed that some applications (even TCP, which is majority of traffic in Internet today) don't set DF bit and don't initiate PMTU processing. It means that there would be fragments and today many IPSEC implementations do the reassembly (Or pseudo reassembly) of the clear packets before applying security. I feel, any suggestion/solution make this case default. With respect to this I have following comments. I agree on Conclusion 1 i.e.. All implementations MUST support tunnel mode SAs that pass traffic without regard to port field values. In regards to second point in conclusions section, I have some reservations. In many cases, the reassembly of the fragments is done for several reasons. It is not only in regards to IPSEC, but also in regards to other security functionality such as 'Stateful inspection firewall' or 'Intrusion Protection System' etc.. In these cases, the IPSEC implementation may would like always send all fragments using the right SA, rather than sending non-initial fragments on different SA. Due to this, the IPSEC implementation may not have even provide this kind of flexibility. I like the idea of providing negotiation option in IKE. If an implementation does not intend to support of allowing non-initial fragments on a different SA, it can indicate so as part of IKE negotiation. In this case, the implementations must not use separate SA for non-initial fragments and must use local methods to map fragments (initial or non-initial) to the same SPD policy and must use same SA. Regards Ravi Stephen Kent wrote: > This is my second attempt to get this memo out to the list. The first > try was late last week. Hopefully this one will be more successful > > I'm writing this note in an effort to better organize our discussion > about handling fragments on the protected side of the IPsec barrier. > (This discussion does not address the existing mechanism in IPsec for > fragmenting an outbound packet after IPsec processing has been applied > and reassembling it at the receiver. These are well understood > mechanisms that work, modulo one's ability to get fragments through > any firewalls that may be fragment-averse.) We've discussed a number > of scenarios and delved into considerable detail, and its easy to lose > track of what we are doing and why. I apologize for taking longer than > anticipated to complete this note, and for the fact that it has grown > to double the size I originally estimated. > > Steve > ----- > > > The Requirement > > There are three issues that must be resolved re processing of > (plaintext) fragments in IPsec: > - mapping a non-initial, outbound fragment to the right SA (or finding > the right SPD entry) > - verifying that a received, non-initial fragment is authorized for > the SA via which it is received > - mapping outbound and inbound non-initial fragments to the right > SPD/cache entry, for bypass/drop traffic. > > The first and third issues arise because we need a deterministic > algorithm for mapping traffic to SAs (and SPD/cache entries). All > three issues are important because we want to make sure that > non-initial fragments that cross the IPsec boundary do not cause the > access control policies in place at the receiver (or transmitter) to > be violated. > > > Transport Mode and Fragments > > First, we note that transport mode SAs have been defined (in 2401bis) > to not carry fragments. This is a carryover from 2401, where transport > mode SAs always terminated at end points. This is a fundamental > requirement because, in the worst case, an IPv4 fragment to which > IPsec was applied, might then be fragmented (as a ciphertext packet), > en route to the destination. IP fragment reassembly procedures at the > IPsec receiver would not be able to distinguish between pre-IPsec > fragments and fragments created after IPsec processing. > > For IPv6, only the sender is allowed to fragment a packet. As for > IPv4, an IPsec implementation is allowed to fragment tunnel mode > packets after IPsec processing, because it is the sender relative to > the (outer) tunnel header. However, unlike IPv4, it would be feasible > to carry a plaintext fragment on a transport mode SA, because the > fragment header in IPv6 would appear after the AH or ESP header, and > thus would not cause confusion at the receiver re reassembly. > Specifically, the receiver would not attempt reassembly for the > fragment until after IPsec processing. > > Thus a possible question for the WG is whether 2401bis should relax > the prohibition on carriage of fragments on transport mode SAs for > IPv6 traffic? I suggest NOT allowing this, as it only adds to our > problems, but I thought I would mention it in the name of completeness. > > When only end systems used transport mode SAs, the prohibition on > carriage of fragments was not a problem, since we assumed that the end > system could be configured to not offer a fragment to IPsec. For a > native host implementation this seems reasonable, and, as someone > already noted, 2401 warned that a BITS implementation might have to > reassemble fragments before performing an SA lookup. (It would then > apply AH or ESP and could re-fragment the packet after IPsec > processing.) Because a BITS implementation is assumed to be able to > have access to all traffic emanating from its host, even if the host > has multiple interfaces, this was deemed a reasonable mandate. > > In 2401bis, we have explicitly said that it's OK to use transport mode > in cases where the IPsec implementation is not the ultimate > destination, e.g., between two SGs. In principle, this creates a new > opportunity for outbound, plaintext fragments to be mapped to a > transport mode SA for IPsec processing. However, in these new contexts > in which a transport mode SA is now approved for use, it seems likely > that we can continue to prohibit transmission of fragments, as seen by > IPsec. For example, in an IP overlay network, packets being sent over > transport mode SAs are IP-in-IP tunneled and thus have the necessary > inner header to accommodate fragmentation prior to IPsec processing. > When carried via a transport mode SA, IPsec would not examine the > inner IP header for such traffic, and thus would not consider the > packet to be a fragment. Thus it seems reasonable to retain the > prohibition on carrying IPv4 fragments on transport mode SAs, even > when the source or destination is an SG. > > > Tunnel Mode and Fragments > > For tunnel mode SAs, it has always been the case that outbound > fragments might arrive for processing at an IPsec implementation, > although we have not defined a fool-proof mechanism for doing so in > all contexts. The need to accommodate fragmented outbound packets can > pose a problem because a non-initial fragment generally will not > contain the port fields associated with a next layer protocol such as > TCP, UDP, or SCTP. Thus, depending on the SPD configuration for a > given IPsec implementation, plaintext fragments might or might not > pose a problem. > > For example, if the SPD requires that all traffic between two address > ranges is offered IPsec protection (no bypass or drop SPD entries > apply to this address range), then it should be easy to carry > non-initial fragments on the SA defined for this address range, since > the SPD entry implies an intent to carry ALL traffic between the > address ranges. But, if there are multiple SPD entries that could > match a fragment, and if these entries reference different subsets of > port fields (vs. ANY), then it is not possible to map an outbound > non-initial fragment to the right entry, unambiguously. (If we choose > to allow carriage of fragments on transport mode SAs for IPv6, the > problems arises in that context as well.) > > This problem largely, though not exclusively, motivated the definition > of OPAQUE as a selector value for port fields in RFC 2401. The other > motivation for OPAQUE is the observation that port fields might not be > accessible due to the prior application of IPsec. For example, if a > host applied IPsec to its traffic and that traffic arrived at an SG, > these fields would be encrypted. The algorithm specified for locating > the "next layer protocol" described in 2401 also motivated use of > OPAQUE to accommodate an encrypted next layer protocol field in such > circumstances. Nonetheless, the primary use of the OPAQUE value was to > match traffic selector fields in packets that did not contain port > fields (non-initial fragments), or packets in which the port fields > were already encrypted (as a result of nested application of IPsec). > 2401 was ambiguous in discussing the use of OPAQUE vs. ANY, suggesting > in some places that ANY might be an alternative to OPAQUE. > > We gain additional access control capability by defining both ANY and > OPAQUE values. OPAQUE can be defined to match only fields that are not > accessible. We could define ANY as the complement of OPAQUE, i.e., it > would match all values but only for accessible port fields. If we > simplify the procedure employed to locate the next layer protocol in > 2401bis, so that we treat ESP and AH as next layer protocols, then the > notion of an encrypted next layer protocol field has vanished, and > there is also no need to worry about encrypted port fields either. (We > probably need to clarify the notion that ESP is not an "extension > header" re IPv6, despite the fact that the IPv6 spec calls it that. > The same is true for AH.) In that case, OPAQUE will be applicable only > to non-initial fragments. > > If we adopt the definitions above for ANY and OPAQUE, we need to > clarify how these values work when the specified protocol does not > have port fields, and when ANY is used for the protocol selector. I > suggest that if a specific protocol value is used as a selector, and > if that protocol has no port fields, then the port field selectors are > to be ignored and ANY MUST be specified as the value for the port > fields. (In this context, ICMP TYPE and CODE values are lumped > together as a single port field (for IKEv2 negotiation), as is the > IPv6 Mobility Header TYPE value.) If the protocol selector is ANY, > then this should be treated as equivalent to specifying a protocol for > which no port fields are defined, and thus the port selectors should > be ignored, and MUST be set to ANY. > > > The Problem of Non-Initial Fragments > > For an SG implementation, it is obvious that fragments might arrive > from end systems behind the SG. A BITW implementation also may > encounter fragments from a host or gateway behind it. (As noted > earlier, native host implementations and BITS implementations probably > can avoid the problems described below.) In the worst case, fragments > from a packet might arrive at distinct BITW or SG instantiations and > thus preclude reassembly as a solution option. Hence, in 2401 we > adopted a general requirement that fragments must be accommodated in > tunnel mode for all implementations. However, 2401 did not provide a > perfect solution. The use of OPAQUE as a selector value for port > fields (a SHOULD in 2401) allowed an SA to carry non-initial fragments. > > Using the features defined in 2401, if one defined an SA between two > IPsec (SG or BITW) implementations using the OPAQUE value for both > port fields, then all non-initial fragments matching the S/D address > and protocol values for the SA would be mapped to that SA. Initial > fragments would NOT map to this SA, if we adopt a strict definition of > OPAQUE. However, 2401 did not provide detailed guidance on this and > thus it may not have been apparent that use of this feature would > essentially create a "non-initial fragment only" SA, precisely the > solution that the WG recently rejected. > > In the course of rejecting the "fragment-only" SA approach, it was > noted that some subtle problems, problems not considered in 2401, > would have to be avoided. For example, an SA of this sort must be > configured to offer the "highest quality" security services for any > traffic between the indicated S/D addresses (for the specified > protocol). This is necessary to ensure that any traffic captured by > the fragment-only SA is not offered degraded security relative to what > it would have been offered if the packet were not fragmented. A > possible problem here is that we may not be able to identify the > "highest quality" security services defined for use between two IPsec > implementation, since the choice of security protocols, options, and > algorithms is a lattice (remember that from algebra?), not a totally > ordered set. (We might safely say that BYPASS < AH < ESP w/integrity, > but it gets messy if we have multiple ESP encryption or integrity > algorithm options.) So, one has to impose a total ordering on these > security parameters to make this work, but this can be done locally. > > However, this conservative strategy has a possible performance down > side; if most traffic traversing an IPsec implementation for a given > S/D address pair (and specified protocol) is bypassed, then a > fragment-only SA for that address pair might cause a dramatic increase > in the volume of traffic afforded crypto processing. If the crypto > implementation cannot support high traffic rates, this could cause > problems. (An IPsec implementation that is capable of line rate or > near line rate crypto performance would not be adversely affected by > this SA configuration approach, so the performance impact is a > potential concern, specific to implementation capabilities.) > > Another concern is that non-initial fragments sent over a dedicated SA > might be used to effect overlapping reassembly attacks, when combined > with an apparently acceptable initial fragment. (This sort of attack > assumes creation of bogus fragments, and is not a side effect of > normal fragmentation.) This concern is easily addressed in IPv4, by > checking the fragment offset value to ensure that no non-initial > fragments have a small enough offset to overlap port fields that > should be contained in the initial fragment. Recall that the IPv4 MTU > minimum is 576 bytes, and the max IP header length is 60 bytes, so any > ports should be present in the initial fragment. If we require all > non-initial fragments to have an offset of say 128 or greater, just to > be on the safe side, this should prevent successful attacks of this > sort. If the intent is only to protect against this sort of reassembly > attack, this check need be implemented only by a receiver. > > Another possible concern is that in some topologies and SPD > configurations this approach might result in an access control > surprise. The notion is that if we create an SA to carry ALL > (non-initial) fragments then that SA would carry some traffic that > might otherwise arrive as plaintext via a separate path, e.g., a path > monitored by a proxy firewall. But, this concern arises only if the > other path allows initial fragments to traverse it without requiring > reassembly, presumably a bad idea for a proxy firewall. Nonetheless, > this does represent a potential problem in some topologies and under > certain assumptions re SPD and (other) firewall rule sets, and > administrators need to be warned of this possibility. > > IPv6 also has a fragment offset, carried in the fragmentation > extension header. However, IPv6 extension headers are variable in > length and there is no analogous max header length value that we can > use to check non-initial fragments, to reject ones that might be used > for an attack of the sort noted above. A receiver would need to > maintain state analogous to reassembly state, to provide equivalent > protection. So, only for IPv4 it is feasible to impose a fragment > offset check that would reject attacks designed to circumvent port > field checks by IPsec (or firewalls) when passing non-initial fragments. > > A less serious concern is that non-initial fragments sent over a > non-initial fragment-only SA might represent a DoS opportunity, in > that they could be sent when no valid, initial fragment will ever > arrive. This might be used to attack hosts behind an SG or BITW > device. However, the incremental risk posed by this sort of attack, > which can be mounted only by hosts behind an SG or BITW device, seems > small. > > If we interpret the ANY selector value as encompassing OPAQUE, then a > single SA with ANY values for both port fields would be able to > accommodate all traffic matching the S/D address and protocol traffic > selectors, an alternative to using the OPAQUE value. But, using ANY > here precludes multiple, distinct SAs between the same IPsec > implementations for the same address pairs and protocol. So, it is not > an exactly equivalent alternative. > Fundamentally, fragment handling problems arise only when more than > one SA is defined with the same S/D address and protocol selector > values, but with different port field selector values. > > > Bypass/Drop Traffic > > We also have to address the non-initial fragment processing issue for > bypass/drop entries, independent of SA processing. This is largely a > local matter for two reasons: 1) we have no means for coordinating SPD > entries for such traffic between IPsec implementations since IKE is > not invoked; 2) many of these entries refer to traffic that is NOT > directed to or received from a location that is using IPsec, so there > is no peer IPsec implementation with which to coordinate via any > means. However, 2401bis should provide guidance here, consistent with > our goal of offering a well-defined, access control function for all > traffic, relative to the IPsec boundary. To that end, I suggest that > implementations MAY choose to support fragment reassembly for > bypass/drop traffic when port fields are specified. An implementation > also MUST permit a user or administrator to accept such traffic or > reject such traffic using the SPD conventions described at the end of > this note. > > > Just say no to ports? > > It has been suggested that we could avoid the problems described above > by not allowing port field selectors to be used in tunnel mode. But > the discussion above shows this to be an unnecessarily stringent > approach, i.e., since no problems arise for the native OS and BITS > implementations. Moreover, some WG members have described scenarios > where use of tunnel mode SAs with (non-trivial) port field selectors > is appropriate. So the challenge is defining a strategy that can deal > with this problem in BITW and SG contexts. Also note that bypass/drop > entries in the SPD that make use of ports pose the same problems, > irrespective of tunnel vs. transport mode notions. > > Some folks have suggested that a firewall behind an SG or BITW should > be left to enforce port level access controls, and the effects of > fragmentation. However, this seems to be an incongruous suggestion in > that elsewhere in IPsec (e.g., in IKE payloads) we are concerned about > firewalls that always drop fragments! If many (most?) firewalls don't > pass fragments in general, why should we expect them deal with > fragments in this case? So, this analysis rejects the suggestion of > disallowing use of port field selectors with tunnel mode SAs. > > > Other Suggested Solutions > > One suggestion is to reassemble fragments at the sending IPsec > implementation, and thus avoid the problem entirely. This approach is > invisible to a receiver and thus could be adopted as a purely local > implementation option. > > A more sophisticated version of this suggestion calls for establishing > and maintaining minimal state from each initial fragment encountered, > to allow non-initial fragments to be matched to the right SAs or > SPD/cache entries. This implies an extension to the current processing > model (and the old one). One would intercept all fragments, capture > S/D address, protocol, packet ID, and port fields from initial > fragments and then use this data to map non-initial fragments to SAs > that require port fields. If this approach is employed, the receiver > needs to employ an equivalent scheme, as it too must verify that > received fragments are consistent with SA selector values. A > non-initial fragment that arrives prior to an initial fragment could > be cached or discarded, awaiting arrival of the corresponding initial > fragment. > > A downside of both approaches noted above is that they will not always > work. When a BITW device or SG is configured in a topology that might > allow some fragments for a packet to be processed at different SGs or > BITW devices, then there is no guarantee that all fragments will ever > arrive at the same IPsec device. This approach also raises possible > processing problems. If the sender caches non-initial fragments until > the corresponding initial fragment arrives, buffering problems might > arise, especially at high speeds. If the non-initial fragments are > discarded rather than cached, there is no guarantee that traffic will > ever pass, e.g., retransmission will result in different packet IDs > that cannot be matched with prior transmissions. In any case, > housekeeping procedures will be needed to decide when to delete the > fragment state data, adding some complexity to the system. > Nonetheless, this is a viable solution in some topologies, and these > are likely to be common topologies. > > Issue #81, which the WG rejected, suggested the convention of creating > an SA to carry only non-initial fragments, something that was > supported implicitly under the 2401 model via use of OPAQUE port > fields, but never clearly articulated in the RFC. The (rejected) text > called for each non-initial fragment to be treated as protocol 44 (the > IPv6 fragment header protocol ID) by the sender and receiver. This > approach has the potential to make IPv4 and v6 fragment handling more > uniform, but it does not fundamentally change the problem, nor dies it > address the issue of fragment handling for bypass/drop traffic. Given > the fragment overlap attack problem that IPv6 poses, it does not seem > that it is worth the effort to adopt this strategy. > > > Consistency > > Earlier the WG agreed (Issue #88) to allow an IPsec BITS, BITW or SG > to perform fragmentation prior to IPsec processing, after Mark Duffy > explain the motivation for this. If this fragmentation is performed > after SA lookup at the sender, there is no "mapping to the right SA" > problem. But, the receiver still needs to be able to verify that the > non-initial fragments are consistent with the SA via which they are > received. Since the initial fragment might be lost en route, the > receiver encounters all of the potential problems noted above. Thus, > if we are to be consistent in our decisions, we need to say how a > receiver will deal with the non-initial fragments that arrive. > > > Conclusions > > There is no simple, uniform way to handle fragments in all contexts. > Different approaches work better in different contexts. Thus I suggest > we require support for two approaches, and offer a third, and allow a > user or administrator to choose from among these based on topology > constraints and security requirements. Hence the following proposed text: > > 1. All implementations MUST support tunnel mode SAs that pass traffic > without regard to port field values. If the SA will carry traffic for > specified protocols, the two selector sets MUST be used to specify the > port fields for the SA: ANY and OPAQUE. An SA defined in this fashion > will carry all traffic for the indicated source/destination addresses > and specified protocol(s). If the SA will carry traffic without regard > to a specific protocol value (i.e., ANY is specified), then the port > field values MUST be set to ANY as well. > > 2. All implementations MUST support tunnel mode SAs that will carry > only non-initial fragments, separate from non-fragmented packets and > initial fragments. The OPAQUE value will be used to specify port field > selectors for an SA to carry non-initial fragments. Specific port > selector values will be used to define SAs to carry initial fragments > and non-fragmented packets. This approach can be used if a user or > administrator wants to create one or more tunnel mode SAs between the > same source/destination addresses that discriminate based on port > fields. These SAs MUST have non-trivial protocol selector values, > otherwise approach #1 above can be used. Receivers MUST perform a > minimum offset check on IPv4 (non-initial) fragments to protect > against overlapping fragment attacks when SAs of this type are > employed. Because such checks cannot be performed on IPv6 non-initial > fragments, users and administrators are advised that carriage of such > fragments may be dangerous, and implementers may choose to NOT support > such SAs for IPv6 traffic. Also, because a SA of this sort will carry > ALL non-initial fragments that match a specified source/destination > address pair and protocol value, users and administrators are advised > to protect such traffic using ESP (with integrity) and the "strongest" > integrity and encryption algorithms available at both peers. > (Determination of the "strongest" algorithms requires imposing a total > ordering of the available algorithms, a local determination at the > discretion of the initiator of the SA.) > > 3. An implementation MAY choose to support some form of stateful > fragment checking for a tunnel mode SA with non-trivial port field > values (not ANY or OPAQUE). Implementations that will transmit > non-initial fragments on a tunnel mode SA that makes use of > non-trivial port selectors MUST notify a peer via an IKE payload > (TBD). The peer MUST reject this proposal if it will not accept > non-initial fragments in this context. If an implementation does not > successfully negotiate transmission of non-initial fragments for such > an SA, it MUST NOT send such fragments over the SA. This standard does > not specify how peers will deal with such fragments, e.g., via > reassembly or other means, at either sender or receiver. However, a > receiver MUST drop non-initial fragments that arrive on an SA with > non-trivial port selector values unless this feature has been > negotiated. Dropping such packets is an auditable event. Note that in > configurations where fragments of a packet might be sent or received > via different security gateways or BITW implementations, stateful > strategies for tracking fragments may fail. > From owner-ipsec@lists.tislabs.com Tue Mar 23 04:34: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 i2NCYW8f069556; Tue, 23 Mar 2004 04:34:32 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA18939 Tue, 23 Mar 2004 06:49:52 -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=iso-8859-1 Message-ID: <16480.9936.57483.798886@fireball.acr.fi> Date: Tue, 23 Mar 2004 14:00:16 +0200 From: Tero Kivinen To: Stephen Kent Cc: Paul Hoffman / VPNC , ipsec@lists.tislabs.com Subject: Re: Remaining open issues for RFC-2401bis In-Reply-To: References: <200403200415.i2K4FlQU007773@thunk.east.sun.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 13 min X-Total-Time: 14 min Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id GAA18931 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > "An opaque octet stream which may be used to pass an account > name or to pass vendor-specific information necessary to do > certain proprietary types of identification." Vendor-specific sounds to me like anything I simply like to put there, including binary. Some uses for this has been proposed to support total identity protection including active attacks, i.e. where you use random ID_KEY_ID as your identity, and after you have connection ready and authenticated from both ends, you run some protocol that will give you new ID_KEY_ID to be used for the next time (this was mostly suggested for IKEv1 aggressive mode, where ID's are in clear otherwise). For that kind of usage, I see no point why it should restricted to the ASCII string. > This hardly sounds like an arbitrary byte string. I think arbitrary octect string easier for multiple reasons. If we say it is text we need to and the encoding to it (ISO 10646 UTF-8?). Doing that causes unnecessary code on some clients and servers, which might have the user database in latin-1 format or similar, and now they need to convert it UTF-8 and back when sending it over the wire. Using UTF-8 there does not help anything, as those implementations propably do not know how to convert the strings to normal format (i.e. they do not know how to convert a + umlauts to ä). On the other hand the client and server will have common security domain, which also defines the usernames, and the encoding used for them, thus it does not cause any problems to encode the Latin-1 username string as binary latin-1 octect stream when sent inside the IKE ID_KEY_ID. > IKE is very sloppy re choice of IDs, and this has not been fixed in > IKEv2. for example, in addition to explicit support for e-mail > addresses, IP addresses, and distinguished names, IOKEv2 calls for > support of the general name construct. But, this construct already > encompasses all of the preceding name types, plus others that seem > very unlikely to ever be of interest in our context, e.g., EDI Party > names! So, my suggestion is that we be a bit more restrictive with If the client and server agrees that they will use the EDI Party names (whatever that is) when identifying the each other, I do not see problem with that. I do not think every implementation should implement EDI Party name support though (it is not MUST)... > the supported name types. In that spirit, if we need to keep this as > an arbitrary byte string, we ought to provide some rationale for that > decision. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Tue Mar 23 06:01:30 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 i2NE1Up1075261; Tue, 23 Mar 2004 06:01:30 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA27496 Tue, 23 Mar 2004 08:22:16 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16480.15529.482315.278735@fireball.acr.fi> Date: Tue, 23 Mar 2004 15:33:29 +0200 From: Tero Kivinen To: Stephen Kent Cc: ipsec@lists.tislabs.com, russ housley Subject: 2nd try In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 41 min X-Total-Time: 52 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > Thus a possible question for the WG is whether 2401bis should relax > the prohibition on carriage of fragments on transport mode SAs for > IPv6 traffic? I suggest NOT allowing this, as it only adds to our > problems, but I thought I would mention it in the name of > completeness. I agree for not allowing that. > Tunnel Mode and Fragments ... > This problem largely, though not exclusively, motivated the > definition of OPAQUE as a selector value for port fields in RFC 2401. > The other motivation for OPAQUE is the observation that port fields > might not be accessible due to the prior application of IPsec. For > example, if a host applied IPsec to its traffic and that traffic > arrived at an SG, these fields would be encrypted. The algorithm > specified for locating the "next layer protocol" described in 2401 > also motivated use of OPAQUE to accommodate an encrypted next layer > protocol field in such circumstances. Nonetheless, the primary use of > the OPAQUE value was to match traffic selector fields in packets that > did not contain port fields (non-initial fragments), or packets in > which the port fields were already encrypted (as a result of nested > application of IPsec). 2401 was ambiguous in discussing the use of > OPAQUE vs. ANY, suggesting in some places that ANY might be an > alternative to OPAQUE. Note, that IKEv1 does not have way to negotiate OPAQUE, it only offers port number - 0 => Port field should be ignored == ANY+OPAQUE. > We gain additional access control capability by defining both ANY and > OPAQUE values. OPAQUE can be defined to match only fields that are > not accessible. We could define ANY as the complement of OPAQUE, > i.e., it would match all values but only for accessible port fields. > If we simplify the procedure employed to locate the next layer > protocol in 2401bis, so that we treat ESP and AH as next layer > protocols, then the notion of an encrypted next layer protocol field > has vanished, and there is also no need to worry about encrypted port > fields either. (We probably need to clarify the notion that ESP is > not an "extension header" re IPv6, despite the fact that the IPv6 > spec calls it that. The same is true for AH.) In that case, OPAQUE > will be applicable only to non-initial fragments. I think that treating ESP and AH as next layer protocol would be good idea. > The Problem of Non-Initial Fragments > > For an SG implementation, it is obvious that fragments might arrive > from end systems behind the SG. A BITW implementation also may > encounter fragments from a host or gateway behind it. (As noted > earlier, native host implementations and BITS implementations > probably can avoid the problems described below.) In the worst case, > fragments from a packet might arrive at distinct BITW or SG > instantiations and thus preclude reassembly as a solution option. > Hence, in 2401 we adopted a general requirement that fragments must > be accommodated in tunnel mode for all implementations. However, 2401 > did not provide a perfect solution. The use of OPAQUE as a selector > value for port fields (a SHOULD in 2401) allowed an SA to carry > non-initial fragments. And as IKEv1 didn't offer any support for OPAQUE, there cannot really be implementations using that method with IKEv1 (i.e. IKEv1 cannot negotiate such SA for OPAQUE traffic). > Bypass/Drop Traffic > > We also have to address the non-initial fragment processing issue for > bypass/drop entries, independent of SA processing. This is largely a > local matter for two reasons: 1) we have no means for coordinating > SPD entries for such traffic between IPsec implementations since IKE > is not invoked; 2) many of these entries refer to traffic that is NOT > directed to or received from a location that is using IPsec, so there > is no peer IPsec implementation with which to coordinate via any > means. However, 2401bis should provide guidance here, consistent with > our goal of offering a well-defined, access control function for all > traffic, relative to the IPsec boundary. To that end, I suggest that > implementations MAY choose to support fragment reassembly for > bypass/drop traffic when port fields are specified. An implementation > also MUST permit a user or administrator to accept such traffic or > reject such traffic using the SPD conventions described at the end of > this note. If you have SA with port selectors between SGWs you cannot allow clear text non-first fragments without (partial) reassembly between SGWs. I.e. if you have rules A <-> B port 25 ESP with auth A <-> B non-first fragments in clear (i.e. bypass) Then attacker who sees or (or forces) the A to send fragmented packet can modify the non-first fragments regardless whether the SGW1 encrypted all the fragments of the packet from A, and the SGW2 will accept them based on the second policy rule. . > Conclusions ... > 1. All implementations MUST support tunnel mode SAs that pass traffic > without regard to port field values. If the SA will carry traffic for > specified protocols, the two selector sets MUST be used to specify > the port fields for the SA: ANY and OPAQUE. An SA defined in this > fashion will carry all traffic for the indicated source/destination > addresses and specified protocol(s). If the SA will carry traffic > without regard to a specific protocol value (i.e., ANY is specified), > then the port field values MUST be set to ANY as well. Is this for traffic where the SGWs ignore the port field completely? Is this negotiated with IKEv2 by setting the port field range to 0-65535 (==ANY). > 2. All implementations MUST support tunnel mode SAs that will carry > only non-initial fragments, separate from non-fragmented packets and > initial fragments. The OPAQUE value will be used to specify port > field selectors for an SA to carry non-initial fragments. Specific > port selector values will be used to define SAs to carry initial > fragments and non-fragmented packets. This approach can be used if a If this is added, I think negotiating it in the IKE using the protocol 44 (issue #81), is much cleaner way than the special port values. On the other hand that does not allow negotiation of the only TCP fragments. Perhaps the special port range is then better, i.e. in IKE v2 use port range of 65535-0 (= non-first fragment). > user or administrator wants to create one or more tunnel mode SAs > between the same source/destination addresses that discriminate based > on port fields. These SAs MUST have non-trivial protocol selector > values, otherwise approach #1 above can be used. Receivers MUST > perform a minimum offset check on IPv4 (non-initial) fragments to > protect against overlapping fragment attacks when SAs of this type > are employed. Because such checks cannot be performed on IPv6 > non-initial fragments, users and administrators are advised that > carriage of such fragments may be dangerous, and implementers may > choose to NOT support such SAs for IPv6 traffic. Also, because a SA The beginning says this is MUST, and here you say implementators can choose not to support it. I think it shoud say it is MUST for IPv4 and MAY/SHOULD for IPv6 > of this sort will carry ALL non-initial fragments that match a > specified source/destination address pair and protocol value, users > and administrators are advised to protect such traffic using ESP > (with integrity) and the "strongest" integrity and encryption > algorithms available at both peers. (Determination of the "strongest" > algorithms requires imposing a total ordering of the available > algorithms, a local determination at the discretion of the initiator > of the SA.) > > 3. An implementation MAY choose to support some form of stateful > fragment checking for a tunnel mode SA with non-trivial port field > values (not ANY or OPAQUE). Implementations that will transmit > non-initial fragments on a tunnel mode SA that makes use of > non-trivial port selectors MUST notify a peer via an IKE payload > (TBD). Why? If the other end only supports the case #2, then it only needs to check that the SA which is used to carry the traffic has enough security to take care of the non-initial fragments. I.e. if the senders policy is use ESP AES for port 25, and the responders is use ESP AES for port 25, and any ESP stronger than 80-bits for non-inigial fragments, then it can safely accept the non-initial packets coming from the SA negotiated for the port 25. > The peer MUST reject this proposal if it will not accept > non-initial fragments in this context. If an implementation does not > successfully negotiate transmission of non-initial fragments for such > an SA, it MUST NOT send such fragments over the SA. This standard > does not specify how peers will deal with such fragments, e.g., via > reassembly or other means, at either sender or receiver. However, a > receiver MUST drop non-initial fragments that arrive on an SA with > non-trivial port selector values unless this feature has been > negotiated. Dropping such packets is an auditable event. Note that in > configurations where fragments of a packet might be sent or received > via different security gateways or BITW implementations, stateful > strategies for tracking fragments may fail. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Tue Mar 23 06:16:20 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NEGJiT076356; Tue, 23 Mar 2004 06:16:20 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA29862 Tue, 23 Mar 2004 08:44:14 -0500 (EST) Message-Id: <200403231354.i2NDsVSj040527@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Stephen Kent cc: ipsec@lists.tislabs.com, russ housley Subject: Re: 2nd try In-reply-to: Your message of Mon, 22 Mar 2004 21:05:54 EST. Date: Tue, 23 Mar 2004 14:54:31 +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: (We probably need to clarify the notion that ESP is not an "extension header" re IPv6, despite the fact that the IPv6 spec calls it that. The same is true for AH.) => in a private discussion a fine proposal was defined: talk about extension headers using the generic extension header format. (ESP, AH and IPCOMP don't use the generic format, AH because the length field is in another unit). In that case, OPAQUE will be applicable only to non-initial fragments. => in theory the upper layer header can be in a non-initial fragment when a (large) destination option header is used, so in IPv6 OPAQUE can be applicable to all fragments. Regards Francis.Dupont@enst-bretagne.fr PS: BTW there is no OPAQUE encoding in the current IKEv2 draft... From owner-ipsec@lists.tislabs.com Tue Mar 23 08:03: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 i2NG38AS085458; Tue, 23 Mar 2004 08:03:08 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10344 Tue, 23 Mar 2004 10:23:53 -0500 (EST) Message-Id: <5.2.0.9.2.20040323102041.03d5bf08@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 23 Mar 2004 10:31:45 -0500 To: Jimmy.Hsieh@rdc.com.tw From: Russ Housley Subject: Re: Question with Using AES CCM Mode With IPsec ESP Cc: ipsec@lists.tislabs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jimmy: I do not find any problems between the CCM cipher specification and the latest ESP draft. By the way, the CCM specification is in the RFC Editor's queue. 1. Only the low order bits are transmitted. The AAD is constructed by the sender and the receiver from other information. A combined mode specification could specify that the high order bits are transmitted and that would still be consistent with the ESP specification, but the CCM cipher specification does not do so. 2. The CCM cipher specification defines the structure for the AAD. With regard to combined mode algorithms, the ESP draft says: The Sequence Number (or Extended Sequence Number, as appropriate) and the SPI are inputs to the algorithm, as they must be included in the integrity check computation. The means by which these values are included in this computation are a function of the combined mode algorithm employed and thus not specified in this standard. Again, I see no problem. Russ At 02:02 PM 3/8/2004 +0800, =?big5?B?SmltbXkgSHNpZWggKMHCqN2n+Ck=?= wrote: >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 Tue Mar 23 08:32: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 i2NGWdvQ088050; Tue, 23 Mar 2004 08:32:40 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15780 Tue, 23 Mar 2004 10:58:28 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: <200403200415.i2K4FlQU007773@thunk.east.sun.com> Date: Tue, 23 Mar 2004 08:10:09 -0800 To: Stephen Kent From: Paul Hoffman / VPNC Subject: Re: Remaining open issues for RFC-2401bis Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:35 PM -0500 3/22/04, Stephen Kent wrote: >Since all ID's sent via IKE are used for access control, it seems >reasonable to assume that, in general, people have interacted with a >management interface to enter these IDs. Fully agree. > So, unless there is a need to transmit an arbitrary octet string >for ID purposes, it would be more appropriate to constrain this to >something that a user has a good chance of getting right. Also fully agree. >The IKE v2 specs says (page 55) > > "An opaque octet stream which may be used to pass an account > name or to pass vendor-specific information necessary to do > certain proprietary types of identification." > >This hardly sounds like an arbitrary byte string. Fully disagree. "opaque octet stream" sounds exactly like "arbitrary byte string" to me. >IKE is very sloppy re choice of IDs, and this has not been fixed in IKEv2. Fully agree. > for example, in addition to explicit support for e-mail addresses, >IP addresses, and distinguished names, IOKEv2 calls for support of >the general name construct. But, this construct already encompasses >all of the preceding name types, plus others that seem very unlikely >to ever be of interest in our context, e.g., EDI Party names! I tried to get this fixed a while back, and was shot down. > So, my suggestion is that we be a bit more restrictive with the >supported name types. In that spirit, if we need to keep this as an >arbitrary byte string, we ought to provide some rationale for that >decision. Also fully agree. I'm happy if we change this field in IKEV to "UTF-8 text string" (changing it to ASCII is not a reasonable option). However, I'm not happy with leaving IKEv2 alone and having that requirement (or, even worse, that assumption) come in 2401bis. If IKEv2 is left as it is, 2401bit should not change the interpretation of the field. Otherwise, boxes that follow 2401bis might fall over when handed a non-UTF-8 octet stream. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Mar 23 08:35: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 i2NGZHCU088201; Tue, 23 Mar 2004 08:35:17 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15600 Tue, 23 Mar 2004 10:57:13 -0500 (EST) Date: Tue, 23 Mar 2004 18:06:18 +0200 Message-Id: <200403231606.i2NG6IVc011645@burp.tkv.asdf.org> From: Markku Savela To: ipsec@lists.tislabs.com In-reply-to: <16480.15529.482315.278735@fireball.acr.fi> (message from Tero Kivinen on Tue, 23 Mar 2004 15:33:29 +0200) Subject: Re: 2nd try References: <16480.15529.482315.278735@fireball.acr.fi> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Somewhat related to the "2nd try" text. I'm somewhat curious how implementations plan to handle this fragmentation issue: (1) IPSEC must verify the policy of packets before they are given to the reassembly, and (2) IPSEC must ALSO verify the policy for the complete the packet after it has been reassembled. This is the normal case where IPSEC is applied to complete packet and the result fragmented (IPSEC can be done only after reassembly). TCP/IP ------> Fragment ----> (1) Assembly (2) IPSEC IPSEC Policy Policy Check Check "2nd try" text relates to (1) IPSEC. How does the (2) IPSEC know that a complete packet coming out of fragment assembly is has been checked or not? (The packet looks like plain unprotected packet, which by all normal rules should be dropped, if policy required it to be protected). To work, IPSEC must be able to associate some additional information with the packet in the assembly? From owner-ipsec@lists.tislabs.com Tue Mar 23 09:13: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 i2NHDQrZ091580; Tue, 23 Mar 2004 09:13:26 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22611 Tue, 23 Mar 2004 11:35:40 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16480.9936.57483.798886@fireball.acr.fi> References: <200403200415.i2K4FlQU007773@thunk.east.sun.com> <16480.9936.57483.798886@fireball.acr.fi> Date: Tue, 23 Mar 2004 11:25:09 -0500 To: Tero Kivinen From: Stephen Kent Subject: Re: Remaining open issues for RFC-2401bis Cc: Paul Hoffman / VPNC , ipsec@lists.tislabs.com Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA22605 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:00 PM +0200 3/23/04, Tero Kivinen wrote: >Stephen Kent writes: >> "An opaque octet stream which may be used to pass an account >> name or to pass vendor-specific information necessary to do >> certain proprietary types of identification." > >Vendor-specific sounds to me like anything I simply like to put there, >including binary. Some uses for this has been proposed to support >total identity protection including active attacks, i.e. where you use >random ID_KEY_ID as your identity, and after you have connection ready >and authenticated from both ends, you run some protocol that will give >you new ID_KEY_ID to be used for the next time (this was mostly >suggested for IKEv1 aggressive mode, where ID's are in clear >otherwise). so, the problem we have is that the same ID type is defined to have two different uses: an account name, for which an IA5 or UTF-8 string would be appropriate, or an arbitrary byte sting, for which no further encoding is appropriate. I would be happy if we choose ONE of these two, but having both listed is a recipe for non-interoperability. As for using a random number as an ID, note that this may not play well with the PAD description that we published. > >For that kind of usage, I see no point why it should restricted to the >ASCII string. > >> This hardly sounds like an arbitrary byte string. > >I think arbitrary octect string easier for multiple reasons. If we say >it is text we need to and the encoding to it (ISO 10646 UTF-8?). Doing >that causes unnecessary code on some clients and servers, which might >have the user database in latin-1 format or similar, and now they need >to convert it UTF-8 and back when sending it over the wire. Using >UTF-8 there does not help anything, as those implementations propably >do not know how to convert the strings to normal format (i.e. they do >not know how to convert a + umlauts to ä). I agree that IF the intent is to send an arbitrary byte string for a vendor-specific purpose, then UTF-8 encoding is inappropriate. However, if the intent is to send a user account name, then such encoding is appropriate. That's why I suggest that we disentangle these two different uses for the field. >On the other hand the client and server will have common security >domain, which also defines the usernames, and the encoding used for >them, thus it does not cause any problems to encode the Latin-1 >username string as binary latin-1 octect stream when sent inside the >IKE ID_KEY_ID. I disagree. There is no reason to believe that there will be an appropriate management interface to allow for easy entry of a UTF-8 account name by a user or admin if the only requirement is to support binary values for this field. > >> IKE is very sloppy re choice of IDs, and this has not been fixed in >> IKEv2. for example, in addition to explicit support for e-mail >> addresses, IP addresses, and distinguished names, IOKEv2 calls for >> support of the general name construct. But, this construct already >> encompasses all of the preceding name types, plus others that seem >> very unlikely to ever be of interest in our context, e.g., EDI Party >> names! So, my suggestion is that we be a bit more restrictive with > >If the client and server agrees that they will use the EDI Party names >(whatever that is) when identifying the each other, I do not see >problem with that. I do not think every implementation should >implement EDI Party name support though (it is not MUST)... same argument as above, For interoperability we want to ensure that any ID form that either end may use will be easy to enter and manage by everyone. Unless we have some good reason to believe that EDI Part names, and X.400 addresses are appropriate ID forms for IPsec, then we ought not provide a means to carry them, since such carriage should be matched by a requirement for a management interface for them in every IPsec implementation. Flexibility is not free if we want interoperability at the same time. If we make provision for carriage of arbitrary strings as IDs in IKEv2 mandatory, then we have a responsibility to ensure that IPsec implementations have a means to make use of them when the arrive. Otherwise we create opportunities for non-interopeability. Steve From owner-ipsec@lists.tislabs.com Tue Mar 23 09:13:37 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NHDbQU091595; Tue, 23 Mar 2004 09:13:37 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22519 Tue, 23 Mar 2004 11:35:20 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <40604BEF.9060204@isi.edu> References: <200403200415.i2K4FlQU007773@thunk.east.sun.com> <40604BEF.9060204@isi.edu> Date: Tue, 23 Mar 2004 11:27:51 -0500 To: Joe Touch From: Stephen Kent Subject: Re: Remaining open issues for RFC-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 6:38 AM -0800 3/23/04, Joe Touch wrote: >Stephen Kent wrote: >>Paul, >> >>Since all ID's sent via IKE are used for access control, it seems >>reasonable to assume that, in general, people have interacted with >>a management interface to enter these IDs. So, unless there is a >>need to transmit an arbitrary octet string for ID purposes, it >>would be more appropriate to constrain this to something that a >>user has a good chance of getting right. >> >>The IKE v2 specs says (page 55) >> >> "An opaque octet stream which may be used to pass an account >> name or to pass vendor-specific information necessary to do >> certain proprietary types of identification." >> >>This hardly sounds like an arbitrary byte string. > >"opaque" isn't particularly vague on that point ;-) > >It specifies an arbitrary byte string, by definition. There is no >semantics for the string at the IKE level, so there should be no >restrictions on its contents. > >Joe See my response to Tero. The IKE text is schizophrenic on the semantics, and there are interoperability implications with viewing this in both ways. Steve From owner-ipsec@lists.tislabs.com Tue Mar 23 09:42:20 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NHgJcV093570; Tue, 23 Mar 2004 09:42:19 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27739 Tue, 23 Mar 2004 12:09:13 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: <200403200415.i2K4FlQU007773@thunk.east.sun.com> Date: Tue, 23 Mar 2004 12:19:32 -0500 To: Paul Hoffman / VPNC From: Stephen Kent Subject: Re: Remaining open issues for RFC-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 Paul, I think we're in close agreement on essentially all points, including UTF-8, not ASCII, if the WG chooses to narrow the scope of the ID semantics. I would rather not have 2401bis profile IKEv2, but I also reluctant to have gaps, so I thin iot is good to resolve this now. Steve From owner-ipsec@lists.tislabs.com Tue Mar 23 09:50:08 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 i2NHo8xH093984; Tue, 23 Mar 2004 09:50:08 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28874 Tue, 23 Mar 2004 12:16:08 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: Remaining open issues for RFC-2401bis In-reply-to: Your message of "Tue, 23 Mar 2004 08:10:09 PST." X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Tue, 23 Mar 2004 12:26:53 -0500 Message-ID: <3023.1080062813@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Kent> Since all ID's sent via IKE are used for access control, it seems Kent> reasonable to assume that, in general, people have interacted Kent> with a management interface to enter these IDs. Let's rephase this so that I agree: When IPsec is used for access control (such as VPNs or RemoteAccess), then all IDs sent via IKE are used for access control, it seems reasonable to assume that, in general, people have interacted with a management interface to enter these IDs. Maybe this is a tautology. Maybe not. As long as there is a mapping from the ID to the access control policy, then I don't have a problem with this statement. VPNC> Also fully agree. I'm happy if we change this field in IKEV to VPNC> "UTF-8 text string" (changing it to ASCII is not a reasonable VPNC> option). However, I'm not happy with leaving IKEv2 alone and VPNC> having that requirement (or, even worse, that assumption) come VPNC> in 2401bis. If IKEv2 is left as it is, 2401bit should not VPNC> change the interpretation of the field. Otherwise, boxes that VPNC> follow 2401bis might fall over when handed a non-UTF-8 octet VPNC> stream. That's fine, but I personally see Kivinen's point. I don't know why a UTF-8 can't go into a different ID type. - -- ] 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 iQCVAwUBQGBzXIqHRg3pndX9AQEsTgP+N3n8IxpMAVidpRntsk2H/COwzG4oz7Lv cMqK8+5inJ2+wqmjeTUnQo+1H/5EPlRbrwxR/dHJWwBd5kn8nNubYQNGHFfZIIJj rSAZgJjjOQk9/JoGFOD1EmTQGk6OQnmF5Ar70vJ1X911od/qSIxPt9V+MEGBy1y9 nWPcojxgw7E= =//Tn -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Mar 23 10:27: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 i2NIR0IC097097; Tue, 23 Mar 2004 10:27:00 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04309 Tue, 23 Mar 2004 12:43:31 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200403231606.i2NG6IVc011645@burp.tkv.asdf.org> References: <16480.15529.482315.278735@fireball.acr.fi> <200403231606.i2NG6IVc011645@burp.tkv.asdf.org> Date: Tue, 23 Mar 2004 12:32:51 -0500 To: Markku Savela From: Stephen Kent Subject: Re: 2nd try 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 6:06 PM +0200 3/23/04, Markku Savela wrote: >Somewhat related to the "2nd try" text. I'm somewhat curious how >implementations plan to handle this fragmentation issue: > > (1) IPSEC must verify the policy of packets before they are given to > the reassembly, and I don't think this is true if one chooses to support reassembly, or partial reassembly in IPsec. That process requires maintaining state on a per SA basis, and thus might be expected to be performed as part of SA- processing. > (2) IPSEC must ALSO verify the policy for the complete the packet > after it has been reassembled. This is the normal case where IPSEC is > applied to complete packet and the result fragmented (IPSEC can be > done only after reassembly). this sounds like reassembly on the ciphertext/unprotected side of an IPsec receiver, a very different case from what we have been discussing. > > > TCP/IP > ------> Fragment ----> > (1) Assembly (2) > IPSEC IPSEC > Policy Policy > Check Check > >"2nd try" text relates to (1) IPSEC. How does the (2) IPSEC know that >a complete packet coming out of fragment assembly is has been checked >or not? (The packet looks like plain unprotected packet, which by all >normal rules should be dropped, if policy required it to be >protected). > >To work, IPSEC must be able to associate some additional information >with the packet in the assembly? this seems to assume a particular implementation approach, and is analogous to the issue we have discussed previously, i.e., performing firewall checks outside of the IPsec context requires access to SA info that would not normally be available at that point. Steve From owner-ipsec@lists.tislabs.com Tue Mar 23 10:33: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 i2NIXbL6097832; Tue, 23 Mar 2004 10:33:38 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA06428 Tue, 23 Mar 2004 12:55:14 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: <200403200415.i2K4FlQU007773@thunk.east.sun.com> Date: Tue, 23 Mar 2004 12:19:32 -0500 To: Paul Hoffman / VPNC From: Stephen Kent Subject: Re: Remaining open issues for RFC-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 Paul, I think we're in close agreement on essentially all points, including UTF-8, not ASCII, if the WG chooses to narrow the scope of the ID semantics. I would rather not have 2401bis profile IKEv2, but I also reluctant to have gaps, so I thin iot is good to resolve this now. Steve From owner-ipsec@lists.tislabs.com Tue Mar 23 10:48:10 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NIm9WG098787; Tue, 23 Mar 2004 10:48:09 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09318 Tue, 23 Mar 2004 13:11:22 -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=iso-8859-1 Message-ID: <16480.32863.476549.187521@fireball.acr.fi> Date: Tue, 23 Mar 2004 20:22:23 +0200 From: Tero Kivinen To: Stephen Kent Cc: Paul Hoffman / VPNC , ipsec@lists.tislabs.com Subject: Re: Remaining open issues for RFC-2401bis In-Reply-To: References: <200403200415.i2K4FlQU007773@thunk.east.sun.com> <16480.9936.57483.798886@fireball.acr.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 17 min X-Total-Time: 17 min Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA09315 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > so, the problem we have is that the same ID type > is defined to have two different uses: an account > name, for which an IA5 or UTF-8 string would be There is no text in the IKEv1 defining it to be account name. IKEv1 defined it to be "an opaque byte stream which may be used to pass vendor-specific information necessary to identify which pre- shared key should be used to authenticate Aggressive mode negotiations." This account name thing was added in the IKEv2, and I do not know why it was added. > appropriate, or an arbitrary byte sting, for > which no further encoding is appropriate. I would > be happy if we choose ONE of these two, but > having both listed is a recipe for > non-interoperability. Do we really need account name? Why cannot be use rfc822 address? How about using the ID_KEY_ID to send the uid of the unix machine (i.e. the numeric user id, as 16/32 bit number (2/4 octects)). > As for using a random number as an ID, note that this may not play > well with the PAD description that we published. Why not, after the new ID has been exchanged, both the server and client, will simply reconfigure the PAD to include the new ID. > I agree that IF the intent is to send an > arbitrary byte string for a vendor-specific > purpose, then UTF-8 encoding is inappropriate. > However, if the intent is to send a user account > name, then such encoding is appropriate. That's > why I suggest that we disentangle these two > different uses for the field. We already have rfc822 address for user account name, why would we need separate account name id? The ID_KEY_ID is also defined to be something that is NOT matched against anything in the certificates etc, it is only matched against the built in policy (i.e. mostly usefull in shared-key authentication). In those case the bit-comparison is much better. > >On the other hand the client and server will have common security > >domain, which also defines the usernames, and the encoding used for > >them, thus it does not cause any problems to encode the Latin-1 > >username string as binary latin-1 octect stream when sent inside the > >IKE ID_KEY_ID. > > I disagree. There is no reason to believe that > there will be an appropriate management interface > to allow for easy entry of a UTF-8 account name > by a user or admin if the only requirement is to > support binary values for this field. Why should there interface to allow UTF-8 account names, if the only thing the adminstrator is going to use it, is to account names in the policy specified format. If my account name is Törvelä, I will encode it in the same way in my client and in my server, as they are most likely adminstrated by the same persons. If the adminstrator cannot enter my account name, he will propably say, that your new account name for the VPN use will be "Torvela". > same argument as above, For interoperability we > want to ensure that any ID form that either end > may use will be easy to enter and manage by > everyone. Unless we have some good reason to > believe that EDI Part names, and X.400 addresses > are appropriate ID forms for IPsec, then we > ought not provide a means to carry them, since > such carriage should be matched by a requirement > for a management interface for them in every > IPsec implementation. If I undertand correctly, the general name is there, because it can be matched against the certificate, and in some cases people might have setup where they allow you to login if you just happen to have valid certificate from that certain CA, and you can use any ID that can be found from the certificate as your ID. The pki4ipsec wg is working on that issue. This issue does not cover ID_KEY_ID, as it will not be in the certificates. If we say that ID_KEY_ID is octect string, and adminstrators must allow support for any binary string there, then we can put configure the system to use ISO 10646 UTF-8 account names, uid, Latin-1 account or plain ASCII account names. If the implementator is stupid and does not include easy way to enter the ISO 10646 UTF-8 account names, it does not still affect the interoperability, it just makes the configuration harder. > Flexibility is not free if we want > interoperability at the same time. If we make > provision for carriage of arbitrary strings as > IDs in IKEv2 mandatory, then we have a > responsibility to ensure that IPsec > implementations have a means to make use of them > when the arrive. Otherwise we create > opportunities for non-interopeability. If we say it is opaque octect string, and implementationtions MUST support any binary data up to 32 bytes in it, it defines exactly an interoperable use for the ID_KEY_ID. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Tue Mar 23 11:49:17 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NJnGpx003397; Tue, 23 Mar 2004 11:49:16 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23220 Tue, 23 Mar 2004 14:08:59 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: Remaining open issues for RFC-2401bis In-Reply-To: Message from Stephen Kent of "Tue, 23 Mar 2004 11:25:09 EST." References: <200403200415.i2K4FlQU007773@thunk.east.sun.com> <16480.9936.57483.798886@fireball.acr.fi> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Tue, 23 Mar 2004 14:21:21 -0500 Message-ID: <7396.1080069681@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Why wouldn't an "account name" be represented as ID_RFC822_ADDR? Perhaps the @domain may seem redundant to some, but it certainly doesn't hurt anyone. If it was a big problem, I'd rather relax it to make @-part optional than say any more than ID_KEY_ID says right now. In particular, I think that an appropriate comparison function for ID_KEY_ID is "memcmp()", while I'm sure that ID_RFC822_ADDR needs to be parsed in some way and then compared in a more structured fashion. Is UTF-8 welcome in ID_FQDN, ID_RFC822_ADDR? - -- ] 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 iQCVAwUBQGCOLoqHRg3pndX9AQGwNgQAtoizLrVAWhbRSAKCV/dSrIvAqROi4CM0 SL5FIyRRZimi7ZiF0ZNkC5vKybCUif9eHNmQ/12UtrAsHrZHYYmAvJBWxaoBraGx 69PzfHf2DlnRrIeBwdduHGc2vO0c+tucQy9HnuCHdKDOuSCeLfnzmh5qqpQCabgY oFLhNOz+TkI= =qFzg -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Mar 23 12:02: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 i2NK25wp004727; Tue, 23 Mar 2004 12:02:05 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26776 Tue, 23 Mar 2004 14:23:46 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: Remaining open issues for RFC-2401bis In-reply-to: Your message of "Tue, 23 Mar 2004 20:22:23 +0200." <16480.32863.476549.187521@fireball.acr.fi> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Tue, 23 Mar 2004 14:36:11 -0500 Message-ID: <8148.1080070571@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- (mostly, "What Tero said") >>>>> "Tero" == Tero Kivinen writes: Tero> We already have rfc822 address for user account name, why Tero> would we need separate account name id? The ID_KEY_ID is also Tero> defined to be something that is NOT matched against anything Tero> in the certificates etc, it is only matched against the built Tero> in policy (i.e. mostly usefull in shared-key Tero> authentication). In those case the bit-comparison is much Tero> better. The reason I can imagine (now, after reading your message) is because the certificate (not RSA key) doesn't have that rfc822 address in it, and the gateway isn't cable of having policy indexed by anything not in the certificate unless it is ID_KEY_ID. (I think such a gateway is totally broken, though) - -- ] 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 iQCVAwUBQGCRqoqHRg3pndX9AQEs/gQAv1bK+z2t/Yzb+BmbsH63OHfyMZV8QHxp OlwP4460kde43EPrO377nmEuaMHcPouXRWvNgTiFKz3LA+qZwjJk0Xet7LrYVYgc 6DNvTL5PfbE3SJjuSptmTpg7xlfwtGyc74IIAXy315fwBRggDmf6iHxRHACshYrE b2QCBZZ94uI= =it/s -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Mar 23 13:09: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 i2NL9U0n010073; Tue, 23 Mar 2004 13:09:30 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13938 Tue, 23 Mar 2004 15:31:21 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16480.41328.206013.705605@gargle.gargle.HOWL> Date: Tue, 23 Mar 2004 15:43:28 -0500 From: Paul Koning To: mcr@sandelman.ottawa.on.ca Cc: ipsec@lists.tislabs.com Subject: Re: Remaining open issues for RFC-2401bis References: <200403200415.i2K4FlQU007773@thunk.east.sun.com> <16480.9936.57483.798886@fireball.acr.fi> <7396.1080069681@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Michael" == Michael Richardson writes: Michael> -----BEGIN PGP SIGNED MESSAGE----- Why wouldn't an "account Michael> name" be represented as ID_RFC822_ADDR? Because not all accounts have English names? paul From owner-ipsec@lists.tislabs.com Tue Mar 23 14:22: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 i2NMMZEP017062; Tue, 23 Mar 2004 14:22:36 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00286 Tue, 23 Mar 2004 16:41:40 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: Remaining open issues for RFC-2401bis In-reply-to: Your message of "Tue, 23 Mar 2004 15:43:28 EST." <16480.41328.206013.705605@gargle.gargle.HOWL> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Tue, 23 Mar 2004 16:52:41 -0500 Message-ID: <13871.1080078761@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Paul" == Paul Koning writes: Michael> -----BEGIN PGP SIGNED MESSAGE----- Why wouldn't an "account Michael> name" be represented as ID_RFC822_ADDR? Paul> Because not all accounts have English names? 1) we have ways of encoding UTF-8 into From:/To: lines, we could use that. 2) we could agree to permit UTF-8 in RFC822_ADDR. - -- ] 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 iQCVAwUBQGCxqIqHRg3pndX9AQHPQAQA2Fb7mEjRsELzEU9/Zf3vWKFCeyIUQjbU kXpuHztEpGnXhGOO7MNEpkd1gKf2Md31Rpl12gAMYFVNv2C1lB2CHQrlR+pRXYcQ ZO27oxjbCq8H3Xbc5AMLcmng0CinzxtyLSWr1pLboeEkIKw65wt3nlk6zEOZbj/P t01R2l+1yzI= =tPLP -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Mar 23 15:59: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 i2NNxXY4025671; Tue, 23 Mar 2004 15:59:37 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25028 Tue, 23 Mar 2004 18:16:15 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <13871.1080078761@marajade.sandelman.ottawa.on.ca> References: <13871.1080078761@marajade.sandelman.ottawa.on.ca> Date: Tue, 23 Mar 2004 15:27:34 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Remaining open issues for RFC-2401bis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:52 PM -0500 3/23/04, Michael Richardson wrote: > 1) we have ways of encoding UTF-8 into From:/To: lines, we could > use that. No, we don't. We have ways of encoding the display name and the coments, but *not* the address itself (called the "addr-spec"). RFC 822 and 2822 are completely clear on this. > 2) we could agree to permit UTF-8 in RFC822_ADDR. Doing so and hoping that the Applications Area Directors don't barf is like applications folks saying "we can just send cleartext passwords in the clear here" and hoping that the Security Area Directors don't barf. It is reasonable to have one plain text or an opaque binary identifier. There is no need to mess up one of the few clear identifiers we have. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Mar 23 16:08:07 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2O0865Q026419; Tue, 23 Mar 2004 16:08:06 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA26469 Tue, 23 Mar 2004 18:25:09 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Tue, 23 Mar 2004 15:32:01 -0800 To: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-rfc2402bis-07.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Authentication Header Author(s) : S. Kent Filename : draft-ietf-ipsec-rfc2402bis-07.txt Pages : 33 Date : 2004-3-2 This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2402bis-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-rfc2402bis-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-rfc2402bis-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. [The following attachment must be fetched by mail. Command-click the URL below and send the resulting message to get the attachment.] [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] From owner-ipsec@lists.tislabs.com Tue Mar 23 16:09:51 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 i2O09oS2026536; Tue, 23 Mar 2004 16:09:51 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA26493 Tue, 23 Mar 2004 18:25:15 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Tue, 23 Mar 2004 15:32:14 -0800 To: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esp-v3-08.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Encapsulating Security Payload (ESP) Author(s) : S. Kent Filename : draft-ietf-ipsec-esp-v3-08.txt Pages : 43 Date : 2004-3-2 This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-v3-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-esp-v3-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. [The following attachment must be fetched by mail. Command-click the URL below and send the resulting message to get the attachment.] [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] From owner-ipsec@lists.tislabs.com Tue Mar 23 16:23: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 i2O0NQxa028149; Tue, 23 Mar 2004 16:23:26 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01244 Tue, 23 Mar 2004 18:47:44 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Tue, 23 Mar 2004 15:39:24 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Temporary version of the new IKEv2 draft Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. At Charlie's request, I have just posted a temporary version of the new IKEv2 draft at . This version will disappear when the official draft is posted to the Internet Drafts web site and the announcement appears on this mailing list. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Mar 23 17:30: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 i2O1Uad5031721; Tue, 23 Mar 2004 17:30:36 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA14728 Tue, 23 Mar 2004 19:53:07 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16480.56991.690000.612956@gargle.gargle.HOWL> Date: Tue, 23 Mar 2004 20:04:31 -0500 From: Paul Koning To: mcr@sandelman.ottawa.on.ca Cc: ipsec@lists.tislabs.com Subject: Re: Remaining open issues for RFC-2401bis References: <16480.41328.206013.705605@gargle.gargle.HOWL> <13871.1080078761@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Michael" == Michael Richardson writes: Michael> -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Paul" == Paul Koning writes: Michael> -----BEGIN PGP SIGNED MESSAGE----- Why wouldn't an "account Michael> name" be represented as ID_RFC822_ADDR? Paul> Because not all accounts have English names? Michael> 1) we have ways of encoding UTF-8 into From:/To: lines, we Michael> could use that. Yes, but that's a kluge to retrofit other character sets into a 7-bit limited protocol. We don't need to carry those things forward into non-ancient protocols. paul From owner-ipsec@lists.tislabs.com Tue Mar 23 20:31: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 i2O4VR3A043491; Tue, 23 Mar 2004 20:31:27 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA22424 Tue, 23 Mar 2004 22:50:52 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: Question with Using AES CCM Mode With IPsec ESP Date: Wed, 24 Mar 2004 12:05:13 +0800 Message-ID: Thread-Topic: Question with Using AES CCM Mode With IPsec ESP thread-index: AcQQ7GX7qfPBHY8CRle3z8yhijE2AgAaFijA From: =?iso-2022-jp?B?SmltbXkgSHNpZWggKBskQjxVUFJCPBsoQik=?= To: "Russ Housley" Cc: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks a lot. Jimmy Hsieh -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Tuesday, March 23, 2004 11:32 PM To: Jimmy Hsieh Cc: ipsec@lists.tislabs.com Subject: Re: Question with Using AES CCM Mode With IPsec ESP Jimmy: I do not find any problems between the CCM cipher specification and the latest ESP draft. By the way, the CCM specification is in the RFC Editor's queue. 1. Only the low order bits are transmitted. The AAD is constructed by the sender and the receiver from other information. A combined mode specification could specify that the high order bits are transmitted and that would still be consistent with the ESP specification, but the CCM cipher specification does not do so. 2. The CCM cipher specification defines the structure for the AAD. With regard to combined mode algorithms, the ESP draft says: The Sequence Number (or Extended Sequence Number, as appropriate) and the SPI are inputs to the algorithm, as they must be included in the integrity check computation. The means by which these values are included in this computation are a function of the combined mode algorithm employed and thus not specified in this standard. Again, I see no problem. Russ At 02:02 PM 3/8/2004 +0800, =?big5?B?SmltbXkgSHNpZWggKMHCqN2n+Ck=?= wrote: >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 Wed Mar 24 00:54: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 i2O8shiK012372; Wed, 24 Mar 2004 00:54:43 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA10923 Wed, 24 Mar 2004 03:09:14 -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: <38E66F82-7D6C-11D8-A750-000A95834BAA@checkpoint.com> Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com From: Yoav Nir Subject: Re: Temporary version of the new IKEv2 draft Date: Wed, 24 Mar 2004 10:21:17 +0200 To: Paul Hoffman / VPNC X-Mailer: Apple Mail (2.613) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Again, regarding section 2.16, I believe it should say, that the Initiator MAY send the AUTH payload before the EAP success message, in which case the Responder SHOULD send the AUTH, SAr2, TSi, TSr along with the EAP-success. In this case, the initial SA establishment will be shortened to 6 messages. On Mar 24, 2004, at 1:39 AM, Paul Hoffman / VPNC wrote: > Greetings again. At Charlie's request, I have just posted a temporary > version of the new IKEv2 draft at > . > This version will disappear when the official draft is posted to the > Internet Drafts web site and the announcement appears on this mailing > list. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Wed Mar 24 01:14:14 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 i2O9EDgh019850; Wed, 24 Mar 2004 01:14:13 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA14877 Wed, 24 Mar 2004 03:33:14 -0500 (EST) Date: Wed, 24 Mar 2004 02:44:58 -0600 From: Nicolas Williams To: Paul Koning Cc: mcr@sandelman.ottawa.on.ca, ipsec@lists.tislabs.com Subject: Re: Remaining open issues for RFC-2401bis Message-ID: <20040324084458.GH5868@binky.central.sun.com> Mail-Followup-To: Paul Koning , mcr@sandelman.ottawa.on.ca, ipsec@lists.tislabs.com References: <200403200415.i2K4FlQU007773@thunk.east.sun.com> <16480.9936.57483.798886@fireball.acr.fi> <7396.1080069681@marajade.sandelman.ottawa.on.ca> <16480.41328.206013.705605@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16480.41328.206013.705605@gargle.gargle.HOWL> User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Mar 23, 2004 at 03:43:28PM -0500, Paul Koning wrote: > >>>>> "Michael" == Michael Richardson writes: > > Michael> -----BEGIN PGP SIGNED MESSAGE----- Why wouldn't an "account > Michael> name" be represented as ID_RFC822_ADDR? > > Because not all accounts have English names? Subverting ID_KEY_ID to carry UTF-8 does not fix any I18N shortcommings of subjectAltName. I18N has to be dealt with, but stuffing possibly unstructured UTF08 text into an OCTET STRING in context specific ways isn't going to be very useful. I suggest that I18N be addressed separately and that ID_KEY_ID remain as it is: opaque. Does this mean that ID_KEY_ID is useless, that noone knows what to really use it for? Is it used much? Can its semantics be changed? Nico -- From owner-ipsec@lists.tislabs.com Wed Mar 24 01:25: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 i2O9Pj2g023991; Wed, 24 Mar 2004 01:25:47 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA17707 Wed, 24 Mar 2004 03:45:25 -0500 (EST) Date: Wed, 24 Mar 2004 02:57:01 -0600 From: Nicolas Williams To: Paul Hoffman / VPNC Cc: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: Remaining open issues for RFC-2401bis Message-ID: <20040324085701.GI5868@binky.central.sun.com> Mail-Followup-To: Paul Hoffman / VPNC , Stephen Kent , ipsec@lists.tislabs.com References: <200403200415.i2K4FlQU007773@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Mar 23, 2004 at 08:10:09AM -0800, Paul Hoffman / VPNC wrote: > At 9:35 PM -0500 3/22/04, Stephen Kent wrote: > >Since all ID's sent via IKE are used for access control, it seems > >reasonable to assume that, in general, people have interacted with a > >management interface to enter these IDs. > > Fully agree. > > > So, unless there is a need to transmit an arbitrary octet string > >for ID purposes, it would be more appropriate to constrain this to > >something that a user has a good chance of getting right. > > Also fully agree. Note that SSH users manage to used public keys for authorization even though the bits in those keys are almost meaningless to them. My point is that users can handle items that look like gibberish. Oh, I know, it ain't pretty, and we'd all rather use names when interacting with access control management interfaces, but that does not mean that access control with opaque IDs can't be done. > >The IKE v2 specs says (page 55) > > > > "An opaque octet stream which may be used to pass an account > > name or to pass vendor-specific information necessary to do > > certain proprietary types of identification." > > > >This hardly sounds like an arbitrary byte string. > > Fully disagree. "opaque octet stream" sounds exactly like "arbitrary > byte string" to me. Yes. Of course, presumably initiators can figure out what to use as ID_KEY_ID values, and presumbaly they can told what to use much the same way that access control by ID_KEY_ID can be managed. But it would be nice if there was a simple default content type for ID_KEY_ID, such as, say, the public key of the cert. This would bring the "power" (forgive me) of secure shell hostkeys/pubkey userauth to IPsec. [...] > > So, my suggestion is that we be a bit more restrictive with the > >supported name types. In that spirit, if we need to keep this as an > >arbitrary byte string, we ought to provide some rationale for that > >decision. > > Also fully agree. I'm happy if we change this field in IKEV to "UTF-8 > text string" (changing it to ASCII is not a reasonable option). > However, I'm not happy with leaving IKEv2 alone and having that > requirement (or, even worse, that assumption) come in 2401bis. If > IKEv2 is left as it is, 2401bit should not change the interpretation > of the field. Otherwise, boxes that follow 2401bis might fall over > when handed a non-UTF-8 octet stream. Agreed, except that I think ID_KEY_ID should stay an octet string. Nico -- From owner-ipsec@lists.tislabs.com Wed Mar 24 01:34: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 i2O9YCtb027048; Wed, 24 Mar 2004 01:34:12 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA19647 Wed, 24 Mar 2004 03:53:56 -0500 (EST) Date: Wed, 24 Mar 2004 03:04:57 -0600 From: Nicolas Williams To: Bill Sommerfeld Cc: Karen Seo , Mohan Parthasarathy , ipsec@lists.tislabs.com, "Theodore Ts'o" Subject: Re: Remaining open issues for RFC-2401bis Message-ID: <20040324090457.GJ5868@binky.central.sun.com> Mail-Followup-To: Bill Sommerfeld , Karen Seo , Mohan Parthasarathy , ipsec@lists.tislabs.com, Theodore Ts'o References: <200403200415.i2K4FlQU007773@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403200415.i2K4FlQU007773@thunk.east.sun.com> User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, Mar 19, 2004 at 11:15:47PM -0500, Bill Sommerfeld wrote: > > Well, if we allow this to be any octet string, > > then it presents complications for the user/management > > interface. So we'd like to limit it to a text string > > containing alphanumeric characters, but not a binary > > string, etc. > > current best practice for ietf protocols is that strings which are > intended for human display in protocols should come with language > tags. (why do I know? sshv2 bit this bullet a while ago...). see > rfc3066 Nit: UTF-8 has language tags also which can do when RFC3066 language tags are not available. But this is besides the point, my point that is, which I just made in separate posts, and which is that secure shell proves that access control by IDs that are fairly meaningless to users can be done and is done everyday, and by many. As to the I18N issues with the other ID types, well, shoving UTF-8 into ID_KEY_ID hardly seems like a way to address them (besides, saying "use UTF-8" is only the beginning, then come string prep profiles and all that other fun). Cheers, Nico -- From owner-ipsec@lists.tislabs.com Wed Mar 24 06:34: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 i2OEYZTB058517; Wed, 24 Mar 2004 06:34:36 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA22598 Wed, 24 Mar 2004 08:46:47 -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="utf-8" Subject: Re: Temporary version of the new IKEv2 draft Date: Wed, 24 Mar 2004 13:54:47 -0000 Message-ID: <579E83556A36E44EB2945CCE990B317401269D33@EUR-MSG-02.europe.corp.microsoft.com> Thread-Topic: Re: Temporary version of the new IKEv2 draft Thread-Index: AcQRp41w4SpoIvp3TDm/xaz1Se3IGA== From: "Michael Roe" To: X-OriginalArrivalTime: 24 Mar 2004 13:54:49.0562 (UTC) FILETIME=[92EFDBA0:01C411A7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id IAA22589 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk draft-ietf-ipsec-ikev2-13.txt says: > o Start Port (2 octets) - Value specifying the smallest port > number allowed by this Traffic Selector. For protocols for > which port is undefined, or if all ports are allowed or > port is OPAQUE, this field MUST be zero. The phrase "or port is OPAQUE" is dangerously ambiguous here. What I *think* this text means is that the "ANY" selector is encoded as [0, 65535], and that the "ANY" selector will match a non-initial fragment ("OPAQUE" port number). However, as well as OPAQUE port numbers, we also have the "OPAQUE" selector, which matches non-initial fragments. There's a question of how IKE represents the "OPAQUE" selector - how do you negotiate a fragment-only SA. Someone might read this text as saying that to negotiate a fragment-only SA (an SA whose selector is "port=OPAQUE") you set start_port=0 and end_port=65535. But that won't work, because there's no way to distinguish between "ANY" and "OPAQUE" if they are both encoded as [0, 65535]. I thought that Charlie Lynn's proposal was to represent an "OPAQUE" selector as [65535, 0], to distinguish it from the "ANY" selector [0, 65535]. See http://www.vpnc.org/ietf-ipsec/mail-archive/msg02701.html: > Please add text saying that OPAQUE is encoded by setting a "start" > field to the maximum value and the "end" field to the minimum value. Note that "start" is the *maximum* value and "end" is the *minimum* value... Mike From owner-ipsec@lists.tislabs.com Wed Mar 24 07:08:02 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OF81Ks061786; Wed, 24 Mar 2004 07:08:01 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29446 Wed, 24 Mar 2004 09:29:37 -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, 24 Mar 2004 14:41:43 -0000 Message-ID: <579E83556A36E44EB2945CCE990B317401269D81@EUR-MSG-02.europe.corp.microsoft.com> Thread-Topic: Final editing changes to IKEv2 Thread-Index: AcQQKR/3NfYD8IUWSgmdmQGGmKyGqABfo/ig From: "Michael Roe" To: "Theodore Ts'o" Cc: X-OriginalArrivalTime: 24 Mar 2004 14:41:44.0002 (UTC) FILETIME=[20795220:01C411AE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id JAA29433 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Theodore Ts'o > Sent: 17 March 2004 23:59 > To: Michael Roe > Cc: ipsec@lists.tislabs.com > Subject: Re: Final editing changes to IKEv2 > > 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 I was referring to a different part of Charlie Lynn's message. I was talking about bidirectional SA's that protect some MIPv6 messages and not others, not unidirectional SA's. Suppose that you want to have a SA that only protects the Home Test message (MH type = 3). Charlie Lynn's suggestion was that it would be negotiated with the following traffic selector: protocol = 135 start port = 0x300 end port = 0x300 (He said: "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)". Another obvious possibility would have been: protocol = 135 start port = 3 end port = 3 If we don't specify which of these it is, there could be some nasty interop problems. However, I'm not going to be too upset if this doesn't make it into the IKEv2 RFC. I suspect we're going to need a separate RFC to explain how MIPv6 uses IKEv2 --- just as we have draft-ietf-mobileip-mipv6-ha-ipsec-06.txt to explain how MIPv6 uses IKEv1 --- so it can always go in there. There's a general problem here: whenever someone assigns a new value of the protocol field in the IP header, there needs to be a document explaining what the IKEv2 "start port" and "end port" mean for the new protocol. It's clearly undesirable to revise the IKE specification every time this happens, so a separate document explaining the encoding is OK. Mike From owner-ipsec@lists.tislabs.com Wed Mar 24 07:14:19 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OFEJFK062295; Wed, 24 Mar 2004 07:14:19 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00358 Wed, 24 Mar 2004 09:36:17 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: Remaining open issues for RFC-2401bis In-reply-to: Your message of "Tue, 23 Mar 2004 15:27:34 PST." X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Wed, 24 Mar 2004 09:46:48 -0500 Message-ID: <21323.1080139608@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "VPNC" == VPNC writes: VPNC> No, we don't. We have ways of encoding the display name and VPNC> the coments, but *not* the address itself (called the VPNC> "addr-spec"). RFC 822 and 2822 are completely clear on this. Ah, good point. >> 2) we could agree to permit UTF-8 in RFC822_ADDR. VPNC> Doing so and hoping that the Applications Area Directors don't VPNC> barf is like Fine. Point made. So, we need an identifier that can carry UTF-8, is known to carry UTF-8, and isn't ID_KEY_ID. - -- ] 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 iQCVAwUBQGGfVYqHRg3pndX9AQFS0gP/REqyJFEuHwEdd84mjKL7eVu8OZ94VcB3 QXNT18Tvzt/nGAoxqUbXv6IK11TMTbqC0uqR/kKm/Opuxa4OUNSKmvMUuiujufEe fSPZ8LuBzoZe/xX+v6LUQsb4jky7oTxy2jFX6lg6qpc542ZpXrlZsEMYzPJFN/iA KPtMeVAsWX0= =7eGq -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Mar 24 07:20:03 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OFK3AY063293; Wed, 24 Mar 2004 07:20:03 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00590 Wed, 24 Mar 2004 09:38:34 -0500 (EST) To: Paul Hoffman / VPNC cc: ipsec@lists.tislabs.com Subject: Re: Remaining open issues for RFC-2401bis In-Reply-To: Message from Paul Hoffman / VPNC of "Tue, 23 Mar 2004 15:27:34 PST." References: <13871.1080078761@marajade.sandelman.ottawa.on.ca> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Wed, 24 Mar 2004 09:47:58 -0500 Message-ID: <21503.1080139678@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Oh, re: UTF-8 identifier. perhaps those that care could write a draft explaining their requirement, and perhaps they could be first user of the IANA IKEv2 registry. - -- ] 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 iQCVAwUBQGGfnIqHRg3pndX9AQFCygQAxKLXD0sDdvKPN+voTnq1ys7FFNAgZqLh q/QIaFeoLcvvdjdaW+jo/qPl3M/1XH7i53+kRYTAHp+2WpYYwZZaKL2hs3eawER1 2Od+f1vYxiTbVM6nUk1869DOT3q58trr+g4Um0t7NjD4LNP9ILIgUskTZzNQ+EJE h9OVqKoL4c0= =Zgfy -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Mar 24 09:28:22 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OHSLYd073317; Wed, 24 Mar 2004 09:28:21 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20966 Wed, 24 Mar 2004 11:37:55 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: EAP Roundtrips (was: Temporary version of the new IKEv2 draft) Date: Wed, 24 Mar 2004 17:41:54 +0200 To: ipsec@lists.tislabs.com, Paul Hoffman / VPNC X-Mailer: Apple Mail (2.613) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Again, regarding section 2.16, I believe it should say, that the Initiator MAY send the AUTH payload before the EAP-success message, in which case the Responder SHOULD send the AUTH, SAr2, TSi, TSr along with the EAP-success. In this case, the initial SA establishment will be shortened to 6 messages. On Mar 24, 2004, at 1:39 AM, Paul Hoffman / VPNC wrote: > Greetings again. At Charlie's request, I have just posted a temporary > version of the new IKEv2 draft at > . > This version will disappear when the official draft is posted to the > Internet Drafts web site and the announcement appears on this mailing > list. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Wed Mar 24 09:57:10 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OHv8YB074921; Wed, 24 Mar 2004 09:57:09 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA26679 Wed, 24 Mar 2004 12:11:03 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16480.32863.476549.187521@fireball.acr.fi> References: <200403200415.i2K4FlQU007773@thunk.east.sun.com> <16480.9936.57483.798886@fireball.acr.fi> <16480.32863.476549.187521@fireball.acr.fi> Date: Wed, 24 Mar 2004 09:53:25 -0500 To: Tero Kivinen From: Stephen Kent Subject: Re: Remaining open issues for RFC-2401bis Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA26675 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:22 PM +0200 3/23/04, Tero Kivinen wrote: >Stephen Kent writes: >> so, the problem we have is that the same ID type >> is defined to have two different uses: an account >> name, for which an IA5 or UTF-8 string would be > >There is no text in the IKEv1 defining it to be account name. IKEv1 >defined it to be "an opaque byte stream which may be used to pass >vendor-specific information necessary to identify which pre- shared >key should be used to authenticate Aggressive mode negotiations." > >This account name thing was added in the IKEv2, and I do not know why >it was added. neither do I. I did not go back to IKEv1 to see how the ID type was defined there, since the focus of 2401bis is IKEv2, but your point is well taken. If the WG is comfortable changing the dscriptipn back to what it was in IKEv1, then I agree that this is an arbitrary, potentially binary value, and my suggestion re human readable, character string encoding would not be relevant. > > appropriate, or an arbitrary byte sting, for >> which no further encoding is appropriate. I would >> be happy if we choose ONE of these two, but >> having both listed is a recipe for >> non-interoperability. > >Do we really need account name? Why cannot be use rfc822 address? >How about using the ID_KEY_ID to send the uid of the unix machine >(i.e. the numeric user id, as 16/32 bit number (2/4 octects)). If the goal is to match account names precisely, then 822 addresses are not an ideal choice. I also would not suggest the Unix UID, since that is clearly an OS-specific approach. The goal in access control systems is to provide admins with name forms that mimic the ones that they are otherwise accustomed to dealing with. That's why a user login ID or account name is preferable in many cases. > > As for using a random number as an ID, note that this may not play >> well with the PAD description that we published. > >Why not, after the new ID has been exchanged, both the server and >client, will simply reconfigure the PAD to include the new ID. We had no plans to describe the PAD as a database that was dynamically reconfigured, but we also did not plan to say anything that would prohibit this. > > I agree that IF the intent is to send an >> arbitrary byte string for a vendor-specific >> purpose, then UTF-8 encoding is inappropriate. >> However, if the intent is to send a user account >> name, then such encoding is appropriate. That's >> why I suggest that we disentangle these two >> different uses for the field. > >We already have rfc822 address for user account name, why would we >need separate account name id? The ID_KEY_ID is also defined to be >something that is NOT matched against anything in the certificates >etc, it is only matched against the built in policy (i.e. mostly >usefull in shared-key authentication). In those case the >bit-comparison is much better. As noted above, 822 addresses may be OK, but they are not ideal as a way to mimic a login ID. > > >On the other hand the client and server will have common security >> >domain, which also defines the usernames, and the encoding used for >> >them, thus it does not cause any problems to encode the Latin-1 >> >username string as binary latin-1 octect stream when sent inside the >> >IKE ID_KEY_ID. >> >> I disagree. There is no reason to believe that >> there will be an appropriate management interface >> to allow for easy entry of a UTF-8 account name >> by a user or admin if the only requirement is to >> support binary values for this field. > >Why should there interface to allow UTF-8 account names, if the only >thing the adminstrator is going to use it, is to account names in the >policy specified format. I can't parse the above sentence. >If my account name is Törvelä, I will encode it in the same way >in my client and in my server, as they are most likely adminstrated by >the same persons. If the adminstrator cannot enter my account name, he >will propably say, that your new account name for the VPN use will be >"Torvela". The client and server may be produced by different vendors, and if only one provides a management interface for UTF-8 ID input, then there is a possibility that it will not be easy to get the two to match. For example, in 802.11 nets, I have had problems getting the passwords that are used as keys to match on routers/access points and my Apple computers, precisely because the management interfaces were not built to any standard. > > same argument as above, For interoperability we >> want to ensure that any ID form that either end >> may use will be easy to enter and manage by >> everyone. Unless we have some good reason to >> believe that EDI Part names, and X.400 addresses >> are appropriate ID forms for IPsec, then we >> ought not provide a means to carry them, since >> such carriage should be matched by a requirement >> for a management interface for them in every >> IPsec implementation. > >If I undertand correctly, the general name is there, because it can be >matched against the certificate, and in some cases people might have >setup where they allow you to login if you just happen to have valid >certificate from that certain CA, and you can use any ID that can be >found from the certificate as your ID. The pki4ipsec wg is working on >that issue. The pki4ipsec WG document that deals with this also excludes GN, just as 2401bis has in its current draft. Requiring support for GN duplicates what we already mandate when we require support for DNs, 822 addresses, and IP addresses, plus it adds a requirement to support names forms like EDI party name and X.400 addresses. Unless we believe it is appropriate to support these additional name forms, not to mention to "free form" name types that are part of GN, it is a bad idea to call for GN support. >This issue does not cover ID_KEY_ID, as it will not be in the >certificates. If we say that ID_KEY_ID is octect string, and >adminstrators must allow support for any binary string there, then we >can put configure the system to use ISO 10646 UTF-8 account names, >uid, Latin-1 account or plain ASCII account names. If the >implementator is stupid and does not include easy way to enter the ISO >10646 UTF-8 account names, it does not still affect the >interoperability, it just makes the configuration harder. my experience with 801.11 passwords says otherwise, i.e., it was not possible to configure the access point and my computers to interoperate because of the management interface discrepancies. > >> Flexibility is not free if we want >> interoperability at the same time. If we make >> provision for carriage of arbitrary strings as >> IDs in IKEv2 mandatory, then we have a >> responsibility to ensure that IPsec >> implementations have a means to make use of them >> when the arrive. Otherwise we create >> opportunities for non-interopeability. > >If we say it is opaque octect string, and implementationtions MUST >support any binary data up to 32 bytes in it, it defines exactly an >interoperable use for the ID_KEY_ID. Agreed. But, then we should not expect this ID type to be used to login/account IDs, since there is a chance that it will be infeasible for many folks to configure such ID types using only a binary representation. Steve From owner-ipsec@lists.tislabs.com Wed Mar 24 10:58: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 i2OIwtvH080030; Wed, 24 Mar 2004 10:58:55 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05793 Wed, 24 Mar 2004 13:10:58 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: EAP Roundtrips (was: Temporary version of the new IKEv2 draft) Date: Wed, 24 Mar 2004 10:23:23 -0800 Message-ID: Thread-Topic: EAP Roundtrips (was: Temporary version of the new IKEv2 draft) Thread-Index: AcQRwdCxwgtlGfRqSyqPJFvRKl81ewAB6fWg From: "Charlie Kaufman" To: "Yoav Nir" , , "Paul Hoffman / VPNC" X-OriginalArrivalTime: 24 Mar 2004 18:23:05.0025 (UTC) FILETIME=[0C949B10:01C411CD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA05784 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I made the revisions to IKEv2-13 over the weekend without having seen the discussion of EAP roundtrips on the mailing list Friday. The change reflects the instructions I got from Ted on 3/16. I am happy to change it again if that is the working group consensus, but I'll mention the argument on the other side. While minimizing round trips has been a priority in designing IKEv2, minimizing protocol variations has also been a priority. By allowing the initiator to put the AUTH payload in either of two messages, the responder is required to accept it in either message. While this does not substantially complicate an implementation based on a state machine, it does complicate testing in that both protocol variants would have to be tested. It was this sort of argument that prevented us from having an "optional" additional exchange for EAP to prompt for identity (which arguably offers security advantages in some scenarios). So if we're going to do this, I want Ted and Barbara to officially declare consensus. And I guess that means if there are objections, people should express them now. If that looks like the direction, I'll post proposed language to the list before doing another revision. And I hope this can all go on in parallel with IETF last call. --Charlie -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Yoav Nir Sent: Wednesday, March 24, 2004 7:42 AM To: ipsec@lists.tislabs.com; Paul Hoffman / VPNC Subject: EAP Roundtrips (was: Temporary version of the new IKEv2 draft) Again, regarding section 2.16, I believe it should say, that the Initiator MAY send the AUTH payload before the EAP-success message, in which case the Responder SHOULD send the AUTH, SAr2, TSi, TSr along with the EAP-success. In this case, the initial SA establishment will be shortened to 6 messages. From owner-ipsec@lists.tislabs.com Wed Mar 24 12:04:23 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 i2OK4Mop085254; Wed, 24 Mar 2004 12:04:23 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16764 Wed, 24 Mar 2004 14:23:07 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16480.15529.482315.278735@fireball.acr.fi> References: <16480.15529.482315.278735@fireball.acr.fi> Date: Wed, 24 Mar 2004 14:33:50 -0500 To: Tero Kivinen From: Stephen Kent Subject: Re: 2nd try Cc: ipsec@lists.tislabs.com, russ housley Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero, > >Note, that IKEv1 does not have way to negotiate OPAQUE, it only offers >port number - 0 => Port field should be ignored == ANY+OPAQUE. Yes, there was a disconnect between IKEv1 and what 2401 said, and the goal here is to fix that with 2401bis and IKEv2. >And as IKEv1 didn't offer any support for OPAQUE, there cannot really >be implementations using that method with IKEv1 (i.e. IKEv1 cannot >negotiate such SA for OPAQUE traffic). Agreed, But 2401bis assumes use of IKEv2 in several instances, so I don't see this as a problem. >If you have SA with port selectors between SGWs you cannot allow clear >text non-first fragments without (partial) reassembly between SGWs. > >I.e. if you have rules > > A <-> B port 25 ESP with auth > A <-> B non-first fragments in clear (i.e. bypass) > >Then attacker who sees or (or forces) the A to send fragmented packet >can modify the non-first fragments regardless whether the SGW1 >encrypted all the fragments of the packet from A, and the SGW2 will >accept them based on the second policy rule. . I agree that the second rule would be a bad config choice. But I disagree with the conclusion that one must do some form of reassembly if fragments are allowed to bypass. We ought not impose this requirement just to counter the bad effects of a bad config choice. > > Conclusions >... >> 1. All implementations MUST support tunnel mode SAs that pass traffic >> without regard to port field values. If the SA will carry traffic for >> specified protocols, the two selector sets MUST be used to specify >> the port fields for the SA: ANY and OPAQUE. An SA defined in this >> fashion will carry all traffic for the indicated source/destination >> addresses and specified protocol(s). If the SA will carry traffic >> without regard to a specific protocol value (i.e., ANY is specified), >> then the port field values MUST be set to ANY as well. > >Is this for traffic where the SGWs ignore the port field completely? yes. >Is this negotiated with IKEv2 by setting the port field range to >0-65535 (==ANY). ANY and OPAQUE must both be specified to accommodate all possible traffic types (whole packets, as well as all fragments). > > 2. All implementations MUST support tunnel mode SAs that will carry >> only non-initial fragments, separate from non-fragmented packets and >> initial fragments. The OPAQUE value will be used to specify port >> field selectors for an SA to carry non-initial fragments. Specific >> port selector values will be used to define SAs to carry initial >> fragments and non-fragmented packets. This approach can be used if a > >If this is added, I think negotiating it in the IKE using the protocol >44 (issue #81), is much cleaner way than the special port values. On >the other hand that does not allow negotiation of the only TCP >fragments. Perhaps the special port range is then better, i.e. in IKE >v2 use port range of 65535-0 (= non-first fragment). I'm flexible on what the encoding should be for OPAQUE in IKEv2. > > user or administrator wants to create one or more tunnel mode SAs >> between the same source/destination addresses that discriminate based >> on port fields. These SAs MUST have non-trivial protocol selector >> values, otherwise approach #1 above can be used. Receivers MUST >> perform a minimum offset check on IPv4 (non-initial) fragments to >> protect against overlapping fragment attacks when SAs of this type >> are employed. Because such checks cannot be performed on IPv6 >> non-initial fragments, users and administrators are advised that >> carriage of such fragments may be dangerous, and implementers may >> choose to NOT support such SAs for IPv6 traffic. Also, because a SA > >The beginning says this is MUST, and here you say implementators can >choose not to support it. I think it shoud say it is MUST for IPv4 and >MAY/SHOULD for IPv6 I intended to convey the notion that it is a MUST for v4, but not for v6, for the reason cited. I'm comfortable with a MAY for v6. > >> of this sort will carry ALL non-initial fragments that match a >> specified source/destination address pair and protocol value, users >> and administrators are advised to protect such traffic using ESP >> (with integrity) and the "strongest" integrity and encryption >> algorithms available at both peers. (Determination of the "strongest" >> algorithms requires imposing a total ordering of the available >> algorithms, a local determination at the discretion of the initiator > > of the SA.) >> >> 3. An implementation MAY choose to support some form of stateful >> fragment checking for a tunnel mode SA with non-trivial port field >> values (not ANY or OPAQUE). Implementations that will transmit >> non-initial fragments on a tunnel mode SA that makes use of >> non-trivial port selectors MUST notify a peer via an IKE payload >> (TBD). > >Why? If the other end only supports the case #2, then it only needs to >check that the SA which is used to carry the traffic has enough >security to take care of the non-initial fragments. I.e. if the >senders policy is use ESP AES for port 25, and the responders is use >ESP AES for port 25, and any ESP stronger than 80-bits for non-inigial >fragments, then it can safely accept the non-initial packets coming >from the SA negotiated for the port 25. Since it appears that nothing short of reassembly will be safe for v6, I think it is important to add this case. Also, you and some other folks have indicted that this approach seems reasonable for many contexts, where very high speed processing it not an issue. So, my reason for including #3 above is to allow folks who want to do reassembly to do it, but not to impose it as a burden for folks who don't feel that this strategy is compatible with their system requirements/architecture. Steve From owner-ipsec@lists.tislabs.com Wed Mar 24 12:04: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 i2OK4VUX085273; Wed, 24 Mar 2004 12:04:31 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15845 Wed, 24 Mar 2004 14:18:48 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <16481.57832.728941.484266@gargle.gargle.HOWL> Date: Wed, 24 Mar 2004 14:30:48 -0500 From: Paul Koning To: kent@bbn.com Cc: kivinen@iki.fi, ipsec@lists.tislabs.com Subject: Re: Remaining open issues for RFC-2401bis References: <200403200415.i2K4FlQU007773@thunk.east.sun.com> <16480.9936.57483.798886@fireball.acr.fi> <16480.32863.476549.187521@fireball.acr.fi> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id OAA15822 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Stephen" == Stephen Kent writes: Stephen> At 8:22 PM +0200 3/23/04, Tero Kivinen wrote: >> If my account name is Törvelä, I will encode it in the same way in >> my client and in my server, as they are most likely adminstrated >> by the same persons. If the adminstrator cannot enter my account >> name, he will propably say, that your new account name for the VPN >> use will be "Torvela". Stephen> The client and server may be produced by different vendors, Stephen> and if only one provides a management interface for UTF-8 ID Stephen> input, then there is a possibility that it will not be easy Stephen> to get the two to match. Actually, that's true even if both sides know UTF-8, since there are multiple encodings for many cases. There are 6 encodings, I think, for the sting Tero gave. This is what RFC 3454 is all about. If you really want this thing to be a human-meaningful string, you need to say it's UTF-8 AND you have to specify what stringprep profile applies to it. paul From owner-ipsec@lists.tislabs.com Wed Mar 24 12:08:16 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OK8GwG085495; Wed, 24 Mar 2004 12:08:16 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18111 Wed, 24 Mar 2004 14:30:53 -0500 (EST) Message-ID: <00af01c411d6$d4716010$6501a8c0@adithya> From: "Mohan Parthasarathy" To: "Tero Kivinen" , "Stephen Kent" Cc: "Paul Hoffman / VPNC" , References: <200403200415.i2K4FlQU007773@thunk.east.sun.com><16480.9936.57483.798886@fireball.acr.fi> <16480.32863.476549.187521@fireball.acr.fi> Subject: Re: Remaining open issues for RFC-2401bis Date: Wed, 24 Mar 2004 11:33:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 > Stephen Kent writes: > > so, the problem we have is that the same ID type > > is defined to have two different uses: an account > > name, for which an IA5 or UTF-8 string would be > > There is no text in the IKEv1 defining it to be account name. IKEv1 > defined it to be "an opaque byte stream which may be used to pass > vendor-specific information necessary to identify which pre- shared > key should be used to authenticate Aggressive mode negotiations." > This was the main reason why i raised the issue i.e ID_KEY_ID is used to select pre-shared key and it was defined to be a opaque octet stream in IKEv1. This in conjunction with a road warrior case where the addresses are not known a priori, you need to use the information in ID_KEY_ID as selector. Please see draft-ietf-pana-ipsec-02.txt as an example of how this ID_KEY_ID is used to carry a session-ID - which is an opaque octet stream or possibly an UTF8 string carried in an opaque way. > This account name thing was added in the IKEv2, and I do not know why > it was added. > > > appropriate, or an arbitrary byte sting, for > > which no further encoding is appropriate. I would > > be happy if we choose ONE of these two, but > > having both listed is a recipe for > > non-interoperability. > > Do we really need account name? Why cannot be use rfc822 address? > How about using the ID_KEY_ID to send the uid of the unix machine > (i.e. the numeric user id, as 16/32 bit number (2/4 octects)). > > > As for using a random number as an ID, note that this may not play > > well with the PAD description that we published. > > Why not, after the new ID has been exchanged, both the server and > client, will simply reconfigure the PAD to include the new ID. > Yes, i don't see why this is in conflict with the PAD description in 2401bis. -mohan > > I agree that IF the intent is to send an > > arbitrary byte string for a vendor-specific > > purpose, then UTF-8 encoding is inappropriate. > > However, if the intent is to send a user account > > name, then such encoding is appropriate. That's > > why I suggest that we disentangle these two > > different uses for the field. > > We already have rfc822 address for user account name, why would we > need separate account name id? The ID_KEY_ID is also defined to be > something that is NOT matched against anything in the certificates > etc, it is only matched against the built in policy (i.e. mostly > usefull in shared-key authentication). In those case the > bit-comparison is much better. > > > >On the other hand the client and server will have common security > > >domain, which also defines the usernames, and the encoding used for > > >them, thus it does not cause any problems to encode the Latin-1 > > >username string as binary latin-1 octect stream when sent inside the > > >IKE ID_KEY_ID. > > > > I disagree. There is no reason to believe that > > there will be an appropriate management interface > > to allow for easy entry of a UTF-8 account name > > by a user or admin if the only requirement is to > > support binary values for this field. > > Why should there interface to allow UTF-8 account names, if the only > thing the adminstrator is going to use it, is to account names in the > policy specified format. > > If my account name is Törvelä, I will encode it in the same way > in my client and in my server, as they are most likely adminstrated by > the same persons. If the adminstrator cannot enter my account name, he > will propably say, that your new account name for the VPN use will be > "Torvela". > > > same argument as above, For interoperability we > > want to ensure that any ID form that either end > > may use will be easy to enter and manage by > > everyone. Unless we have some good reason to > > believe that EDI Part names, and X.400 addresses > > are appropriate ID forms for IPsec, then we > > ought not provide a means to carry them, since > > such carriage should be matched by a requirement > > for a management interface for them in every > > IPsec implementation. > > If I undertand correctly, the general name is there, because it can be > matched against the certificate, and in some cases people might have > setup where they allow you to login if you just happen to have valid > certificate from that certain CA, and you can use any ID that can be > found from the certificate as your ID. The pki4ipsec wg is working on > that issue. > > This issue does not cover ID_KEY_ID, as it will not be in the > certificates. If we say that ID_KEY_ID is octect string, and > adminstrators must allow support for any binary string there, then we > can put configure the system to use ISO 10646 UTF-8 account names, > uid, Latin-1 account or plain ASCII account names. If the > implementator is stupid and does not include easy way to enter the ISO > 10646 UTF-8 account names, it does not still affect the > interoperability, it just makes the configuration harder. > > > Flexibility is not free if we want > > interoperability at the same time. If we make > > provision for carriage of arbitrary strings as > > IDs in IKEv2 mandatory, then we have a > > responsibility to ensure that IPsec > > implementations have a means to make use of them > > when the arrive. Otherwise we create > > opportunities for non-interopeability. > > If we say it is opaque octect string, and implementationtions MUST > support any binary data up to 32 bytes in it, it defines exactly an > interoperable use for the ID_KEY_ID. > -- > kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Wed Mar 24 12:09:21 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OK9K4Z085555; Wed, 24 Mar 2004 12:09:20 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18270 Wed, 24 Mar 2004 14:31:49 -0500 (EST) Message-ID: <00b501c411d7$4290e750$6501a8c0@adithya> From: "Mohan Parthasarathy" To: , "Michael Richardson" References: <21323.1080139608@marajade.sandelman.ottawa.on.ca> Subject: Re: Remaining open issues for RFC-2401bis Date: Wed, 24 Mar 2004 11:36:09 -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 > > > >>>>> "VPNC" == VPNC writes: > VPNC> No, we don't. We have ways of encoding the display name and > VPNC> the coments, but *not* the address itself (called the > VPNC> "addr-spec"). RFC 822 and 2822 are completely clear on this. > > Ah, good point. > > >> 2) we could agree to permit UTF-8 in RFC822_ADDR. > > VPNC> Doing so and hoping that the Applications Area Directors don't > VPNC> barf is like > > Fine. Point made. > So, we need an identifier that can carry UTF-8, is known to carry > UTF-8, and isn't ID_KEY_ID. > I hope this does not preclude ID_KEY_ID from carrying UTF-8 in an opaque way. I think this is what Paul Koning mentioned in an earlier mail. thanks mohan > - -- > ] 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 > > iQCVAwUBQGGfVYqHRg3pndX9AQFS0gP/REqyJFEuHwEdd84mjKL7eVu8OZ94VcB3 > QXNT18Tvzt/nGAoxqUbXv6IK11TMTbqC0uqR/kKm/Opuxa4OUNSKmvMUuiujufEe > fSPZ8LuBzoZe/xX+v6LUQsb4jky7oTxy2jFX6lg6qpc542ZpXrlZsEMYzPJFN/iA > KPtMeVAsWX0= > =7eGq > -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Mar 24 12:49:55 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OKnsxj088718; Wed, 24 Mar 2004 12:49:54 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA24879 Wed, 24 Mar 2004 15:09:11 -0500 (EST) Message-ID: <4061ED3E.1060901@kolumbus.fi> Date: Wed, 24 Mar 2004 22:19:10 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charlie Kaufman Cc: ipsec@lists.tislabs.com Subject: Re: EAP Roundtrips (was: Temporary version of the new IKEv2 draft) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie Kaufman wrote: > So if we're going to do this, I want Ted and Barbara to officially > declare consensus. And I guess that means if there are objections, > people should express them now. If that looks like the direction, I'll > post proposed language to the list before doing another revision. Sounds like a good plan. We are by the way still discussing the issue in the EAP WG list and off-list... We'd really like to reach a conclusion in the discussion before the IPsec WG decides what to do. In other words: there's an opinion on the matter, not expressed yet but coming soon so please wait for that ;-) --Jari From owner-ipsec@lists.tislabs.com Wed Mar 24 12:51:02 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OKp1xF088973; Wed, 24 Mar 2004 12:51:01 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26391 Wed, 24 Mar 2004 15:15:45 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Remaining open issues for RFC-2401bis Date: Wed, 24 Mar 2004 11:05:20 -0800 Message-ID: Thread-Topic: Remaining open issues for RFC-2401bis Thread-Index: AcQRxjyjq07EVYAMRHGKVx3E2dluxgACdWdg From: "Charlie Kaufman" To: "Stephen Kent" , "Tero Kivinen" Cc: X-OriginalArrivalTime: 24 Mar 2004 19:05:23.0713 (UTC) FILETIME=[F5C1A710:01C411D2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id PAA26380 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ---On Wednesday, March 24, 2004 6:53 AM, Steve Kent Wrote: > >>There is no text in the IKEv1 defining it to be account name. IKEv1 >>defined it to be "an opaque byte stream which may be used to pass >>vendor-specific information necessary to identify which pre- shared key >>should be used to authenticate Aggressive mode negotiations." >> >>This account name thing was added in the IKEv2, and I do not know why >>it was added. > >neither do I. I did not go back to IKEv1 to see how the ID type was defined >there, since the focus of 2401bis is IKEv2, but your point is well taken. >If the WG is comfortable changing the dscriptipn back to what it was in >IKEv1, then I agree that this is an arbitrary, potentially binary value, >and my suggestion re human readable, character string encoding would not be >relevant. I can answer the 'why' question, though I don't know whether this will help in the debate. When copying the text from IKEv1 describing this field, I was confused and asked 'what would people do with this field really'. The answer I got was that they would likely put an account name or some such there, so I added that text by way of a hint to the reader. It was not my intent to change the definition of the field. In my opinion, leaving it an opaque octet stream is the right thing to do. We could make the spec more clear by making it explicit that account name is only an example. We could make the spec more precise but less clear by going back to the IKEv1 wording. I didn't think anyone could be confused by the current wording, but I clearly underestimated the creativity of the audience. We could add yet another ID Type option for UTF-8 string, but does anyone actually have a use for it? Currently, the spec says that implementations MUST accept ID_KEY_ID types, but does not say what values MUST be configurable. One could interpret that as requiring an administrative interface that allows entry of arbitrary binary values. If so, and if people don't like that, I would propose removing the requirement that implementations MUST accept the type rather than trying to restrict how the field could be used. --Charlie From owner-ipsec@lists.tislabs.com Wed Mar 24 13:02:55 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OL2sTW089599; Wed, 24 Mar 2004 13:02:54 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27927 Wed, 24 Mar 2004 15:27:13 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <00af01c411d6$d4716010$6501a8c0@adithya> References: <200403200415.i2K4FlQU007773@thunk.east.sun.com><16480.9936.57483.79888 6@fireball.acr.fi> <16480.32863.476549.187521@fireball.acr.fi> <00af01c411d6$d4716010$6501a8c0@adithya> Date: Wed, 24 Mar 2004 14:58:23 -0500 To: "Mohan Parthasarathy" From: Stephen Kent Subject: Re: Remaining open issues for RFC-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 Mohan, > > Stephen Kent writes: >> > so, the problem we have is that the same ID type >> > is defined to have two different uses: an account >> > name, for which an IA5 or UTF-8 string would be >> >> There is no text in the IKEv1 defining it to be account name. IKEv1 >> defined it to be "an opaque byte stream which may be used to pass >> vendor-specific information necessary to identify which pre- shared >> key should be used to authenticate Aggressive mode negotiations." >> >This was the main reason why i raised the issue i.e ID_KEY_ID is used >to select pre-shared key and it was defined to be a opaque octet stream >in IKEv1. This in conjunction with a road warrior case where the addresses >are not known a priori, you need to use the information in ID_KEY_ID as >selector. Please see draft-ietf-pana-ipsec-02.txt as an example of how >this ID_KEY_ID is used to carry a session-ID - which is an opaque >octet stream or possibly an UTF8 string carried in an opaque way. Let me note, again, that 2401bis assumes IKEv2, in lots of places, so I don't think the use of this ID type in IKEv1 is central to this discussion. There have been lots of good arguments why one might choose to view this ID type a just a byte string, and why we might want to add another ID type for conveying login IDs, but references to IKEv1 are not among those good arguments :-) > > This account name thing was added in the IKEv2, and I do not know why >> it was added. >> >> > appropriate, or an arbitrary byte sting, for >> > which no further encoding is appropriate. I would >> > be happy if we choose ONE of these two, but > > > having both listed is a recipe for >> > non-interoperability. >> >> Do we really need account name? Why cannot be use rfc822 address? >> How about using the ID_KEY_ID to send the uid of the unix machine >> (i.e. the numeric user id, as 16/32 bit number (2/4 octects)). >> >> > As for using a random number as an ID, note that this may not play >> > well with the PAD description that we published. >> >> Why not, after the new ID has been exchanged, both the server and >> client, will simply reconfigure the PAD to include the new ID. >> > >Yes, i don't see why this is in conflict with the PAD description in 2401bis. I said this MAY be in conflict because there is not mention of PAD entries being dynamically changed as a side effect of an initial IKE exchange. And, as you may guess, I had not envisioned a context where that would be required. In 2401 we needed to consider dynamic SPD entries to accommodate road warriors. That is no longer the case, because of the SPD cache in the model, and because of the introduction of the PAD. I'm not claiming that there are no reasons to have dynamic PAD entries, but none occurred to us in writing 2401bis. Steve From owner-ipsec@lists.tislabs.com Wed Mar 24 13:03:10 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OL39os089623; Wed, 24 Mar 2004 13:03:10 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27734 Wed, 24 Mar 2004 15:26:24 -0500 (EST) Date: Wed, 24 Mar 2004 14:37:45 -0600 From: Nicolas Williams To: Charlie Kaufman Cc: Stephen Kent , Tero Kivinen , ipsec@lists.tislabs.com Subject: Re: Remaining open issues for RFC-2401bis Message-ID: <20040324203745.GX5868@binky.central.sun.com> Mail-Followup-To: Charlie Kaufman , Stephen Kent , Tero Kivinen , ipsec@lists.tislabs.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Mar 24, 2004 at 11:05:20AM -0800, Charlie Kaufman wrote: > We could add yet another ID Type option for UTF-8 string, but does > anyone actually have a use for it? When the rfc822 subjectAltName is internationalized then the corresponding ID should be also by extension (one hopes). If the matter is addressed by adding additional cert extensions or by adding to the general name CHOICE (why is it not marked extensible?) then we may need a new ID type to go with it. Nico -- From owner-ipsec@lists.tislabs.com Wed Mar 24 14:07: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 i2OM7TTp094985; Wed, 24 Mar 2004 14:07:29 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04956 Wed, 24 Mar 2004 16:20:04 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Temporary version of the new IKEv2 draft Date: Wed, 24 Mar 2004 13:21:12 -0800 Message-ID: Thread-Topic: Temporary version of the new IKEv2 draft Thread-Index: AcQRp41w4SpoIvp3TDm/xaz1Se3IGAAOswWA From: "Charlie Kaufman" To: "Michael Roe" , X-OriginalArrivalTime: 24 Mar 2004 21:21:17.0538 (UTC) FILETIME=[F1D09C20:01C411E5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id QAA04923 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----On Wednesday, March 24, 2004 5:55 AM, Michael Row wrote: >The phrase "or port is OPAQUE" is dangerously ambiguous here. >What I *think* this text means is that the "ANY" selector is encoded >as [0, 65535], and that the "ANY" selector will match a non-initial >fragment ("OPAQUE" port number). I was trying to do something minimal but helpful, and may have disturbed a hornet's nest. My instructions were to clarify the encoding of icmp type/code but with a pointer to a message from Charlie Lynn that proposed several changes including clarifications to handling of OPAQUE. There has been much debate on this list as to how OPAQUE should be handled in 2401bis. I have been hoping that debate would conclude with something that did not require changes to IKEv2. The specification of traffic selectors in IKEv2 is already imperfect. There is a provision, for example, to open parallel SAs with identical traffic selectors for the purpose of dividing streams with different QOS processing but there is no way to specify how they are divided in the traffic selectors (or in 2401bis as far as I know). However the OPAQUE debate gets resolved in the specs, I believe most implementations will ignore the issue because they will not filter on ports. I wanted to make it clear that specifying start and end ports of [0, 65535] means ALL (any port number) and OPAQUE (port number unknown). I believe that was a reasonable interpretation of the old language, but wanted to make it explicit. How implementations handle fragments in the case where they are filtering on ports (or worse, are sending different ports' traffic over different SAs) is a corner case that has to be decided or there will be interoperability problems in that corner case. But I don't think it's reasonable for us to design mechanisms for implementations to negotiate how those cases are handled using IKEv2. Either design a mechanism everyone can live with or fight it out in interoperability testing. I'd be happy to take out the phrase "or port is OPAQUE" if people think it's confusing. Just so long as everyone understands and agrees that [0, 65535] means ALL packets and fragments regardless of port. --Charlie -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Michael Roe Sent: Wednesday, March 24, 2004 5:55 AM To: ipsec@lists.tislabs.com Subject: Re: Temporary version of the new IKEv2 draft draft-ietf-ipsec-ikev2-13.txt says: > o Start Port (2 octets) - Value specifying the smallest port > number allowed by this Traffic Selector. For protocols for > which port is undefined, or if all ports are allowed or > port is OPAQUE, this field MUST be zero. The phrase "or port is OPAQUE" is dangerously ambiguous here. What I *think* this text means is that the "ANY" selector is encoded as [0, 65535], and that the "ANY" selector will match a non-initial fragment ("OPAQUE" port number). However, as well as OPAQUE port numbers, we also have the "OPAQUE" selector, which matches non-initial fragments. There's a question of how IKE represents the "OPAQUE" selector - how do you negotiate a fragment-only SA. Someone might read this text as saying that to negotiate a fragment-only SA (an SA whose selector is "port=OPAQUE") you set start_port=0 and end_port=65535. But that won't work, because there's no way to distinguish between "ANY" and "OPAQUE" if they are both encoded as [0, 65535]. I thought that Charlie Lynn's proposal was to represent an "OPAQUE" selector as [65535, 0], to distinguish it from the "ANY" selector [0, 65535]. See http://www.vpnc.org/ietf-ipsec/mail-archive/msg02701.html: > Please add text saying that OPAQUE is encoded by setting a "start" > field to the maximum value and the "end" field to the minimum value. Note that "start" is the *maximum* value and "end" is the *minimum* value... Mike From owner-ipsec@lists.tislabs.com Wed Mar 24 14:57:07 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OMv6II097644; Wed, 24 Mar 2004 14:57:06 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11913 Wed, 24 Mar 2004 17:16:39 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <00b501c411d7$4290e750$6501a8c0@adithya> References: <21323.1080139608@marajade.sandelman.ottawa.on.ca> <00b501c411d7$4290e750$6501a8c0@adithya> Date: Wed, 24 Mar 2004 15:00:34 -0500 To: "Mohan Parthasarathy" From: Stephen Kent Subject: Re: Remaining open issues for RFC-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 11:36 AM -0800 3/24/04, Mohan Parthasarathy wrote: > > >> >> >>>>> "VPNC" == VPNC writes: >> VPNC> No, we don't. We have ways of encoding the display name and >> VPNC> the coments, but *not* the address itself (called the >> VPNC> "addr-spec"). RFC 822 and 2822 are completely clear on this. >> >> Ah, good point. >> >> >> 2) we could agree to permit UTF-8 in RFC822_ADDR. >> >> VPNC> Doing so and hoping that the Applications Area Directors don't >> VPNC> barf is like >> >> Fine. Point made. >> So, we need an identifier that can carry UTF-8, is known to carry >> UTF-8, and isn't ID_KEY_ID. >> >I hope this does not preclude ID_KEY_ID from carrying UTF-8 in an >opaque way. I think this is what Paul Koning mentioned in an earlier mail. > For the reasons cited earlier, I think it is a bad idea to carry structured data like UTF-8 in what is described as an opaque octet string. there is no reason to assume that there will be management interfaces to facilitate entry of the data in a compatible fashion, even without the encoding options that Paul has pointed out. Steve From owner-ipsec@lists.tislabs.com Wed Mar 24 15:06:30 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 i2ON6TZN098567; Wed, 24 Mar 2004 15:06:29 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14635 Wed, 24 Mar 2004 17:29:37 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: responding to unknown SPIs Date: Wed, 24 Mar 2004 13:36:13 -0800 Message-ID: Thread-Topic: responding to unknown SPIs Thread-Index: AcQG9BAP0RPMFwkNQQ2OZKyEVWKIpAJTIMkAAGmCw+A= From: "Charlie Kaufman" To: "Henderson, Thomas R" , X-OriginalArrivalTime: 24 Mar 2004 21:36:17.0823 (UTC) FILETIME=[0A6D32F0:01C411E8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id RAA14632 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I can't speak for the implementation experience around 'unknown SPI' notifications, but can explain the logic behind what's in the IKEv2 spec. IKEv2 defines a syntax for an INVALID_SPI notification, but does not require that they ever be sent and says that they MAY be ignored by recipients. It warns against sending them frequently enough to become an amplifier of a DOS attack or using them as definitive indications that they other end has rebooted. IKEv2 tests liveness with keep alive messages (which can be skipped if there is other traffic on the SA). This mechanism is reliable without INVALID_SPI notifications. There are two reasons INVALID_SPI might be useful. One is to trigger a liveness check and hence speed up recognition that a node has rebooted. The other is as a debugging aid trying to figure out what's going on if the network and/or one of the endpoints is flakey. I would expect most implementations to not bother with them. --Charlie -----On Monday, March 22, 2004 11:09 AM, Thomas R Henderson wrote: This is a request from the HIP WG for some information from IPsec WG participants. At IETF-59, there was some discussion on whether HIP (which functions similar to an IPsec key management protocol) should respond to ESP packets received with an unknown SPI. Some issues raised included: - don't IPsec key management protocols ignore these? (It was pointed out by a participant that the latest draft of IKEv2 has support for responding to them, in the Notify Payload) - what if multiple keying daemons (HIP, IPsec) are running on the same box-- do both respond? - what is the appropriate response, if there is one? (inside/outside SA context, rate limited, request to reestablish the SA?) - is a response dependent on whether the localhost determines that it has rebooted recently? - in practice, if a reboot has occurred, won't applications have lost their context anyway in this case? What is the scenario for which a response is useful? In looking at the latest draft (below), it seems that IKEv2 MAY respond, either within the SA context or outside, to these unknown SPIs, but there is not much further guidance given. In summary, at the HIP WG it was not clear if this was a useful mechanism, so we decided to defer to IPsec WG for guidance. Has it been found to be useful? Thanks, Tom >From http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-12.txt INVALID_SPI 11 MAY be sent in an IKE INFORMATIONAL Exchange when a node receives an ESP or AH packet with an invalid SPI. The Notification Data contains the SPI of the invalid packet. This usually indicates a node has rebooted and forgotten an SA. If this Informational Message is sent outside the context of an IKE_SA, it should only be used by the recipient as a "hint" that something might be wrong (because it could easily be forged). From owner-ipsec@lists.tislabs.com Wed Mar 24 15:30: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 i2ONUrxS000257; Wed, 24 Mar 2004 15:30:54 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA17793 Wed, 24 Mar 2004 17:53:52 -0500 (EST) Date: Wed, 24 Mar 2004 17:03:31 -0600 From: Nicolas Williams To: Stephen Kent Cc: Mohan Parthasarathy , ipsec@lists.tislabs.com Subject: Re: Remaining open issues for RFC-2401bis Message-ID: <20040324230331.GE5868@binky.central.sun.com> Mail-Followup-To: Stephen Kent , Mohan Parthasarathy , ipsec@lists.tislabs.com References: <21323.1080139608@marajade.sandelman.ottawa.on.ca> <00b501c411d7$4290e750$6501a8c0@adithya> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Mar 24, 2004 at 03:00:34PM -0500, Stephen Kent wrote: > At 11:36 AM -0800 3/24/04, Mohan Parthasarathy wrote: > >I hope this does not preclude ID_KEY_ID from carrying UTF-8 in an > >opaque way. I think this is what Paul Koning mentioned in an earlier mail. > > > > For the reasons cited earlier, I think it is a bad idea to carry > structured data like UTF-8 in what is described as an opaque octet > string. there is no reason to assume that there will be management > interfaces to facilitate entry of the data in a compatible fashion, > even without the encoding options that Paul has pointed out. Can you clarify whence the name of this ID? I think that the name, ID_KEY_ID, is consistent with use of the public key of the cert as the ID value. But just because the name seems to imply that doesn't mean that that was the original intention. Nico -- From owner-ipsec@lists.tislabs.com Wed Mar 24 15:39: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 i2ONd9rs000879; Wed, 24 Mar 2004 15:39:09 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA18825 Wed, 24 Mar 2004 18:04:57 -0500 (EST) Message-ID: <010701c411f6$17423b20$6501a8c0@adithya> From: "Mohan Parthasarathy" To: "Stephen Kent" Cc: References: <200403200415.i2K4FlQU007773@thunk.east.sun.com><16480.9936.57483.79888 6@fireball.acr.fi> <16480.32863.476549.187521@fireball.acr.fi> <00af01c411d6$d4716010$6501a8c0@adithya> Subject: Re: Remaining open issues for RFC-2401bis Date: Wed, 24 Mar 2004 15:16:51 -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 > > > > Stephen Kent writes: > >> > so, the problem we have is that the same ID type > >> > is defined to have two different uses: an account > >> > name, for which an IA5 or UTF-8 string would be > >> > >> There is no text in the IKEv1 defining it to be account name. IKEv1 > >> defined it to be "an opaque byte stream which may be used to pass > >> vendor-specific information necessary to identify which pre- shared > >> key should be used to authenticate Aggressive mode negotiations." > >> > >This was the main reason why i raised the issue i.e ID_KEY_ID is used > >to select pre-shared key and it was defined to be a opaque octet stream > >in IKEv1. This in conjunction with a road warrior case where the addresses > >are not known a priori, you need to use the information in ID_KEY_ID as > >selector. Please see draft-ietf-pana-ipsec-02.txt as an example of how > >this ID_KEY_ID is used to carry a session-ID - which is an opaque > >octet stream or possibly an UTF8 string carried in an opaque way. > > Let me note, again, that 2401bis assumes IKEv2, in lots of places, so But where possible, it should still work with IKEv1. > I don't think the use of this ID type in IKEv1 is central to this > discussion. There have been lots of good arguments why one might > choose to view this ID type a just a byte string, and why we might > want to add another ID type for conveying login IDs, but references > to IKEv1 are not among those good arguments :-) > ID_KEY_ID was used in IKEv1 in a particular way as Tero mentioned in the other email. One would like that to still work with IKEv2. Please see the other draft that i mentioned. It is useful to have opaque identifiers that are established by other means and use it as an ID to select the pre-shared key. > > > This account name thing was added in the IKEv2, and I do not know why > >> it was added. > >> > >> > appropriate, or an arbitrary byte sting, for > >> > which no further encoding is appropriate. I would > >> > be happy if we choose ONE of these two, but > > > > having both listed is a recipe for > >> > non-interoperability. > >> > >> Do we really need account name? Why cannot be use rfc822 address? > >> How about using the ID_KEY_ID to send the uid of the unix machine > >> (i.e. the numeric user id, as 16/32 bit number (2/4 octects)). > >> > >> > As for using a random number as an ID, note that this may not play > >> > well with the PAD description that we published. > >> > >> Why not, after the new ID has been exchanged, both the server and > >> client, will simply reconfigure the PAD to include the new ID. > >> > > > >Yes, i don't see why this is in conflict with the PAD description in 2401bis. > > I said this MAY be in conflict because there is not mention of PAD > entries being dynamically changed as a side effect of an initial IKE > exchange. And, as you may guess, I had not envisioned a context > where that would be required. In 2401 we needed to consider dynamic > SPD entries to accommodate road warriors. That is no longer the case, > because of the SPD cache in the model, and because of the > introduction of the PAD. I'm not claiming that there are no reasons > to have dynamic PAD entries, but none occurred to us in writing > 2401bis. > Ok. So, to accomodate the dynamic creation of PAD entries i.e not through an user interface, can we still include the ID_KEY_ID as specified in IKEv1 as a selector and define a new type for login names etc. which would also be another selector? thanks mohan > Steve From owner-ipsec@lists.tislabs.com Wed Mar 24 16:26: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 i2P0QQaZ003615; Wed, 24 Mar 2004 16:26:27 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA22876 Wed, 24 Mar 2004 18:40:25 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 24 Mar 2004 17:46:16 -0500 To: "Charlie Kaufman" From: Stephen Kent Subject: RE: Temporary version of the new IKEv2 draft 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 Charlie, I do not agree with this interpretation for IKEv2. So far the WG response to my memo on fragments has been pretty positive. If the WG agrees with the recommendations, then we need a way to represent ANY vs. OPAQUE, consistent with the semantics described in the memo. Since IKEv2 and 2401bis are so closely related, I don't think there is a benefit to trying to progress IKEv2 before we resolve the outstanding issues for 240bis. A major problem with IKEv1 and 2401 was the fact that the two were not completely aligned, resulting in ambiguity and downright inconsistencies. Let's try to avoid that this tme around. Steve From owner-ipsec@lists.tislabs.com Wed Mar 24 16:52: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 i2P0qgLi006182; Wed, 24 Mar 2004 16:52:42 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA00063 Wed, 24 Mar 2004 19:19:34 -0500 (EST) Message-ID: <011301c411f8$08f9b280$6501a8c0@adithya> From: "Mohan Parthasarathy" To: "Stephen Kent" Cc: References: <21323.1080139608@marajade.sandelman.ottawa.on.ca> <00b501c411d7$4290e750$6501a8c0@adithya> Subject: Re: Remaining open issues for RFC-2401bis Date: Wed, 24 Mar 2004 15:30:46 -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 11:36 AM -0800 3/24/04, Mohan Parthasarathy wrote: > > > > >> > >> >>>>> "VPNC" == VPNC writes: > >> VPNC> No, we don't. We have ways of encoding the display name and > >> VPNC> the coments, but *not* the address itself (called the > >> VPNC> "addr-spec"). RFC 822 and 2822 are completely clear on this. > >> > >> Ah, good point. > >> > >> >> 2) we could agree to permit UTF-8 in RFC822_ADDR. > >> > >> VPNC> Doing so and hoping that the Applications Area Directors don't > >> VPNC> barf is like > >> > >> Fine. Point made. > >> So, we need an identifier that can carry UTF-8, is known to carry > >> UTF-8, and isn't ID_KEY_ID. > >> > >I hope this does not preclude ID_KEY_ID from carrying UTF-8 in an > >opaque way. I think this is what Paul Koning mentioned in an earlier mail. > > > > For the reasons cited earlier, I think it is a bad idea to carry > structured data like UTF-8 in what is described as an opaque octet > string. there is no reason to assume that there will be management > interfaces to facilitate entry of the data in a compatible fashion, > even without the encoding options that Paul has pointed out. > ID_KEY_ID is defined as an opaque octet stream and UTF-8 can be carried as an opque stream of bytes where the two ends do a "memcmp" of the opaque byte stream to match on the ID contents. Why is this not possible ? As i mentioned in the other mail, this content may be dynamically generated. Perhaps we need a different ID to carry structured data like UTF8 that will be created through mangement interfaces. At least, that is what i understood from the emails on this topic. -mohan > Steve From owner-ipsec@lists.tislabs.com Wed Mar 24 18:00: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 i2P20VYd012235; Wed, 24 Mar 2004 18:00:31 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA12362 Wed, 24 Mar 2004 20:21:24 -0500 (EST) From: "Bora Akyol" To: "'Charlie Kaufman'" , "'Henderson, Thomas R'" , Subject: Keepalives (was RE: responding to unknown SPIs) Date: Wed, 24 Mar 2004 17:32:40 -0800 Message-ID: <001201c41209$11f4ad70$020a0a0a@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 Charlie Sending the keepalive messages on the IKE SA itself is not enough to conclude that the data connection is alive. Unless IKE v2 mandates keepalives to be sent in the data connection as opposed to the control connection, this does not solve the problem. You can have an IKE SA up, one side can think IPSEC SAs are up, however because the other side thinks that the SAs are not up. At least with IKE v1, this situation arises when the last message of an exchange gets lost. I am afraid a similar circumstance can happen in IKE v2 but I have not verified this in the lab so I am not going to say it does. And under these conditions, the keepalives on the IKE SA are not useful at all. You do need the INVALID_SPI message. However, I think this message itself is a DOS attack magnet for a security gateway so I would rather not implement it at all, and solve the lost message problem in a different way. Thanks Bora > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Charlie Kaufman > Sent: Wednesday, March 24, 2004 1:36 PM > To: Henderson, Thomas R; ipsec@lists.tislabs.com > Subject: RE: responding to unknown SPIs > > > I can't speak for the implementation experience around > 'unknown SPI' notifications, but can explain the logic behind > what's in the IKEv2 spec. > > IKEv2 defines a syntax for an INVALID_SPI notification, but > does not require that they ever be sent and says that they > MAY be ignored by recipients. It warns against sending them > frequently enough to become an amplifier of a DOS attack or > using them as definitive indications that they other end has rebooted. > > IKEv2 tests liveness with keep alive messages (which can be > skipped if there is other traffic on the SA). This mechanism > is reliable without INVALID_SPI notifications. There are two > reasons INVALID_SPI might be useful. One is to trigger a > liveness check and hence speed up recognition that a node has > rebooted. The other is as a debugging aid trying to figure > out what's going on if the network and/or one of the > endpoints is flakey. > > I would expect most implementations to not bother with them. > > --Charlie > > -----On Monday, March 22, 2004 11:09 AM, Thomas R Henderson > wrote: This is a request from the HIP WG for some information > from IPsec WG > participants. > > At IETF-59, there was some discussion on whether HIP (which functions > similar to an IPsec key management protocol) should respond to ESP > packets received with an unknown SPI. > > Some issues raised included: > - don't IPsec key management protocols ignore these? (It was > pointed out by a participant that the latest draft of IKEv2 > has support for responding to them, in the Notify Payload) > - what if multiple keying daemons (HIP, IPsec) are running on > the same box-- do both respond? > - what is the appropriate response, if there is one? > (inside/outside SA context, rate limited, request to > reestablish the SA?) > - is a response dependent on whether the localhost determines > that it has rebooted recently? > - in practice, if a reboot has occurred, won't applications have lost > their context anyway in this case? What is the scenario for which a > response is useful? > > In looking at the latest draft (below), it seems that IKEv2 > MAY respond, either within the SA context or outside, to these > unknown SPIs, but there is not much further guidance given. > > In summary, at the HIP WG it was not clear if this was a > useful mechanism, so we decided to defer to IPsec WG for > guidance. Has it been found to be useful? > > Thanks, > Tom > > > From http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-12.txt > > INVALID_SPI 11 > > MAY be sent in an IKE INFORMATIONAL Exchange when a node > receives an ESP or AH packet with an invalid SPI. The > Notification Data contains the SPI of the invalid packet. > This usually indicates a node has rebooted and > forgotten an > SA. If this Informational Message is sent outside the > context of an IKE_SA, it should only be used by the > recipient as a "hint" that something might be > wrong (because > it could easily be forged). > From owner-ipsec@lists.tislabs.com Wed Mar 24 21:24:17 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2P5OGu3024348; Wed, 24 Mar 2004 21:24:16 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA19320 Wed, 24 Mar 2004 23:37:26 -0500 (EST) Date: Wed, 24 Mar 2004 20:20:57 -0500 From: "Theodore Ts'o" To: Michael Roe Cc: ipsec@lists.tislabs.com Subject: Re: Final editing changes to IKEv2 Message-ID: <20040325012057.GA7158@thunk.org> References: <579E83556A36E44EB2945CCE990B317401269D81@EUR-MSG-02.europe.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <579E83556A36E44EB2945CCE990B317401269D81@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 24, 2004 at 02:41:43PM -0000, Michael Roe wrote: > I was referring to a different part of Charlie Lynn's message. I was talking > about bidirectional SA's that protect some MIPv6 messages and not others, not > unidirectional SA's. > > Suppose that you want to have a SA that only protects the Home Test > message (MH type = 3). Charlie Lynn's suggestion was... "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)". That was the part of Charlie Lynn's message which we specifically commended to Charlie's attention, and indeed it is in draft-ietf-ipsec-ikev2-13.txt. - Ted From owner-ipsec@lists.tislabs.com Thu Mar 25 06:16: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 i2PEG6If033293; Thu, 25 Mar 2004 06:16:06 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA04344 Thu, 25 Mar 2004 08:28:33 -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: <16482.57692.830072.313565@fireball.acr.fi> Date: Thu, 25 Mar 2004 15:40:44 +0200 From: Tero Kivinen To: "Charlie Kaufman" Cc: "Yoav Nir" , , "Paul Hoffman / VPNC" Subject: RE: EAP Roundtrips (was: Temporary version of the new IKEv2 draft) In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 3 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie Kaufman writes: > While minimizing round trips has been a priority in designing IKEv2, If we use EAP, there is quite often user interaction required anyways, thus saving one round trip after we have asked the password etc from the user, doesn't have that big effect. > minimizing protocol variations has also been a priority. By allowing the I think minimizing protocol variations is more important here, than one extra round trip when doing EAP. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Thu Mar 25 07:38:07 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 i2PFc6M8041902; Thu, 25 Mar 2004 07:38:07 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17489 Thu, 25 Mar 2004 10:01:58 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16482.57437.574350.440617@fireball.acr.fi> References: <200403200415.i2K4FlQU007773@thunk.east.sun.com> <16480.9936.57483.798886@fireball.acr.fi> <16480.32863.476549.187521@fireball.acr.fi> <16482.57437.574350.440617@fireball.acr.fi> Date: Thu, 25 Mar 2004 10:13:16 -0500 To: Tero Kivinen From: Stephen Kent Subject: Re: Remaining open issues for RFC-2401bis Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id KAA17482 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:36 PM +0200 3/25/04, Tero Kivinen wrote: >Stephen Kent writes: >> >How about using the ID_KEY_ID to send the uid of the unix machine >> >(i.e. the numeric user id, as 16/32 bit number (2/4 octects)). >> >> If the goal is to match account names precisely, >> then 822 addresses are not an ideal choice. I >> also would not suggest the Unix UID, since that >> is clearly an OS-specific approach. The goal in > >The unix UID was one example of IDs implementators might want to use >for the ID_KEY_ID. as an example it is fine. > > access control systems is to provide admins with >> name forms that mimic the ones that they are >> otherwise accustomed to dealing with. That's why >> a user login ID or account name is preferable in >> many cases. > >For example the unix kernel only knows about user IDs, it does not >know about user logi IDs or account names, and there is no way to map >user ID to user name (there might be multiple user names with same >user ID). Because of that if IPsec is used between two unix machines >belonging to the same NIS domain etc (== same UIDs) it would make >perfect sense to use the UID as a ID inside the IKE (when creating per >UID SAs between two hosts). I think I'm not communicating well here. As a user and for most admin functions, login names will be used for access control, nit the internal UIDs that the kernel sees. My concern is that if we intend to represent character string IDs in an ID type, then it behooves us to use a suitably restrictive syntax for that purpose. the reasoning is that a vendor will offer a management interface appropriate for a given syntax and we want the management interface to be easy for users and admins, not only because it makes life easier, but because it helps avoid management-induced vulnerabilities. >Again this was simply an example how the ID_KEY_ID can be used. In >some other environment it might be used completely differently. > >> >If my account name is Törvelä, I will encode it in the same way >> >in my client and in my server, as they are most likely adminstrated by >> >the same persons. If the adminstrator cannot enter my account name, he >> >will propably say, that your new account name for the VPN use will be >> >"Torvela". >> >> The client and server may be produced by >> different vendors, and if only one provides a >> management interface for UTF-8 ID input, then >> there is a possibility that it will not be easy >> to get the two to match. > >Yes, but if both ends provides way to enter binary data, it is always >possible to make them match. You simply take the UTF-8 formatted ID >from the server, and configure that in to the client as binary octect >string. No problems with different ways to encode the umlauts etc in >the login name. no problme encoding at a low level, but a big problem entering the data. > >> my experience with 801.11 passwords says >> otherwise, i.e., it was not possible to configure >> the access point and my computers to interoperate >> because of the management interface discrepancies. > >And the reason is, that somebody assumed that the password is plain >ASCII, or any text. If they only way to configure it in is the >hex-string or similar, then there would not be problems... but the point was that vendors acted in what they believed was a reasonable way give a lack of syntactic direction. hex would be workable, but is often harder for a user.when Apple user ASCII, I could use a pass phrase as the key. when I had to use hex to enter the data, life became much harder, and it took several tries to get the same data into the access point and each machine. does anyone think that's a feature? >That is exactly the reason I do not like the idea of UTF-8 there. It >requires the implementators to actually do something for that. Quite >often they say, ok, I create this dialog box, which supports any >characters, so it simply matter of the input device if you can enter >the name or not. And if you do not happen to have Japanese input >support installed, there is no way, you can enter the Japanese name. yes, this makes it harder for implementors, and easier for users. offering a GUI for management is also harder for implementors and easier for users. I think we have to accept the possibility that additional effort for implementors is sometimes appropriate, if it yields a better user interface. >If we mandate that there must be way to insert ID_KEY_ID as binary >octect string (either in hex or something similar, including NULs), >then we can always enter those names to the system. It might not be >easy, as it might require converting the name to the ISO10646 and then >UTF-8 and then to hex, but it is possible. yes, possible, but maybe not easy. >Vendors are of course allowed to provide other means to input the >item, like dialog box asking it as string. allowed, yes, required, no. As a user I would like to try to make my life easier whenever possible. > > Agreed. But, then we should not expect this ID > > type to be used to login/account IDs, since there >> is a chance that it will be infeasible for many >> folks to configure such ID types using only a >> binary representation. > >You again assume that vendors will only support exactly one way to >enter the data in. Most of the implementations out there already have >way to specify the shared-secret either in text or in hex, so the >implementators do know how to do it... :-) I can't comment on what most vendors do in the shared secret case for IPsec implementations. I just cited my bad experience in a different but equivalent context, and it was not good. Steve From owner-ipsec@lists.tislabs.com Thu Mar 25 07:40: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 i2PFeCvV042163; Thu, 25 Mar 2004 07:40:15 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17480 Thu, 25 Mar 2004 10:01:46 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <011301c411f8$08f9b280$6501a8c0@adithya> References: <21323.1080139608@marajade.sandelman.ottawa.on.ca> <00b501c411d7$4290e750$6501a8c0@adithya> <011301c411f8$08f9b280$6501a8c0@adithya> Date: Thu, 25 Mar 2004 09:45:00 -0500 To: "Mohan Parthasarathy" From: Stephen Kent Subject: Re: Remaining open issues for RFC-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 3:30 PM -0800 3/24/04, Mohan Parthasarathy wrote: > > >> At 11:36 AM -0800 3/24/04, Mohan Parthasarathy wrote: >> > > >> >> >> >> >>>>> "VPNC" == VPNC writes: >> >> VPNC> No, we don't. We have ways of encoding the display name and >> >> VPNC> the coments, but *not* the address itself (called the >> >> VPNC> "addr-spec"). RFC 822 and 2822 are completely clear on this. >> >> >> >> Ah, good point. >> >> >> >> >> 2) we could agree to permit UTF-8 in RFC822_ADDR. >> >> >> >> VPNC> Doing so and hoping that the Applications Area Directors don't >> >> VPNC> barf is like >> >> >> >> Fine. Point made. >> >> So, we need an identifier that can carry UTF-8, is known to carry >> >> UTF-8, and isn't ID_KEY_ID. >> >> >> >I hope this does not preclude ID_KEY_ID from carrying UTF-8 in an >> >opaque way. I think this is what Paul Koning mentioned in an earlier mail. >> > >> >> For the reasons cited earlier, I think it is a bad idea to carry >> structured data like UTF-8 in what is described as an opaque octet >> string. there is no reason to assume that there will be management >> interfaces to facilitate entry of the data in a compatible fashion, >> even without the encoding options that Paul has pointed out. >> >ID_KEY_ID is defined as an opaque octet stream and UTF-8 can be >carried as an opque stream of bytes where the two ends do a "memcmp" of the >opaque byte stream to match on the ID contents. Why is this not possible ? >As i mentioned in the other mail, this content may be dynamically generated. >Perhaps we need a different ID to carry structured data like UTF8 that will be >created through mangement interfaces. At least, that is what i understood from >the emails on this topic. My comments on management interfaces for this ID type get at the heart of the problem, and I'm a bit disappointed that your messages seem to keep ignoring that. This discussion has never been about how to perform a comparison of the data; it is about whether users and admins interacting with different vendor products will have appropriate management interfaces to enter the data that is sent and that forms the basis for checking, IF the description of the semantics of the data were as stated in IKEv2. Nonetheless, I agree that a good way to resolve this is to change the IKE text back to the v1 version, that makes no mention of account IDs etc. Then, if the WG wants, a separate ID type can be created to carriage of account info such as login IDs. Steve From owner-ipsec@lists.tislabs.com Thu Mar 25 10:29: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 i2PITHWq057487; Thu, 25 Mar 2004 10:29:19 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00407 Thu, 25 Mar 2004 12:45:34 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16482.56582.91481.918705@fireball.acr.fi> References: <16480.15529.482315.278735@fireball.acr.fi> <16482.56582.91481.918705@fireball.acr.fi> Date: Thu, 25 Mar 2004 12:56:59 -0500 To: Tero Kivinen From: Stephen Kent Subject: Re: 2nd try 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:22 PM +0200 3/25/04, Tero Kivinen wrote: >Stephen Kent writes: >> >And as IKEv1 didn't offer any support for OPAQUE, there cannot really >> >be implementations using that method with IKEv1 (i.e. IKEv1 cannot >> >negotiate such SA for OPAQUE traffic). >> Agreed, But 2401bis assumes use of IKEv2 in several instances, so I >> don't see this as a problem. > >I was commenting that IKEv1 does not support it, thus there cannot be >implementations supporting that format => if we mandate that now in >the RFC2401bis then all implementations needs to add new code to >support that. agreed, but 2401bis also requires support for other features that arise only in IKEv2, so this would not be the only reason that new/changed code is required. >On the other hand there is (several?) implementations out which do >partial reassembly, which means that it is already tested and working >method of fixing that problem. yes, and that's a good reason to include it as an option, but not as a mandatory facility. > > >If you have SA with port selectors between SGWs you cannot allow clear >> >text non-first fragments without (partial) reassembly between SGWs. >> > >> >I.e. if you have rules >> > >> > A <-> B port 25 ESP with auth >> > A <-> B non-first fragments in clear (i.e. bypass) >> > >> >Then attacker who sees or (or forces) the A to send fragmented packet >> >can modify the non-first fragments regardless whether the SGW1 >> >encrypted all the fragments of the packet from A, and the SGW2 will >> >accept them based on the second policy rule. . >> >> I agree that the second rule would be a bad config choice. But I >> disagree with the conclusion that one must do some form of reassembly >> if fragments are allowed to bypass. We ought not impose this >> requirement just to counter the bad effects of a bad config choice. > >If we do not add that requirements, then the problem is that if user >uses vendor 1 IPsec with that configuration and which uses the partial >reassembly it is secure, but if he switches to vendor 2 IPsec which do >not do partial reassmebly his working policy suddenly comes insecure. >That can be quite suprise to the adminstrator, and I think some kind >of warning for the implementators should be in the text, if there is >no requirement for partial reassembly. I'm all in favor of a warning. > > >> 3. An implementation MAY choose to support some form of stateful >> >> fragment checking for a tunnel mode SA with non-trivial port field >> >> values (not ANY or OPAQUE). Implementations that will transmit >> >> non-initial fragments on a tunnel mode SA that makes use of >> >> non-trivial port selectors MUST notify a peer via an IKE payload >> >> (TBD). >> > >> >Why? If the other end only supports the case #2, then it only needs to >> >check that the SA which is used to carry the traffic has enough >> >security to take care of the non-initial fragments. I.e. if the >> >senders policy is use ESP AES for port 25, and the responders is use >> >ESP AES for port 25, and any ESP stronger than 80-bits for non-inigial >> >fragments, then it can safely accept the non-initial packets coming >> >from the SA negotiated for the port 25. >> >> Since it appears that nothing short of reassembly will be safe for >> v6, I think it is important to add this case. > >The "why?" was for "why do you need to notify that with IKE?". The need to notification is required, I think, because support for reassembly is not mandated in my proposal. So if an implementation sends fragments across an SA that requires port checking, the receiver should reject non-initial fragments unless it has said that it is prepared to deal with them via reassembly (prior to checking). > >> Also, you and some >> other folks have indicted that this approach seems reasonable for >> many contexts, where very high speed >> processing it not an issue. So, my reason for including #3 above is >> to allow folks who want to do reassembly to do it, but not to impose >> it as a burden for folks who don't feel that this strategy is > > compatible with their system requirements/architecture. > >I think we do need case #3, but I do not think we need to negotiate it >with notifications. I also think that case #2 and case #3 >implementations can interoperate without any problems. > >I use port fragment to indicate the fragment which contains the port >numbers, and non-port fragment to indicate the fragment which do not >have port numbers. > >If you ONLY support #2, then you create non-port fragment SA, and you >accept any non-port fragments from there. You MUST also accept any >non-port fragments from any port fragment SA, provided that the >security of that port fragment SA is "enough" compared to the non-port >fragment SA. There is no need to do any partial-reassembly for any of >the traffic regardless whether it was received from the non-port >fragment SA or from port fragment SA. agreed, but this works only for IPv4. >If you support #3, then you MUST send all non-port fragments to same >port-fragment SA which was used for the fragment containing the port >numbers of the packet. When you receive fragments from the any source, >you do the partial-reassembly and verify that the packet is allowed by >policy. If the fragment was received from the any other SA than which >would carry the port-fragment of the packet, then you also need to >verify that the security of that SA is "enough" compared to the >port-fragment SA, which should have been used. A sender might choose approach #3 because he will receive non-fragmented packets, map them to a port-specific SA, then fragment them on the protected side, and send them over the port-specific SA. in this simple case the receiver needs to be willing to deal with the fragments that otherwise would not be acceptable on the SA in question. This case, by itself, motivates the need to check with the receiver to ensure that the receiver will accept fragments on a port-specific SA. In this case there is no need to check to see if the security of the SA in question is "good enough," as there there was no ambiguity in mapping the non-fragmented packet to the SA. Steve From owner-ipsec@lists.tislabs.com Thu Mar 25 14:31: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 i2PMVW6x074496; Thu, 25 Mar 2004 14:31:32 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10088 Thu, 25 Mar 2004 16:53:12 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc Message-Id: Date: Thu, 25 Mar 2004 12:42:58 -0800 To: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esn-addendum-03.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Extended Sequence Number Addendum to IPsec DOI for ISAKMP Author(s) : S. Kent Filename : draft-ietf-ipsec-esn-addendum-03.txt Pages : 6 Date : 2004-2-16 The IP Security Authentication Header (AH) and Encapsulating Security Payload (ESP) protocols use a sequence number to detect replay. This document describes extensions to the Internet IP Security Domain of Interpretation (DOI) for the Internet Security Association and Key Management Protocol(ISAKMP). These extensions support negotiation of the use of traditional 32-bit sequence numbers or extended 64-bit sequence numbers for a particular AH or ESP security association. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esn-addendum-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esn-addendum-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-esn-addendum-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. [The following attachment must be fetched by mail. Command-click the URL below and send the resulting message to get the attachment.] [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] From owner-ipsec@lists.tislabs.com Thu Mar 25 14:47: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 i2PMlt9Z075229; Thu, 25 Mar 2004 14:47:55 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA12847 Thu, 25 Mar 2004 17:15:50 -0500 (EST) Message-ID: <002901c412a1$908d7200$861167c0@adithya> From: "Mohan Parthasarathy" To: "Stephen Kent" Cc: References: <21323.1080139608@marajade.sandelman.ottawa.on.ca> <00b501c411d7$4290e750$6501a8c0@adithya> <011301c411f8$08f9b280$6501a8c0@adithya> Subject: Re: Remaining open issues for RFC-2401bis Date: Thu, 25 Mar 2004 11:44:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >> > > > >> >> > >> >> >>>>> "VPNC" == VPNC writes: > >> >> VPNC> No, we don't. We have ways of encoding the display name and > >> >> VPNC> the coments, but *not* the address itself (called the > >> >> VPNC> "addr-spec"). RFC 822 and 2822 are completely clear on this. > >> >> > >> >> Ah, good point. > >> >> > >> >> >> 2) we could agree to permit UTF-8 in RFC822_ADDR. > >> >> > >> >> VPNC> Doing so and hoping that the Applications Area Directors don't > >> >> VPNC> barf is like > >> >> > >> >> Fine. Point made. > >> >> So, we need an identifier that can carry UTF-8, is known to carry > >> >> UTF-8, and isn't ID_KEY_ID. > >> >> > >> >I hope this does not preclude ID_KEY_ID from carrying UTF-8 in an > >> >opaque way. I think this is what Paul Koning mentioned in an earlier mail. > >> > > >> > >> For the reasons cited earlier, I think it is a bad idea to carry > >> structured data like UTF-8 in what is described as an opaque octet > >> string. there is no reason to assume that there will be management > >> interfaces to facilitate entry of the data in a compatible fashion, > >> even without the encoding options that Paul has pointed out. > >> > >ID_KEY_ID is defined as an opaque octet stream and UTF-8 can be > >carried as an opque stream of bytes where the two ends do a "memcmp" of the > >opaque byte stream to match on the ID contents. Why is this not possible ? > >As i mentioned in the other mail, this content may be dynamically generated. > >Perhaps we need a different ID to carry structured data like UTF8 that will be > >created through mangement interfaces. At least, that is what i understood from > >the emails on this topic. > > My comments on management interfaces for this ID type get at the > heart of the problem, and I'm a bit disappointed that your messages > seem to keep ignoring that. This discussion has never been about how > to perform a comparison of the data; it is about whether users and > admins interacting with different vendor products will have > appropriate management interfaces to enter the data that is sent and > that forms the basis for checking, IF the description of the > semantics of the data were as stated in IKEv2. > I do see your point about how if we restrict the ID_KEY_ID to account names /login names as stated in IKEv2 will make the interactions with various vendor products easier. But the other point that was made in this thread is that ID_KEY_ID also has been used to select pre-shared key and it can carry a opaque stream of bytes. The data for ID_KEY_ID itself may be configured using some management interface or dynamically generated. For the dynamically generated case, there is no issue i suppose. But if we use ID_KEY_ID for values entered through management interfaces also, then the issue of "how different products would support this" comes up. At least it looks like we need flexibility in one case (dynamic) and restriction in another case (configuration through UI) to make configuration easier. I can see how it can become a nightmare configuring product from Vendor X using ASCII and configuring product from Vendor Y using hex for making it communicate with each other. But at least there is a possiblity that you can get this right by doing the right conversion. But if you restrict it to use only login names, then the flexibility is lost. I know at least that 3GPP2 uses the ID_KEY_ID that is generated dynamically and communicated using RADIUS. There may be others e.g PANA that will use ID_KEY_ID to carry session ids. > Nonetheless, I agree that a good way to resolve this is to change the > IKE text back to the v1 version, that makes no mention of account IDs > etc. > Will RFC 2401bis also reflect the same ? > Then, if the WG wants, a separate ID type can be created to carriage > of account info such as login IDs. > Sounds good to me. thanks mohan > Steve From owner-ipsec@lists.tislabs.com Thu Mar 25 15:02: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 i2PN2hPl076731; Thu, 25 Mar 2004 15:02:43 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA15101 Thu, 25 Mar 2004 17:29:07 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Thu, 25 Mar 2004 14:41:35 -0800 To: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ikev2-13.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Internet Key Exchange (IKEv2) Protocol Author(s) : C. Kaufman Filename : draft-ietf-ipsec-ikev2-13.txt Pages : 105 Date : 2004-3-25 This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations. This version of the IKE specification combines the contents of what were previously separate documents, including ISAKMP (RFC 2408), IKE (RFC 2409), the Internet DOI (RFC 2407), NAT Traversal, Legacy authentication, and remote address acquisition. Version 2 of IKE does not interoperate with version 1, but it has enough of the header format in common that both versions can unambiguously run over the same UDP port. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-13.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ikev2-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. [The following attachment must be fetched by mail. Command-click the URL below and send the resulting message to get the attachment.] [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] From owner-ipsec@lists.tislabs.com Thu Mar 25 17:43: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 i2Q1hQl9087912; Thu, 25 Mar 2004 17:43:27 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA22841 Thu, 25 Mar 2004 19:58:25 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <002901c412a1$908d7200$861167c0@adithya> References: <21323.1080139608@marajade.sandelman.ottawa.on.ca> <00b501c411d7$4290e750$6501a8c0@adithya> <011301c411f8$08f9b280$6501a8c0@adithya> <002901c412a1$908d7200$861167c0@adithya> Date: Thu, 25 Mar 2004 15:17:36 -0500 To: "Mohan Parthasarathy" From: Stephen Kent Subject: Re: Remaining open issues for RFC-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 > > Nonetheless, I agree that a good way to resolve this is to change the >> IKE text back to the v1 version, that makes no mention of account IDs >> etc. >> >Will RFC 2401bis also reflect the same ? Yes. Steve From owner-ipsec@lists.tislabs.com Thu Mar 25 18:38: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 i2Q2cuD2092552; Thu, 25 Mar 2004 18:38:56 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA27732 Thu, 25 Mar 2004 20:53:17 -0500 (EST) Message-Id: <5.2.0.9.0.20040325174856.00abc208@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 25 Mar 2004 19:10:37 -0500 To: Stephen Kent , ipsec@lists.tislabs.com From: Mark Duffy Subject: Re: 2nd try In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks, Steve. This gives a very nice summary of the issues! And, I agree in general with the recommendations. Some specific comments/questions embedded below... --Mark At 09:05 PM 3/22/2004 -0500, Stephen Kent wrote: ... >In 2401bis, we have explicitly said that it's OK to use transport mode in >cases where the IPsec implementation is not the ultimate destination, >e.g., between two SGs. In principle, this creates a new opportunity for >outbound, plaintext fragments to be mapped to a transport mode SA for >IPsec processing. However, in these new contexts in which a transport mode >SA is now approved for use, it seems likely that we can continue to >prohibit transmission of fragments, as seen by IPsec. For example, in an >IP overlay network, packets being sent over transport mode SAs are >IP-in-IP tunneled and thus have the necessary inner header to accommodate >fragmentation prior to IPsec processing. When carried via a transport mode >SA, IPsec would not examine the inner IP header for such traffic, and thus >would not consider the packet to be a fragment. Thus it seems reasonable >to retain the prohibition on carrying IPv4 fragments on transport mode >SAs, even when the source or destination is an SG. My suggestion would be to simply say (e.g. in 2401bis sect 4.1): The use of transport mode by intermediate devices (e.g. SGs) is permitted only when applied to packets whose source (for outbound packets) or destination (for inbound packets) address is an address belonging to the intermediate system itself. In these cases the intermediate system is essentially acting as a host with respect to those packets. ... >If we simplify the procedure employed to locate the next layer protocol in >2401bis, so that we treat ESP and AH as next layer protocols, then the >notion of an encrypted next layer protocol field has vanished, and there >is also no need to worry about encrypted port fields either. Yes please. In fact, I thought this was already decided. I.e. in 2401bis-01 section 4.4.2 Selectors: 'Next Layer Protocol: Obtained from the IPv4 "Protocol" or ...' ... >Conclusions ... >1. All implementations MUST support tunnel mode SAs that pass traffic >without regard to port field values. And must support bypass/drop rules that operate without regard to port field values, no? ... >2. All implementations MUST support tunnel mode SAs that will carry only >non-initial fragments, separate from non-fragmented packets and initial >fragments. And must support bypass/drop rules that will match only non-initial fragments, no? ... >Also, because a SA of this sort will carry ALL non-initial fragments that >match a specified source/destination address pair and protocol value, >users and administrators are advised to protect such traffic using ESP >(with integrity) and the "strongest" integrity and encryption algorithms >available at both peers. (Determination of the "strongest" algorithms >requires imposing a total ordering of the available algorithms, a local >determination at the discretion of the initiator of the SA.) Isn't it also at the discretion of the responder? >3. An implementation MAY choose to support some form of stateful fragment >checking for a tunnel mode SA with non-trivial port field values (not ANY >or OPAQUE). Implementations that will transmit non-initial fragments on a >tunnel mode SA that makes use of non-trivial port selectors MUST notify a >peer via an IKE payload (TBD). The peer MUST reject this proposal if it >will not accept non-initial fragments in this context. If an >implementation does not successfully negotiate transmission of non-initial >fragments for such an SA, it MUST NOT send such fragments over the SA. >This standard does not specify how peers will deal with such fragments, >e.g., via reassembly or other means, at either sender or receiver. >However, a receiver MUST drop non-initial fragments that arrive on an SA >with non-trivial port selector values unless this feature has been negotiated. This wording does not preclude an implementation from negotiating this feature but then failing to do the expected checking on received packets. Should it state that if the feature has been negotiated, the receiver MUST NOT accept non-initial fragments without verifying that they comply with the security policy called for for the overall packet? Also, I think that #3 also should state that a receiver that has negotiated the feature must not accept non-initial fragments for bypass without verifying that they comply with the security policy called for for the overall packet. ------------ One final issue, does port selector ANY encompass OPAQUE? To my sensibilities ANY means any value in the range (e.g. 0..65535) and the port values of an opaque packet are surely in this range even if we don't know them. If there is some value (what is it?) in having an ANY concept that does not include OPAQUE, it should be clearly named e.g. ANY_NONOPAQUE. Here is at least one specific reason why ANY *should* include OPAQUE. (Yes, I realize that this is an arcane case.) For approach #1 we use port-blind policies. If ANY includes opaque then the port selectors are simply: source port = ANY, dest port = ANY. But if ANY and OPAQUE are disjoint then (here's where it gets arcane ;-) it is possible that a an initial fragment will come along that contains the source port but not the dest port. The policy for approach #1 to cover this case would need to be: source port = ANY, dest port = ANY or source port = ANY, dest port = OPAQUE or source port = OPAQUE, dest port = OPAQUE What administrator is going to think to provision that? --Thanks, Mark From owner-ipsec@lists.tislabs.com Fri Mar 26 05:17:23 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 i2QDHNYN011142; Fri, 26 Mar 2004 05:17:23 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA17429 Fri, 26 Mar 2004 07:37: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: <16483.65081.442633.47762@fireball.acr.fi> Date: Fri, 26 Mar 2004 11:56:09 +0200 From: Tero Kivinen To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: Re: Remaining open issues for RFC-2401bis In-Reply-To: References: <200403200415.i2K4FlQU007773@thunk.east.sun.com> <16480.9936.57483.798886@fireball.acr.fi> <16480.32863.476549.187521@fireball.acr.fi> <16482.57437.574350.440617@fireball.acr.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 5 min X-Total-Time: 4 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > I can't comment on what most vendors do in the > shared secret case for IPsec implementations. I > just cited my bad experience in a different but > equivalent context, and it was not good. All of my bad experiences are because someone thought to be user friendly and only created text input box where the password can be written. It is extremly hard (or impossible) to write binary key 0x44f7ba0052dc29b4812d2e9b165b410d to that box, thus that laptop user who have only text input box will not be able to use system at all. Most of those who provided the hex-input also provided a way to type the key in as string. Thus, saying it is binary string, and you MUST offer way to put in any binary string (up to certain length) works better, as it will always offer interoperability (I agree it might not be that user friendly, but that is something that the vendor can fix if they feel like making it user friendly). -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Fri Mar 26 10:16: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 i2QIG2WS031053; Fri, 26 Mar 2004 10:16:02 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24241 Fri, 26 Mar 2004 12:23:04 -0500 (EST) Subject: IDci and IDcr payloads with NAT Traversal To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: David Wierbowski Date: Fri, 26 Mar 2004 12:35:06 -0500 X-MIMETrack: Serialize by Router on D01MLL83/01/M/IBM(Build V652_03112004NP|March 11, 2004) at 03/26/2004 12:35:15 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have a question about the ID payloads exchanged in Quick Mode when NAT Traversal is being utilized in the following scenario: HOST A ----> GW ----> GW's NAT ----> B's NAT ----> HOST B 10.1.1.123 10.1.1.1 10.2.2.2 Where: - The private address for HOST A is 10.1.1.123 - The private address for GW is 10.1.1.1 - GW's NAT translates 10.1.1.1. to x.x.x.x - The private address for HOST B is 10.2.2.2 - B's NAT translates 10.2.2.2 to y.y.y.y - GW is trying to create a phase 2 SA with HOST B to protect traffic between HOST A and HOST B My questions are: - is this a valid scenario? - if it is, then what IP addresses should be utilized in IDci and IDcr? Thanks Dave Wierbowski z/OS Comm Server Developer From owner-ipsec@lists.tislabs.com Fri Mar 26 10:30: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 i2QIUiiZ032083; Fri, 26 Mar 2004 10:30:44 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA26107 Fri, 26 Mar 2004 12:47:15 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16483.65081.442633.47762@fireball.acr.fi> References: <200403200415.i2K4FlQU007773@thunk.east.sun.com> <16480.9936.57483.798886@fireball.acr.fi> <16480.32863.476549.187521@fireball.acr.fi> <16482.57437.574350.440617@fireball.acr.fi> <16483.65081.442633.47762@fireball.acr.fi> Date: Fri, 26 Mar 2004 12:44:52 -0500 To: Tero Kivinen From: Stephen Kent Subject: Re: Remaining open issues for RFC-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:56 AM +0200 3/26/04, Tero Kivinen wrote: >Stephen Kent writes: >> I can't comment on what most vendors do in the >> shared secret case for IPsec implementations. I >> just cited my bad experience in a different but >> equivalent context, and it was not good. > >All of my bad experiences are because someone thought to be user >friendly and only created text input box where the password can be >written. It is extremly hard (or impossible) to write binary key >0x44f7ba0052dc29b4812d2e9b165b410d to that box, thus that laptop user >who have only text input box will not be able to use system at all. >Most of those who provided the hex-input also provided a way to type >the key in as string. > >Thus, saying it is binary string, and you MUST offer way to put in any >binary string (up to certain length) works better, as it will always >offer interoperability (I agree it might not be that user friendly, >but that is something that the vendor can fix if they feel like making >it user friendly). And my bad experience is that while I could create and remember a key in the form of a pass phrase character string, I had to write down the hex key I created and very carefully, manually enter it into each system, which was error prone (despite my care), frustrating, and a very poor use of my time. I fear that you bring an implementer perspective to the problem, and I bring a user perspective, and it is unfortunate that the two don't overlap better :-) Steve From owner-ipsec@lists.tislabs.com Fri Mar 26 15: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 i2QNLVeI065012; Fri, 26 Mar 2004 15:21:31 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA03501 Thu, 25 Mar 2004 08:24:17 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <16482.57437.574350.440617@fireball.acr.fi> Date: Thu, 25 Mar 2004 15:36:29 +0200 From: Tero Kivinen To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: Re: Remaining open issues for RFC-2401bis In-Reply-To: References: <200403200415.i2K4FlQU007773@thunk.east.sun.com> <16480.9936.57483.798886@fireball.acr.fi> <16480.32863.476549.187521@fireball.acr.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 13 min X-Total-Time: 12 min Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id IAA03491 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > >How about using the ID_KEY_ID to send the uid of the unix machine > >(i.e. the numeric user id, as 16/32 bit number (2/4 octects)). > > If the goal is to match account names precisely, > then 822 addresses are not an ideal choice. I > also would not suggest the Unix UID, since that > is clearly an OS-specific approach. The goal in The unix UID was one example of IDs implementators might want to use for the ID_KEY_ID. > access control systems is to provide admins with > name forms that mimic the ones that they are > otherwise accustomed to dealing with. That's why > a user login ID or account name is preferable in > many cases. For example the unix kernel only knows about user IDs, it does not know about user logi IDs or account names, and there is no way to map user ID to user name (there might be multiple user names with same user ID). Because of that if IPsec is used between two unix machines belonging to the same NIS domain etc (== same UIDs) it would make perfect sense to use the UID as a ID inside the IKE (when creating per UID SAs between two hosts). Again this was simply an example how the ID_KEY_ID can be used. In some other environment it might be used completely differently. > >If my account name is Törvelä, I will encode it in the same way > >in my client and in my server, as they are most likely adminstrated by > >the same persons. If the adminstrator cannot enter my account name, he > >will propably say, that your new account name for the VPN use will be > >"Torvela". > > The client and server may be produced by > different vendors, and if only one provides a > management interface for UTF-8 ID input, then > there is a possibility that it will not be easy > to get the two to match. Yes, but if both ends provides way to enter binary data, it is always possible to make them match. You simply take the UTF-8 formatted ID from the server, and configure that in to the client as binary octect string. No problems with different ways to encode the umlauts etc in the login name. > my experience with 801.11 passwords says > otherwise, i.e., it was not possible to configure > the access point and my computers to interoperate > because of the management interface discrepancies. And the reason is, that somebody assumed that the password is plain ASCII, or any text. If they only way to configure it in is the hex-string or similar, then there would not be problems... That is exactly the reason I do not like the idea of UTF-8 there. It requires the implementators to actually do something for that. Quite often they say, ok, I create this dialog box, which supports any characters, so it simply matter of the input device if you can enter the name or not. And if you do not happen to have Japanese input support installed, there is no way, you can enter the Japanese name. If we mandate that there must be way to insert ID_KEY_ID as binary octect string (either in hex or something similar, including NULs), then we can always enter those names to the system. It might not be easy, as it might require converting the name to the ISO10646 and then UTF-8 and then to hex, but it is possible. Vendors are of course allowed to provide other means to input the item, like dialog box asking it as string. > Agreed. But, then we should not expect this ID > type to be used to login/account IDs, since there > is a chance that it will be infeasible for many > folks to configure such ID types using only a > binary representation. You again assume that vendors will only support exactly one way to enter the data in. Most of the implementations out there already have way to specify the shared-secret either in text or in hex, so the implementators do know how to do it... :-) -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Fri Mar 26 15:21:53 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 i2QNLngp065041; Fri, 26 Mar 2004 15:21:52 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08811 Thu, 25 Mar 2004 08:52:28 -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: <16482.59064.936893.286507@fireball.acr.fi> Date: Thu, 25 Mar 2004 16:03:36 +0200 From: Tero Kivinen To: "Bora Akyol" Cc: "'Charlie Kaufman'" , "'Henderson, Thomas R'" , Subject: Keepalives (was RE: responding to unknown SPIs) In-Reply-To: <001201c41209$11f4ad70$020a0a0a@amer.cisco.com> References: <001201c41209$11f4ad70$020a0a0a@amer.cisco.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 8 min X-Total-Time: 8 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bora Akyol writes: > Sending the keepalive messages on the IKE SA itself is not > enough to conclude that the data connection is alive. Unless > IKE v2 mandates keepalives to be sent in the data connection > as opposed to the control connection, this does not solve > the problem. > > You can have an IKE SA up, one side can think IPSEC SAs are up, > however because the other side thinks that the SAs are not up. No you cannot in IKEv2. > At least with IKE v1, this situation arises when the last message > of an exchange gets lost. I am afraid a similar circumstance can > happen in IKE v2 but I have not verified this in the lab so > I am not going to say it does. The initiator is mandated to resend the final packet until it gets reply back to that. If it does not get reply ever, it will assume that the IKE SA has failed, and tear down the IKE SA along with all IPsec SAs created with that IKE SA. So if that happens then the other end will remove both IKE and IPsec SAs, and the next keepalive packet will fail and the other end will also do the same. Also the IKEv2 drafts forbids conditions where the IPsec SA could fail when the IKEv2 SA still works. I.e. if the IPsec SA processing is offloaded to another processor, and that processor can fail separately from the IKE SA processor, then IKE SA processor must make sure that the IPsec SA processor is alive and working all the time. If the IPsec SA processor fails (or loses SAs), then IKE SA processor must remove IKE SAs too. > And under these conditions, the keepalives on the IKE SA > are not useful at all. You do need the INVALID_SPI message. > However, I think this message itself is a DOS attack magnet for > a security gateway so I would rather not implement it at all, > and solve the lost message problem in a different way. The INVALID_SPI message is used when your host is just rebooted, and you receive ESP packet which has unknown SPI. You could simply ignore it, and after couple of minutes or tens of minutes (depending on the configuration) the other end will notice that you are not responding to its IKE keepalives, and tear down the IKE and IPsec SAs. If instead of that you send unprotected INVALID_SPI notification, then the other end will immediately know that there might be problem, thus it can immediately send keepalive, and when you do not reply that within say 60 seconds (after 3-10 retransmits or so), then it can tear down the IKE SA and IPsec SA. After that the next packet will trigger the creation of the new IKE and IPsec SA and the connection is up and running again. You do not want to send protected INVALID_SPI as that would require you to first create IKE SA besed on completely unauthenticated ESP packet having invalid SPI. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Fri Mar 26 16:04:14 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 i2R04E3v067137; Fri, 26 Mar 2004 16:04:14 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00945 Thu, 25 Mar 2004 08:09:52 -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: <16482.56582.91481.918705@fireball.acr.fi> Date: Thu, 25 Mar 2004 15:22:14 +0200 From: Tero Kivinen To: Stephen Kent Cc: ipsec@lists.tislabs.com, russ housley Subject: Re: 2nd try In-Reply-To: References: <16480.15529.482315.278735@fireball.acr.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 42 min X-Total-Time: 42 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > >And as IKEv1 didn't offer any support for OPAQUE, there cannot really > >be implementations using that method with IKEv1 (i.e. IKEv1 cannot > >negotiate such SA for OPAQUE traffic). > Agreed, But 2401bis assumes use of IKEv2 in several instances, so I > don't see this as a problem. I was commenting that IKEv1 does not support it, thus there cannot be implementations supporting that format => if we mandate that now in the RFC2401bis then all implementations needs to add new code to support that. On the other hand there is (several?) implementations out which do partial reassembly, which means that it is already tested and working method of fixing that problem. > >If you have SA with port selectors between SGWs you cannot allow clear > >text non-first fragments without (partial) reassembly between SGWs. > > > >I.e. if you have rules > > > > A <-> B port 25 ESP with auth > > A <-> B non-first fragments in clear (i.e. bypass) > > > >Then attacker who sees or (or forces) the A to send fragmented packet > >can modify the non-first fragments regardless whether the SGW1 > >encrypted all the fragments of the packet from A, and the SGW2 will > >accept them based on the second policy rule. . > > I agree that the second rule would be a bad config choice. But I > disagree with the conclusion that one must do some form of reassembly > if fragments are allowed to bypass. We ought not impose this > requirement just to counter the bad effects of a bad config choice. If we do not add that requirements, then the problem is that if user uses vendor 1 IPsec with that configuration and which uses the partial reassembly it is secure, but if he switches to vendor 2 IPsec which do not do partial reassmebly his working policy suddenly comes insecure. That can be quite suprise to the adminstrator, and I think some kind of warning for the implementators should be in the text, if there is no requirement for partial reassembly. > >> 3. An implementation MAY choose to support some form of stateful > >> fragment checking for a tunnel mode SA with non-trivial port field > >> values (not ANY or OPAQUE). Implementations that will transmit > >> non-initial fragments on a tunnel mode SA that makes use of > >> non-trivial port selectors MUST notify a peer via an IKE payload > >> (TBD). > > > >Why? If the other end only supports the case #2, then it only needs to > >check that the SA which is used to carry the traffic has enough > >security to take care of the non-initial fragments. I.e. if the > >senders policy is use ESP AES for port 25, and the responders is use > >ESP AES for port 25, and any ESP stronger than 80-bits for non-inigial > >fragments, then it can safely accept the non-initial packets coming > >from the SA negotiated for the port 25. > > Since it appears that nothing short of reassembly will be safe for > v6, I think it is important to add this case. The "why?" was for "why do you need to notify that with IKE?". > Also, you and some > other folks have indicted that this approach seems reasonable for > many contexts, where very high speed > processing it not an issue. So, my reason for including #3 above is > to allow folks who want to do reassembly to do it, but not to impose > it as a burden for folks who don't feel that this strategy is > compatible with their system requirements/architecture. I think we do need case #3, but I do not think we need to negotiate it with notifications. I also think that case #2 and case #3 implementations can interoperate without any problems. I use port fragment to indicate the fragment which contains the port numbers, and non-port fragment to indicate the fragment which do not have port numbers. If you ONLY support #2, then you create non-port fragment SA, and you accept any non-port fragments from there. You MUST also accept any non-port fragments from any port fragment SA, provided that the security of that port fragment SA is "enough" compared to the non-port fragment SA. There is no need to do any partial-reassembly for any of the traffic regardless whether it was received from the non-port fragment SA or from port fragment SA. If you support #3, then you MUST send all non-port fragments to same port-fragment SA which was used for the fragment containing the port numbers of the packet. When you receive fragments from the any source, you do the partial-reassembly and verify that the packet is allowed by policy. If the fragment was received from the any other SA than which would carry the port-fragment of the packet, then you also need to verify that the security of that SA is "enough" compared to the port-fragment SA, which should have been used. This way you are always putting the fragments to the same SA which contained the port-fragment if you support #3 and to the non-port fragment SA if you only support #2. Note, that traffic for each direction may use different SAs, i.e. traffic from SGW 1 to 2 may use non-port fragment SA for non-port fragment, and traffic from SGW 2 to 1 may always use port-fragment SAs, and never send any traffic inside the non-port fragment SA. When you receive packet from any SA, you do the policy checks, and if your policy check is that any non-port fragment can go through, then there is no need to do partial reassembly at all (even in case #3). If you policy is that always verify the port selectors, then you need to do partial reassembly for all fragment regardless which SA (or bypass rule) was used to receive it. This mixing of case 2 and 3, assumes that you can have some kind of ordering of the SAs, saying that this security is enough for the non-port fragments. This can be also done so that the adminstrator creates the list of allowed algorithms for the non-port fragments (incoming), and if system only supports #2, then adminstrator needs to specify algorithm for the outgoing non-port fragments too. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Fri Mar 26 16:14:46 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2R0Ej2w067838; Fri, 26 Mar 2004 16:14:46 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06328 Thu, 25 Mar 2004 15:14:58 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc Message-Id: Date: Thu, 25 Mar 2004 10:43:14 -0800 To: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org (by way of Paul Hoffman / VPNC) Subject: I-D ACTION:draft-ietf-ipsec-esn-addendum-03.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Extended Sequence Number Addendum to IPsec DOI for ISAKMP Author(s) : S. Kent Filename : draft-ietf-ipsec-esn-addendum-03.txt Pages : 6 Date : 2004-2-16 The IP Security Authentication Header (AH) and Encapsulating Security Payload (ESP) protocols use a sequence number to detect replay. This document describes extensions to the Internet IP Security Domain of Interpretation (DOI) for the Internet Security Association and Key Management Protocol(ISAKMP). These extensions support negotiation of the use of traditional 32-bit sequence numbers or extended 64-bit sequence numbers for a particular AH or ESP security association. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esn-addendum-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esn-addendum-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-esn-addendum-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. [The following attachment must be fetched by mail. Command-click the URL below and send the resulting message to get the attachment.] [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] From owner-ipsec@lists.tislabs.com Fri Mar 26 16:17:52 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 i2R0HqTr067901; Fri, 26 Mar 2004 16:17:52 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05701 Thu, 25 Mar 2004 15:12:22 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <20040324203745.GX5868@binky.central.sun.com> References: <20040324203745.GX5868@binky.central.sun.com> Date: Thu, 25 Mar 2004 10:16:37 -0500 To: Nicolas Williams From: Stephen Kent Subject: Re: Remaining open issues for RFC-2401bis Cc: Charlie Kaufman , Tero Kivinen , ipsec@lists.tislabs.com Content-Type: multipart/alternative; boundary="============_-1131894696==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1131894696==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 2:37 PM -0600 3/24/04, Nicolas Williams wrote: >On Wed, Mar 24, 2004 at 11:05:20AM -0800, Charlie Kaufman wrote: >> We could add yet another ID Type option for UTF-8 string, but does >> anyone actually have a use for it? > >When the rfc822 subjectAltName is internationalized then the >corresponding ID should be also by extension (one hopes). If the matter >is addressed by adding additional cert extensions or by adding to the >general name CHOICE (why is it not marked extensible?) then we may need >a new ID type to go with it. > >Nico >-- Nico, GN is already extensible: GeneralName ::= CHOICE { otherName [0] OtherName, rfc822Name [1] IA5String, dNSName [2] IA5String, x400Address [3] ORAddress, directoryName [4] Name, ediPartyName [5] EDIPartyName, uniformResourceIdentifier [6] IA5String, iPAddress [7] OCTET STRING, registeredID [8] OBJECT IDENTIFIER } OtherName ::= SEQUENCE { type-id OBJECT IDENTIFIER, value [0] EXPLICIT ANY DEFINED BY type-id } otherName and registeredID provide all the extensibility you could ever want in terms of creating additional ID types. Steve --============_-1131894696==_ma============ Content-Type: text/html; charset="us-ascii" At 2:37 PM -0600 3/24/04, Nicolas Williams wrote: >On Wed, Mar 24, 2004 at 11:05:20AM -0800, Charlie Kaufman wrote: >> We could add yet another ID Type option for UTF-8 string, but does >> anyone actually have a use for it? > >When the rfc822 subjectAltName is internationalized then the >corresponding ID should be also by extension (one hopes). If the matter >is addressed by adding additional cert extensions or by adding to the >general name CHOICE (why is it not marked extensible?) then we may need >a new ID type to go with it. > >Nico >-- Nico, GN is already extensible: GeneralName ::= CHOICE { otherName [0] OtherName, rfc822Name [1] IA5String, dNSName [2] IA5String, x400Address [3] ORAddress, directoryName [4] Name, ediPartyName [5] EDIPartyName, uniformResourceIdentifier [6] IA5String, iPAddress [7] OCTET STRING, registeredID [8] OBJECT IDENTIFIER } OtherName ::= SEQUENCE { type-id OBJECT IDENTIFIER, value [0] EXPLICIT ANY DEFINED BY type-id } otherName and registeredID provide all the extensibility you could ever want in terms of creating additional ID types. Steve --============_-1131894696==_ma============-- From owner-ipsec@lists.tislabs.com Fri Mar 26 16:33:55 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2R0XtoM068602; Fri, 26 Mar 2004 16:33:55 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17824 Fri, 26 Mar 2004 18:55:33 -0500 (EST) Date: Fri, 26 Mar 2004 18:07:35 -0600 From: Nicolas Williams To: Stephen Kent Cc: Charlie Kaufman , Tero Kivinen , ipsec@lists.tislabs.com Subject: Re: Remaining open issues for RFC-2401bis Message-ID: <20040327000735.GD5868@binky.central.sun.com> Mail-Followup-To: Stephen Kent , Charlie Kaufman , Tero Kivinen , ipsec@lists.tislabs.com References: <20040324203745.GX5868@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Mar 25, 2004 at 10:16:37AM -0500, Stephen Kent wrote: > Nico, > > GN is already extensible: [...] *nod* Thanks, Nico -- From owner-ipsec@lists.tislabs.com Sat Mar 27 01:08:46 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2R98jfS050643; Sat, 27 Mar 2004 01:08:45 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA22825 Sat, 27 Mar 2004 03:23: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: <16485.15533.582898.949467@fireball.acr.fi> Date: Sat, 27 Mar 2004 10:34:53 +0200 From: Tero Kivinen To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: Re: Remaining open issues for RFC-2401bis In-Reply-To: References: <200403200415.i2K4FlQU007773@thunk.east.sun.com> <16480.9936.57483.798886@fireball.acr.fi> <16480.32863.476549.187521@fireball.acr.fi> <16482.57437.574350.440617@fireball.acr.fi> <16483.65081.442633.47762@fireball.acr.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 4 min X-Total-Time: 3 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > And my bad experience is that while I could create and remember a key > in the form of a pass phrase character string, I had to write down > the hex key I created and very carefully, manually enter it into each > system, which was error prone (despite my care), frustrating, and a > very poor use of my time. I have always configured those keys to my laptop, I do not enter them after the first time ever. My laptop then have that kind of information encrypted using the passphrase, and I only type in the passphrase when I need any of those 10-40 character long random keys. > I fear that you bring an implementer perspective to the problem, and > I bring a user perspective, and it is unfortunate that the two don't > overlap better :-) Anyways ID_KEY_ID is little bit different, I do not think people are going to type it in, it will be configured in to their system configuration once, and then used in the IKE. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Sun Mar 28 02:34:22 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2SAYLX2027163; Sun, 28 Mar 2004 02:34:21 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA08729 Sun, 28 Mar 2004 04:40:03 -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: <16486.40986.148372.423387@fireball.acr.fi> Date: Sun, 28 Mar 2004 12:51:22 +0300 From: Tero Kivinen To: David Wierbowski Cc: ipsec@lists.tislabs.com Subject: IDci and IDcr payloads with NAT Traversal In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 5 min X-Total-Time: 5 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David Wierbowski writes: > I have a question about the ID payloads exchanged in Quick Mode > when NAT Traversal is being utilized in the following scenario: > > HOST A ----> GW ----> GW's NAT ----> B's NAT ----> HOST B > 10.1.1.123 10.1.1.1 10.2.2.2 > > > Where: > - The private address for HOST A is 10.1.1.123 > - The private address for GW is 10.1.1.1 > - GW's NAT translates 10.1.1.1. to x.x.x.x > > - The private address for HOST B is 10.2.2.2 > - B's NAT translates 10.2.2.2 to y.y.y.y > > - GW is trying to create a phase 2 SA with HOST B > to protect traffic between HOST A and HOST B > > My questions are: > - is this a valid scenario? Yes, but the discovery of the y.y.y.y or x.x.x.x is outside the scope of the NAT-T. Lets assume that y.y.y.y is static, known and configured to the GW (if the GW is the initiator, as it seems in your case). > - if it is, then what IP addresses should be utilized in IDci and IDcr? The GW can use IDci = 10.1.1.123 and IDcr = 10.2.2.2, and it needs to know the 10.2.2.2 from the configuration. I.e. the GW's configuration would be: src = 10.1.1.123, dst = 10.2.2.2, enable Tunnel mode NAT-T to address y.y.y.y. If there would be overlaps (i.e. host B would also have IP-address of 10.1.1.123, then GW would need to do some kind of NAT for the packets from host B it sends to the host A). -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Mon Mar 29 16:17:46 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2U0HjjE085946; Mon, 29 Mar 2004 16:17:46 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11216 Mon, 29 Mar 2004 18:27:08 -0500 (EST) In-Reply-To: <16486.40986.148372.423387@fireball.acr.fi> Subject: Re: IDci and IDcr payloads with NAT Traversal To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: David Wierbowski Date: Mon, 29 Mar 2004 18:39:01 -0500 X-MIMETrack: Serialize by Router on D01MLL83/01/M/IBM(Build V652_03112004NP|March 11, 2004) at 03/29/2004 18:39:03 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> - if it is, then what IP addresses should be utilized in IDci and IDcr? > >The GW can use IDci = 10.1.1.123 and IDcr = 10.2.2.2, and it needs to >know the 10.2.2.2 from the configuration. I.e. the GW's configuration >would be: > > src = 10.1.1.123, dst = 10.2.2.2, > enable Tunnel mode NAT-T to address y.y.y.y. > >If there would be overlaps (i.e. host B would also have IP-address of >10.1.1.123, then GW would need to do some kind of NAT for the packets >from host B it sends to the host A). Perhaps I'm reading too much into your answer, but there seems to be some inconsistencies with IDci and IDcr when NAT Traversal is used. Let's consider a simpler example: HOST A ----> A's NAT ----> B's NAT ----> HOST B 10.1.1.1 10.2.2.2 Where: - The private address for HOST A is 10.1.1.1 - HOST A's NAT translates 10.1.1.1. to x.x.x.x - The private address for HOST B is 10.2.2.2 - B's NAT translates 10.2.2.2 to y.y.y.y (where y.y.y.y is static). There are two cases: 1) HOST A is trying create a phase 2 SA with HOST B to protect ALL traffic between HOST A and HOST B. 2) HOST A is trying create a phase 2 SA with HOST B to protect TCP traffic between HOST A and HOST B. In case 1 there is no need to exchange IDci and IDcr. They can be assumed to be the IP addresses of the IKE peers without any implied constraints on port or protocol. To me this would imply that both HOST A and HOST B have a different view of IDci and IDcr. - HOST A would think the IP address for IDci is 10.1.1.1 and for IDcr is y.y.y.y. - HOST B would think the IP address for IDci is x.x.x.x and for IDcr is 10.2.2.2 In case 2 ID payloads must be exchanged (since traffic is constrained to TCP traffic). Based on your previous answer I'm thinking you would expect both HOST A and HOST B to view IDci as 10.1.1.1 and IDcr as 10.2.2.2. Based on what the IDs would be if no ID payloads were sent I would expect that the IDs exchanged in case 2 should be the same as the IDs implied in case 1. This seems far more natural to me as it does not require HOST A to know HOST B's private address before the negotiation starts and it does not require HOST B to know HOST A's private address before the negotiation starts. I will admit that in the gateway case (my original case) that it seems as if knowledge of private addresses must be shared. I think that the "Negotiation of NAT-Traversal in IKE" drafts needs to include conventions for setting IDci and IDcr. Perhaps IDci and IDcr should always be exchanged when NAT is detected? My concern is that without establishing a convention for dealing with IDci and IDcr that we open ourselves up to possible interoperability issues. Dave Wierbowski z/OS Comm Server Developer Phone: Tie line: 620-4055 External: 607-429-4055 From owner-ipsec@lists.tislabs.com Mon Mar 29 19:02: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 i2U32F0I097855; Mon, 29 Mar 2004 19:02:15 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA27796 Mon, 29 Mar 2004 21:19:12 -0500 (EST) From: uri@lucent.com Date: Tue, 30 Mar 2004 10:13:02 +0800 To: ipsec@lists.tislabs.com Subject: Re: Msg reply 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 Mon Mar 29 19:02: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 i2U32GOL097856; Mon, 29 Mar 2004 19:02:16 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA27828 Mon, 29 Mar 2004 21:19:28 -0500 (EST) From: uri@lucent.com Date: Tue, 30 Mar 2004 10:22:22 +0800 To: ipsec@lists.tislabs.com Subject: Re: Incoming Fax 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 Mon Mar 29 19:25: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 i2U3Pahn099088; Mon, 29 Mar 2004 19:25:37 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA29846 Mon, 29 Mar 2004 21:40:29 -0500 (EST) From: uri@lucent.com Date: Tue, 30 Mar 2004 10:35:05 +0800 To: ipsec@lists.tislabs.com Subject: Forum notify 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 Mon Mar 29 21:38: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 i2U5c84R007392; Mon, 29 Mar 2004 21:38:08 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA13968 Mon, 29 Mar 2004 23:55:21 -0500 (EST) Date: Mon, 29 Mar 2004 19:10:21 -0500 (EST) From: shogunx To: ipsec@lists.tislabs.com Subject: Re: Msg reply In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk sleekfreak pirate broadcast serving up a portscan of this schmuck legend:~# nmap -sS -v 68.107.23.153 Starting nmap 3.27 ( www.insecure.org/nmap/ ) at 2004-03-29 23:22 EST Host ip68-107-23-153.sd.sd.cox.net (68.107.23.153) appears to be up ... good. Initiating SYN Stealth Scan against ip68-107-23-153.sd.sd.cox.net (68.107.23.153) at 23:22 Adding open port 389/tcp Adding open port 113/tcp Adding open port 1025/tcp Adding open port 5000/tcp Adding open port 1720/tcp The SYN Stealth Scan took 27 seconds to scan 1623 ports. Interesting ports on ip68-107-23-153.sd.sd.cox.net (68.107.23.153): (The 1605 ports scanned but not shown below are in state: closed) Port State Service 80/tcp filtered http 113/tcp open auth 135/tcp filtered loc-srv 136/tcp filtered profile 137/tcp filtered netbios-ns 138/tcp filtered netbios-dgm 139/tcp filtered netbios-ssn 389/tcp open ldap 445/tcp filtered microsoft-ds 593/tcp filtered http-rpc-epmap 1025/tcp open NFS-or-IIS 1433/tcp filtered ms-sql-s 1720/tcp open H.323/Q.931 4444/tcp filtered krb524 5000/tcp open UPnP 12345/tcp filtered NetBus 27374/tcp filtered subseven 31337/tcp filtered Elite Nmap run completed -- 1 IP address (1 host up) scanned in 33.127 seconds legend:~# the ip was pulled from the body. in this link: visible only in the packet headers, which leads to not a php file but a vb script, (drumroll for forensic analysis of the annoying) legend:~# cat *php Windows Update which calls a jpeg that is not a jpeg, but a virus. http://68.107.23.153:81/fcebwur.jpeg as evidenced by the following partial strings output: 8<@D 217.5.9 SOFTWARE\windirects .exe CLEANER3.E/ d3dupdate!PC c AVprot<9x MGRDI ON016 PF9X2 WNB? TDW= ICSSU }PUTY SET;k TIVIRUS-- C',FAS ErLL LOWPROTECTOaZ FP-WIN_TR!" OD6N 530[BYB HACK ,HTL zAMAy 1R SjJX KAVLI40 xIO- WRL-4 G2 S1 FG&Z HW32 DX L6l;S C"4^ EOuIos7 8Z7w3z KxLzU Arial image/bmp ygifjpeg gdiplus.dl* Startup hutdowo GetI Date: Tue, 30 Mar 2004 11:55:26 +0300 From: Tero Kivinen To: David Wierbowski Cc: ipsec@lists.tislabs.com Subject: Re: IDci and IDcr payloads with NAT Traversal In-Reply-To: References: <16486.40986.148372.423387@fireball.acr.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 17 min X-Total-Time: 16 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David Wierbowski writes: > Perhaps I'm reading too much into your answer, but there seems to be > some inconsistencies with IDci and IDcr when NAT Traversal is used. > Let's consider a simpler example: > > > HOST A ----> A's NAT ----> B's NAT ----> HOST B > 10.1.1.1 10.2.2.2 Note, as there is two NAT's there the initiastor MUST have specific configuration about the situation. I.e. it will have configuration saying if I want to reach host B (ip = 10.2.2.2) create NAT-T connection using the B's NAt address of y.y.y.y. > Where: > - The private address for HOST A is 10.1.1.1 > - HOST A's NAT translates 10.1.1.1. to x.x.x.x > > - The private address for HOST B is 10.2.2.2 > - B's NAT translates 10.2.2.2 to y.y.y.y (where y.y.y.y > is static). > > There are two cases: > 1) HOST A is trying create a phase 2 SA with HOST B > to protect ALL traffic between HOST A and HOST B. > > 2) HOST A is trying create a phase 2 SA with HOST B > to protect TCP traffic between HOST A and HOST B. > > In case 1 there is no need to exchange IDci and > IDcr. They can be assumed to be the IP addresses > of the IKE peers without any implied constraints on > port or protocol. Yes, for the transport mode. For the tunnel mode that really does not work, as both ends must agree on the IDs otherwise they will drop the packet during the tunnel exit checks. Lets assume tunnel mode for now, so both ends MUST send ID payloads. > To me this would imply that both > HOST A and HOST B have a different view of IDci and > IDcr. > - HOST A would think the IP address for IDci is 10.1.1.1 > and for IDcr is y.y.y.y. No, the HOST A will know from the configuration that it wanted to create SA with 10.2.2.2, and that was simply reached by sending packets to y.y.y.y, thus it will have IDci 10.1.1.1 and IDcr 10.2.2.2. It will also notice that it must send IDci and IDcr as they do not match the IP-addresses. > - HOST B would think the IP address for IDci is x.x.x.x > and for IDcr is 10.2.2.2 As HOST A will send the IDs the HOST B will know that the other end is 10.1.1.1, and not use implicit IP. > In case 2 ID payloads must be exchanged (since traffic is > constrained to TCP traffic). Based on your previous answer > I'm thinking you would expect both HOST A and HOST B to view > IDci as 10.1.1.1 and IDcr as 10.2.2.2. Yes. > Based on what the IDs would be if no ID payloads were sent > I would expect that the IDs exchanged in case 2 should be the > same as the IDs implied in case 1. This seems far more natural to > me as it does not require HOST A to know HOST B's private address > before the negotiation starts How does the implementation on HOST A start? The HOST A needs to have some configuration which initiates the connection. In normal case it is the packet send to the HOST B ip-address, which means that HOST A needs to know the HOST B's ip-address so it can send that packet, and after trig create the SA with correct host. > and it does not require HOST B to > know HOST A's private address before the negotiation starts. I HOST B does not need to know the private address of A, as it can see it from the ID payloads. > will admit that in the gateway case (my original case) that it > seems as if knowledge of private addresses must be shared. It is the same with this case as long as the tunnel mode is used. > I think that the "Negotiation of NAT-Traversal in IKE" drafts > needs to include conventions for setting IDci and IDcr. Perhaps > IDci and IDcr should always be exchanged when NAT is detected? For transport mode, you simply ignore the IP-addresses, and you can put anything you like there (or even use fqdn as IDci and IDcr, so you do not need to care about the IP-addresses). For tunnel mode you put the internal IP-addresses, because that is how the tunnel exit policy is negotiated. > My concern is that without establishing a convention for > dealing with IDci and IDcr that we open ourselves up to > possible interoperability issues. We talked about the IDci and IDcr earlier, but we really couldn't agree anything else than it depends on the scenario, and almost everything can be used. Some wanted to use FQDNs, some wanted to say we simply ignore all IP-numbers in tunnel mode, and some say we leave them out completely. I would have liked to add following text: "If negotiation is using transport mode, then received IP-addresses in the IDci and IDcr MUST be ignored, i.e. only port and protocol numbers are used. If negotiation is using tunnel mode, then IDci and IDcr MUST have IP-address used inside the tunnel i.e. IP-addresses used in the inner IP-header." -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Tue Mar 30 10:21:23 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 i2UILN1m034123; Tue, 30 Mar 2004 10:21:23 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22515 Tue, 30 Mar 2004 12:19:50 -0500 (EST) Message-Id: <200403301725.i2UHPECI009187@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: ipsec@lists.tislabs.com Subject: last few items for IKEv2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Mar 2004 12:25:14 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have added 3 to-do items for IKEv2, which you can find at https://roundup.machshav.com/ipsec/index If you think there are any other items missing, drop me a note --- I don't anticipate any, however. -Angelos From owner-ipsec@lists.tislabs.com Tue Mar 30 10:23:06 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UIN56i034196; Tue, 30 Mar 2004 10:23:06 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA20393 Tue, 30 Mar 2004 12:12:06 -0500 (EST) Message-Id: <200403301717.i2UHHhCI024980@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: ipsec@lists.tislabs.com Subject: Issue 83 will be withdrawn Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Mar 2004 12:17:43 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk https://roundup.machshav.com/ipsec/issue83 Issue 83 will be withdrawn and marked closed, unless someone disagrees by next Tuesday. -Angelos From owner-ipsec@lists.tislabs.com Tue Mar 30 18:41:16 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2V2fFkY073307; Tue, 30 Mar 2004 18:41:16 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA04868 Tue, 30 Mar 2004 20:48:17 -0500 (EST) Message-ID: <016c01c416c3$eb1d8270$861167c0@adithya> From: "Mohan Parthasarathy" To: "Tero Kivinen" , "Stephen Kent" Cc: , "russ housley" References: <16480.15529.482315.278735@fireball.acr.fi> Subject: Re: 2nd try Date: Tue, 30 Mar 2004 18:00:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, I am okay with your recommendations except for the second. > > > 2. All implementations MUST support tunnel mode SAs that will carry > >> only non-initial fragments, separate from non-fragmented packets and > >> initial fragments. The OPAQUE value will be used to specify port > >> field selectors for an SA to carry non-initial fragments. Specific > >> port selector values will be used to define SAs to carry initial > >> fragments and non-fragmented packets. This approach can be used if a > > > >If this is added, I think negotiating it in the IKE using the protocol > >44 (issue #81), is much cleaner way than the special port values. On > >the other hand that does not allow negotiation of the only TCP > >fragments. Perhaps the special port range is then better, i.e. in IKE > >v2 use port range of 65535-0 (= non-first fragment). > > I'm flexible on what the encoding should be for OPAQUE in IKEv2. > > > > user or administrator wants to create one or more tunnel mode SAs > >> between the same source/destination addresses that discriminate based > >> on port fields. These SAs MUST have non-trivial protocol selector > >> values, otherwise approach #1 above can be used. Receivers MUST > >> perform a minimum offset check on IPv4 (non-initial) fragments to > >> protect against overlapping fragment attacks when SAs of this type > >> are employed. Because such checks cannot be performed on IPv6 > >> non-initial fragments, users and administrators are advised that > >> carriage of such fragments may be dangerous, and implementers may > >> choose to NOT support such SAs for IPv6 traffic. Also, because a SA > > > >The beginning says this is MUST, and here you say implementators can > >choose not to support it. I think it shoud say it is MUST for IPv4 and > >MAY/SHOULD for IPv6 > > I intended to convey the notion that it is a MUST for v4, but not for > v6, for the reason cited. I'm comfortable with a MAY for v6. > Why is it a MUST for IPv4 ? You have just mentioned one case as a problematic case for IPv4 in the conclusion and given a solution as to how one may overcome this for IPv4. But the earlier sections in the document mentioned a few others which indicate that one could get into problems by configuring fragment-only SAs. If the implementation takes the conservative approach of keeping it simple and secure (Vs performance), isn't MUST a bit too strong ? thanks -mohan From owner-ipsec@lists.tislabs.com Wed Mar 31 03:13: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 i2VBDkJ0085833; Wed, 31 Mar 2004 03:13:46 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA07303 Wed, 31 Mar 2004 05:26:43 -0500 (EST) Message-ID: <1AB3D30B989BF141BBD5C70057B2EF7C0476A75D@eestqnt105.es.eu.ericsson.se> X-Sybari-Trust: d9ac57c1 2c4885b5 4dbf37a1 00000138 From: "David Mariblanca (ML/EEM)" To: "'ipsec@lists.tislabs.com'" Subject: clarification on IKEv2 with EAP Date: Wed, 31 Mar 2004 12:37:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 31 Mar 2004 10:38:18.0218 (UTC) FILETIME=[47A3CCA0:01C4170C] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am reading the IKEv2 i-d and I have a question in chapter 2.16, about the usage of EAP methods over IKEv2. The sequence diagram with the process is the following (copied from the paper): Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP } HDR, SK {EAP, AUTH} --> <-- HDR, SK {EAP, AUTH, SAr2, TSi, TSr } As written in the paper, the initiator omits the AUTH payload in message 3 when it wants to use EAP. Later on, it is written that when the whole EAP message is finished, the resultant shared secret (if exists) is used to generate the AUTH in messages 5 and 6. My question is: what about AUTH in message 4 ? How is it generated ? Thanks and best regards, David. From owner-ipsec@lists.tislabs.com Wed Mar 31 04:30:50 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VCUneN091967; Wed, 31 Mar 2004 04:30:50 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA20588 Wed, 31 Mar 2004 06:44:19 -0500 (EST) In-Reply-To: <1AB3D30B989BF141BBD5C70057B2EF7C0476A75D@eestqnt105.es.eu.ericsson.se> References: <1AB3D30B989BF141BBD5C70057B2EF7C0476A75D@eestqnt105.es.eu.ericsson.se> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4361DE32-830A-11D8-826C-000A95834BAA@checkpoint.com> Content-Transfer-Encoding: 7bit Cc: "'ipsec@lists.tislabs.com'" From: Yoav Nir Subject: Re: clarification on IKEv2 with EAP Date: Wed, 31 Mar 2004 13:55:11 +0200 To: "David Mariblanca (ML/EEM)" X-Mailer: Apple Mail (2.613) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Using the CERT or shared secret that are used to authenticate the Responder. This is meant to prove the identity of the Responder. The AUTH in the last message is signed (if possible) by the generated key. This is meant to prove that the Responder is known to the EAP server, rather than just mounting a MITM attack on unsuspecting Initiators. On Mar 31, 2004, at 1:37 PM, David Mariblanca (ML/EEM) wrote: > > Hi, > I am reading the IKEv2 i-d and I have a question in chapter 2.16, > about the usage of EAP methods over IKEv2. > The sequence diagram with the process is the following (copied from > the paper): > > Initiator Responder > ----------- ----------- > HDR, SAi1, KEi, Ni --> > > <-- HDR, SAr1, KEr, Nr, [CERTREQ] > > HDR, SK {IDi, [CERTREQ,] [IDr,] > SAi2, TSi, TSr} --> > > <-- HDR, SK {IDr, [CERT,] AUTH, > EAP } > > HDR, SK {EAP, AUTH} --> > > <-- HDR, SK {EAP, AUTH, > SAr2, TSi, TSr } > > > As written in the paper, the initiator omits the AUTH payload in > message 3 when it wants to use EAP. Later on, it is written that when > the whole EAP message is finished, the resultant shared secret (if > exists) is used to generate the AUTH in messages 5 and 6. My question > is: what about AUTH in message 4 ? How is it generated ? > > Thanks and best regards, > David. > > From owner-ipsec@lists.tislabs.com Wed Mar 31 05:47: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 i2VDleSZ097823; Wed, 31 Mar 2004 05:47:40 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03007 Wed, 31 Mar 2004 07:54:03 -0500 (EST) Message-ID: <1AB3D30B989BF141BBD5C70057B2EF7C0476A765@eestqnt105.es.eu.ericsson.se> X-Sybari-Trust: 19f4a1a6 2c4885b5 4dbf37a1 00000138 From: "David Mariblanca (ML/EEM)" To: "'Tschofenig Hannes'" , "'ipsec@lists.tislabs.com'" Subject: RE: clarification on IKEv2 with EAP Date: Wed, 31 Mar 2004 15:05:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 31 Mar 2004 13:06:46.0742 (UTC) FILETIME=[0588AF60:01C41721] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id HAA02976 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yoav, Hannes, thanks for your answers, that's what I wanted to confirm. BR, David. -----Original Message----- From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] Sent: miércoles, 31 de marzo de 2004 14:07 To: David Mariblanca (ML/EEM); 'ipsec@lists.tislabs.com' Subject: RE: clarification on IKEv2 with EAP hi david, the AUTH payload in message 4 (from the responder to the initiator) is not based on the keying material of an eap method authentication and key exchange run. hence, it most likely uses public key based authentication. ciao hannes > -----Original Message----- > From: David Mariblanca (ML/EEM) [mailto:david.mariblanca@ericsson.com] > Sent: Wednesday, March 31, 2004 12:37 PM > To: 'ipsec@lists.tislabs.com' > Subject: clarification on IKEv2 with EAP > > > > Hi, > I am reading the IKEv2 i-d and I have a question in chapter > 2.16, about the usage of EAP methods over IKEv2. > The sequence diagram with the process is the following > (copied from the paper): > > Initiator Responder > ----------- ----------- > HDR, SAi1, KEi, Ni --> > > <-- HDR, SAr1, KEr, Nr, [CERTREQ] > > HDR, SK {IDi, [CERTREQ,] [IDr,] > SAi2, TSi, TSr} --> > > <-- HDR, SK {IDr, [CERT,] AUTH, > EAP } > > HDR, SK {EAP, AUTH} --> > > <-- HDR, SK {EAP, AUTH, > SAr2, TSi, TSr } > > > As written in the paper, the initiator omits the AUTH payload > in message 3 when it wants to use EAP. Later on, it is > written that when the whole EAP message is finished, the > resultant shared secret (if exists) is used to generate the > AUTH in messages 5 and 6. My question is: what about AUTH in > message 4 ? How is it generated ? > > Thanks and best regards, > David. > > From owner-ipsec@lists.tislabs.com Wed Mar 31 13:26:34 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 i2VLQXJV035951; Wed, 31 Mar 2004 13:26:34 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23158 Wed, 31 Mar 2004 15:43:44 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.2.0.9.0.20040325174856.00abc208@email> References: <5.2.0.9.0.20040325174856.00abc208@email> Date: Wed, 31 Mar 2004 15:55:25 -0500 To: Mark Duffy From: Stephen Kent Subject: Re: 2nd try 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 7:10 PM -0500 3/25/04, Mark Duffy wrote: >Thanks, Steve. This gives a very nice summary of the issues! And, >I agree in general with the recommendations. Some specific >comments/questions embedded below... >--Mark > >At 09:05 PM 3/22/2004 -0500, Stephen Kent wrote: >... >>In 2401bis, we have explicitly said that it's OK to use transport >>mode in cases where the IPsec implementation is not the ultimate >>destination, e.g., between two SGs. In principle, this creates a >>new opportunity for outbound, plaintext fragments to be mapped to a >>transport mode SA for IPsec processing. However, in these new >>contexts in which a transport mode SA is now approved for use, it >>seems likely that we can continue to prohibit transmission of >>fragments, as seen by IPsec. For example, in an IP overlay network, >>packets being sent over transport mode SAs are IP-in-IP tunneled >>and thus have the necessary inner header to accommodate >>fragmentation prior to IPsec processing. When carried via a >>transport mode SA, IPsec would not examine the inner IP header for >>such traffic, and thus would not consider the packet to be a >>fragment. Thus it seems reasonable to retain the prohibition on >>carrying IPv4 fragments on transport mode SAs, even when the source >>or destination is an SG. > >My suggestion would be to simply say (e.g. in 2401bis sect 4.1): > >The use of transport mode by intermediate devices (e.g. SGs) is >permitted only when applied to packets whose source (for outbound >packets) or destination (for inbound packets) address is an address >belonging to the intermediate system itself. In these cases the >intermediate system is essentially acting as a host with respect to >those packets. I think some words along these lines can be used. >>...If we simplify the procedure employed to locate the next layer >>protocol in 2401bis, so that we treat ESP and AH as next layer >>protocols, then the notion of an encrypted next layer protocol >>field has vanished, and there is also no need to worry about >>encrypted port fields either. > >Yes please. In fact, I thought this was already decided. I.e. in >2401bis-01 section 4.4.2 Selectors: 'Next Layer Protocol: Obtained >from the IPv4 "Protocol" or ...' just wanted to reiterate and make sure we all agree. > >>1. All implementations MUST support tunnel mode SAs that pass >>traffic without regard to port field values. > >And must support bypass/drop rules that operate without regard to >port field values, no? we should group the bypass/drop requirements together. just as they were discussed separately in the memo. sorry that I didn't make this explicit. >... >>2. All implementations MUST support tunnel mode SAs that will carry >>only non-initial fragments, separate from non-fragmented packets >>and initial fragments. > >And must support bypass/drop rules that will match only non-initial >fragments, no? ibid. >... >>Also, because a SA of this sort will carry ALL non-initial >>fragments that match a specified source/destination address pair >>and protocol value, users and administrators are advised to protect >>such traffic using ESP (with integrity) and the "strongest" >>integrity and encryption algorithms available at both peers. >>(Determination of the "strongest" algorithms requires imposing a >>total ordering of the available algorithms, a local determination >>at the discretion of the initiator of the SA.) > >Isn't it also at the discretion of the responder? in the sense that a responder must agree to SA parameters proposed by the initiator. The initiator must propose only what he considers to acceptable algorithms given the context. >>3. An implementation MAY choose to support some form of stateful >>fragment checking for a tunnel mode SA with non-trivial port field >>values (not ANY or OPAQUE). Implementations that will transmit >>non-initial fragments on a tunnel mode SA that makes use of >>non-trivial port selectors MUST notify a peer via an IKE payload >>(TBD). The peer MUST reject this proposal if it will not accept >>non-initial fragments in this context. If an implementation does >>not successfully negotiate transmission of non-initial fragments >>for such an SA, it MUST NOT send such fragments over the SA. This >>standard does not specify how peers will deal with such fragments, >>e.g., via reassembly or other means, at either sender or receiver. >>However, a receiver MUST drop non-initial fragments that arrive on >>an SA with non-trivial port selector values unless this feature has >>been negotiated. > >This wording does not preclude an implementation from negotiating >this feature but then failing to do the expected checking on >received packets. Should it state that if the feature has been >negotiated, the receiver MUST NOT accept non-initial fragments >without verifying that they comply with the security policy called >for for the overall packet? good point. we'll add that note. >Also, I think that #3 also should state that a receiver that has >negotiated the feature must not accept non-initial fragments for >bypass without verifying that they comply with the security policy >called for for the overall packet. we can say that too. but it is implied by the required, normal SA receiver processing rules. >------------ > >One final issue, does port selector ANY encompass OPAQUE? To my >sensibilities ANY means any value in the range (e.g. 0..65535) and >the port values of an opaque packet are surely in this range even if >we don't know them. > >If there is some value (what is it?) in having an ANY concept that >does not include OPAQUE, it should be clearly named e.g. >ANY_NONOPAQUE. > >Here is at least one specific reason why ANY *should* include >OPAQUE. (Yes, I realize that this is an arcane case.) For approach >#1 we use port-blind policies. If ANY includes opaque then the port >selectors are simply: > > source port = ANY, dest port = ANY. > >But if ANY and OPAQUE are disjoint then (here's where it gets arcane >;-) it is possible that a an initial fragment will come along that >contains the source port but not the dest port. The policy for >approach #1 to cover this case would need to be: > > source port = ANY, dest port = ANY >or source port = ANY, dest port = OPAQUE >or source port = OPAQUE, dest port = OPAQUE > >What administrator is going to think to provision that? The memo says that ANY and OPAQUE are disjoint and it explicitly said that you would need to define an SA that used BOTH ANY and OPAQUE port selectors if you wanted a single SA for all traffic of this sort. Nonetheless, I think you are right, i.e., we can redefine ANY to encompass OPAQUE and still be OK. OPAQUE must be kept separate to allow us to have a fragment only SA when we have port-specific SAs, but defining ANY the way you suggest makes it easier to define an SA that carries all traffic (non-fragmented, as well as initial and non-initial fragments) that otherwise matches the other selectors, when we want to not be port-specific. This makes it easier for admins too, as you note. Is also is more consistent with the convention I proposed for protocols that have no ports (or only on port), since I had suggested using ANY as the port field selector value for such protocols. Steve From owner-ipsec@lists.tislabs.com Wed Mar 31 13:29:34 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 i2VLTXIb036093; Wed, 31 Mar 2004 13:29:33 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23164 Wed, 31 Mar 2004 15:43:46 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <016c01c416c3$eb1d8270$861167c0@adithya> References: <16480.15529.482315.278735@fireball.acr.fi> <016c01c416c3$eb1d8270$861167c0@adithya> Date: Wed, 31 Mar 2004 15:20:27 -0500 To: "Mohan Parthasarathy" From: Stephen Kent Subject: Re: 2nd try 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 6:00 PM -0800 3/30/04, Mohan Parthasarathy wrote: > Steve, > >I am okay with your recommendations except for the second. > > > > > > > 2. All implementations MUST support tunnel mode SAs that will carry >> >> only non-initial fragments, separate from non-fragmented packets and >> >> initial fragments. The OPAQUE value will be used to specify port >> >> field selectors for an SA to carry non-initial fragments. Specific >> >> port selector values will be used to define SAs to carry initial >> >> fragments and non-fragmented packets. This approach can be used if a >> > >> >If this is added, I think negotiating it in the IKE using the protocol >> >44 (issue #81), is much cleaner way than the special port values. On >> >the other hand that does not allow negotiation of the only TCP >> >fragments. Perhaps the special port range is then better, i.e. in IKE >> >v2 use port range of 65535-0 (= non-first fragment). >> >> I'm flexible on what the encoding should be for OPAQUE in IKEv2. >> >> > > user or administrator wants to create one or more tunnel mode SAs >> >> between the same source/destination addresses that discriminate based >> >> on port fields. These SAs MUST have non-trivial protocol selector >> >> values, otherwise approach #1 above can be used. Receivers MUST >> >> perform a minimum offset check on IPv4 (non-initial) fragments to >> >> protect against overlapping fragment attacks when SAs of this type >> >> are employed. Because such checks cannot be performed on IPv6 >> >> non-initial fragments, users and administrators are advised that >> >> carriage of such fragments may be dangerous, and implementers may >> >> choose to NOT support such SAs for IPv6 traffic. Also, because a SA >> > >> >The beginning says this is MUST, and here you say implementators can >> >choose not to support it. I think it shoud say it is MUST for IPv4 and >> >MAY/SHOULD for IPv6 >> >> I intended to convey the notion that it is a MUST for v4, but not for >> v6, for the reason cited. I'm comfortable with a MAY for v6. >> >Why is it a MUST for IPv4 ? We would like to have at least one, mandatory way for two IPsec peers to carry fragments via SAs, when port-specific SAs are employed, hence we need at least one approach that is a MUST. The third recommendation would satisfy the requirement, but the reassembly process may be a hardship for very high speed implementations. That's why I suggested this option as a MAY. The reason for making the second recommendation the MUST, for IPv4, is because it satisfies the requirement, and does not seem likely to impose performance penalties. It is only a MAY/SHOULD for IPv6 because there are security problems for v6 when dealing with fragments w/o reassembly, as noted in the analysis. >You have just mentioned one case as a problematic >case for IPv4 in the conclusion and given a solution as to how one >may overcome >this for IPv4. I noted a problem for v6 under recommendation #2, not for v4. >But the earlier sections in the document mentioned a few others >which indicate that one could get into problems by configuring >fragment-only SAs. There have been discussions about possible problems for IPv4 fragment handling w/o reassembly, but I think my analysis dealt with all of these concerns and thus I feel comfortable recommending that approach. >If the implementation takes the conservative approach of keeping it >simple and secure >(Vs performance), isn't MUST a bit too strong ? Reassembly or reassmebly-like state tracking is not simple, although if properly implemented it is secure for both IPv4 and v6. That is its major benefit, in my view. Steve