From owner-ipsec@lists.tislabs.com Sat Nov 1 05:35:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1DZ3kT010496; Sat, 1 Nov 2003 05:35:04 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA19701 Sat, 1 Nov 2003 07:44:37 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16291.44184.656748.314272@ryijy.hel.fi.ssh.com> Date: Sat, 1 Nov 2003 14:52:40 +0200 From: Tero Kivinen To: Tom Hu Cc: latten@austin.ibm.com, ipsec@lists.tislabs.com Subject: Re: question about draft-ietf-ipsec-nat-t-ike-07 In-Reply-To: <3FA2A893.87A67635@cisco.com> References: <200310291953.h9TJriia017231@faith.austin.ibm.com> <16288.53766.952607.215763@ryijy.hel.fi.ssh.com> <3FA1B09E.F4CB6E86@cisco.com> <16290.14758.563376.383730@ryijy.hel.fi.ssh.com> <3FA2A893.87A67635@cisco.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 5 min X-Total-Time: 8 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tom Hu writes: > 1.4 The INFORMATIONAL Exchange > At various points during the operation of an IKE_SA, peers may desire > to convey control messages to each other regarding errors or > notifications of certain events. To accomplish this IKE defines an > INFORMATIONAL exchange. INFORMATIONAL exchanges MAY ONLY occur after > the initial exchanges and are cryptographically protected with the > negotiated keys. > > Here initial exchange includes 1 to 4 messages. Informational exchange != Notification payload. Any exchange (IKE_SA_INIT, IKE_AUTH, CREATE_CHILD_SA and INFORMATIONAL) can have notifications in them. For example most error messages are replies to the IKE_SA_INIT or IKE_AUTH exchanges, not separate INFORMATIONAL exchange. Also there are lots of status notifications that are put in the IKE_SA_INIT, IKE_AUTH or CREATE_CHILD_SA exchanges. Examples of those are SET_WINDOW_SIZE, ADDITIONAL_TS_POSSIBLE, IPCOMP_SUPPORTED, NAT_DETECTION_*_IP, COOKIE, USE_TRANSPORT_MODE etc. Informational exchange is only used when you do not have any other exchange where you could put the notification... > And by the way, IKE_SA_INIT message does not have AUTH payload. True, but AUTH payload does not have anything to do with being cryptographically protected. In IKEv2 draft the packet is cryptographically protected if its contents is inside the Encrypted payload. > AUTH payload is sending at #3 and #4 messages. And that AUTH payload is inside the encrypted payload, which protects those messages. Messages #1 and #2 are authenticated because they are included in the AUTH message calculations. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Sat Nov 1 13:11:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1LBUkT026774; Sat, 1 Nov 2003 13:11:30 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21774 Sat, 1 Nov 2003 15:29:01 -0500 (EST) Message-Id: <5.2.1.1.0.20031101012956.056a44f0@dfintra.f-secure.com> X-Sender: joern@dfintra.f-secure.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 01 Nov 2003 01:41:24 +0100 To: "Casey Carr" , "Ipsec@Lists. Tislabs. Com" From: Joern Sierwald Subject: Re: Aggressive/Main mode proposal In-Reply-To: <006401c39fef$551893a0$b501a8c0@cipheroptics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id TAA16416 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 15:41 31.10.2003 -0500, Casey Carr wrote: >Can anyone clear up an IKE proposal issue for e? If two secure gateways >are configured with the same KE proposal parameters with the exception >that one is configured for main ode and the other is configured for >aggressive mode, can a valid IKE proposal be negotiated? Im assuming that >regardless of which SG nitiates, the result would be a main mode Phase 1. >Correct? Thanks, Casey Not at all, I'm afraid. The result is implementation-dependent. Several things could happen: (1) The responder only accepts its configured mode. With this implementation, the negotiation will fails, regardless which SG initiates. (2) The responder doesn't care about the mode, it accepts both. Both directions would work (3) The responder accepts both directions, but with limitations regarding the initiators ID. Our own software (VPN+) will always accept aggressive mode, but for main mode the responder will do a policy lookup with just the IP address. Thus, if the policy only says "let C=DE, CN=Joern in with RSA, AES, and group 14", main mode will not work, because the responder would have to choose the group before it receives the ID. (4) The implementation might regard one of the modes to be "more secure" and the responder might allow a config mismatch due to that reason. Only one direction would work. (5) Some implementations support only one of the two modes. Jörn From owner-ipsec@lists.tislabs.com Sun Nov 2 07:06:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA2F6YkT025329; Sun, 2 Nov 2003 07:06:34 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26191 Sun, 2 Nov 2003 09:17:23 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16293.5078.518969.254292@ryijy.hel.fi.ssh.com> Date: Sun, 2 Nov 2003 16:25:26 +0200 From: Tero Kivinen To: Stephen Kent Cc: "Mike Taylor" , Subject: RE: I-D ACTION:draft-ietf-ipsec-rfc2401bis-00.txt In-Reply-To: References: X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 18 min X-Total-Time: 21 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > In Ikev1, you could establish two SAs at once, for the special case > of AH + ESP. IKEv2 removed this special case feature, so now two SAs > must be negotiated separately. IKEv2 did not remove that feature. You can still negotiate AH + ESP with one CREATE_CHILD_SA exchange. In IKEv2 the SA payload contains list of Proposal payloads. Each proposal payload contains proposal number, protocol ID, SPI and list of transforms. If two proposals have asme proposal number they create the "protocol1 AND protocol2" proposal, i.e AH and ESP. Transforms consists of transform type and transform ID (+ possible attributes). Example of transform list is Encryption algorithm = AES_CBC Integrity Algorithm = AUTH_HMAC_SHA1_96 I.e the final SA payload is: SA: Proposal # 1 Protocol-ID = ESP (1) SPI-size = 4 # of Transforms = 1 SPI = 0x12345678 Transforms: Transform Type = Encryption Algorithm (1) Transform ID = AES_CBC (12) Proposal # 1 Protocol-ID = AH (2) SPI-size = 4 # of Transforms = 1 SPI = 0x12345679 Transforms: Transform Type = Integrity Algorithm (3) Transform ID = AUTH_HMAC_SHA1_96 (2) Proposal # 2 Protocol-ID = ESP (1) SPI-size = 4 # of Transforms = 2 SPI = 0x1234567a Transforms: Transform Type = Encryption Algorithm (1) Transform ID = AES_CBC (12) Transform Type = Integrity Algorithm (3) Transform ID = AUTH_HMAC_SHA1_96 (2) and that proposes either ESP(AES_CBC) AND AH(SHA1) or ESP(AES_CBC with SHA1). -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Nov 3 08:33:02 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3GX1kT040204; Mon, 3 Nov 2003 08:33:02 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05606 Mon, 3 Nov 2003 10:11:34 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 3 Nov 2003 10:18:14 -0500 To: "Mike Taylor" From: Stephen Kent Subject: RE: I-D ACTION:draft-ietf-ipsec-rfc2401bis-00.txt 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 what you're saying here is that there will no longer be >separate inbound and outbound policy databases? yes, that's what my revised processing model message said. >Then much more >of 2401bis needs major rewriting. yes, we know, but Ted & Barbara wanted to have a version distributed to show what has been agreed to and updated so far. >Is this being imposed by changes >to IKE in IKEv2? no. it's being done because if we think of the inbound and outbound databases as completely independent, we make it easier for folks to make errors in configuring them. >I am finding having the separate policies for >inbound and outbound very useful for debugging during development. you still have to support separate inbound and outbound selector sets. However, you need to pair them. >And I can even see an argument for one-way policies in general, >for example, perhaps some kind of remote sensor. then the part of the entry that deals with traffic in the other direction could be NULL. >Who knows? >And of course, pragmatically its far too late to change my current >design now. I have separate policies. But I'm not really doing >an IPsec v3 implementation anyway. I was only looking to 2401bis >to clarify some of the confusion I found in 2401. Mike, the processing model does not mandate in detail how you implement the SPD. It provides a nominal model that your implementation should match, from an external perspective, with regard to management interfaces, etc. > >> >> >Section 4.4.2 Selectors >> > >> > Still requires that both SPD entries and SAs carry selectors, >> > and still requires separate SAD entries for ESP and AH, so that >> > if I have a incoming datagram which must be processed through both >> > AH and ESP then I can't really make any use of the selectors in the >> > AH SA because until the datagram has also gone through ESP the >> > selectors are opaque. From a practical implementation standpoint >> > I certainly don't want to waste memory (in my embedded system) >> > on information I can't use. >> >> Each SPD entry must contain selector values because that is how one >> searches for the right SPD entry. > >If SAs all have selectors one can envision having an outbound SA >cache and 1st searching the SA cache before bothering to look at >the SPD. After all, this would generally reduce the amount of >time wasted looking at the SPD which is primarily used to create >new SAs but presumably the creation of new SAs occurs far less frequently >than the transmission of a datagram in most systems. > >Am I missing something? yes, you are. unless one decorrelates the SPD, one cannot cache entries. 2401 did not discuss decorrelation and thus did not discuss caching, whereas 2401bis discusses both. > >> The SAD contains values for extant >> SAs, and we put selector values there because we need to check >> inbound traffic to ensure consistency with the selector values >> negotiated during SA establishment. > >But in my implementation I have back pointers from all SAs to >the policy that spawned them. So when I'm done processing an >inbound datagram through an SA the SA knows where to find the >policy that contains the selectors. So unless this inheritance of >selectors by SAs provides some required functionality from a blackbox >perspective (improved security and/or interoperability) that cannot >be achieved just as well with multiple policies it seems like one >could just as well only have selectors in SPD entries and none in >SAs, thereby possibly saving significant RAM for a small system >especially with 128-bit IPv6 addresses. as noted above, you are free to implement these functions in any fashion you wish, so long as the externally visible operation matches what the model describes. > >> >> In Ikev1, you could establish two SAs at once, for the special case >> of AH + ESP. IKEv2 removed this special case feature, so now two SAs >> must be negotiated separately. the only way you can nest the two SAs, > > and thus apply both AH and ESP, is via creation and processing for >> both SAs. As noted in the revised processing model, nesting requires >> careful configuration of both the SPD and the forwarding tables, to >> cause the traffic to pass through IPsec processing twice, for both >> outbound and inbound processing. >> >> Frankly, the question I would ask is why (when) do you plan to use >> both AH & ESP? Given the current capabilities of ESP, we don't tend >> to see a need to use both. > >Well, the problem from my perspective is that 2401 has so much >implementation >detail that it is very hard for me remain clear on what are requirements >and what are just suggestions. For example, see 4.5 Basic Combinations >of Security Associations. It shows the case of ESP in AH in transport mode >and begins with the sentence: > > "This section describes four examples of combinations for security > associations that MUST be supported by compliant IPsec hosts or > security gateways." > >Aside from that, I've seen other references to the fact that since ESP >doesn't authenticate the IP header AH may still be useful for that purpose. >I'm a programmer, not an IT person. I don't really know what people think >is useful on the real world and I don't have much marketing input. So >I try to conform to the RFC's requirements. If ESP in AH isn't useful >then the 2401bis should certainly make it clear that it isn't a required >basic SA combination. A MUST is a pretty straightforward indication of a requirement, both here and in ALL IETF RFCs. Your cited text from 2401. We're writing 2401bis now. If you want to be compliant with 2401, then you need to support the combination of AH + ESP. For 2401bis, you will NOT have to support this combination. If you have tracked the various discussion topics on the list, then you will note that we have proposed simplifying IPsec in 2401bis, removing support for certain features that were previously mandated. > >> >> > >> > And of course the RFC mandates that that after processing >> > through the SAs the selectors in the datagram must be >> matched against >> > the SPD entry: >> > >> > 5. IP Traffic Processing >> > >> > As mentioned in Section 4.4.1 "The Security Policy >> Database (SPD)", >> > the SPD must be consulted during the processing of all traffic >> > (INBOUND and OUTBOUND), including non-IPsec traffic. >> > >> > Why, if I really have the selectors stored in SAs, would I do this >> > on the inbound side in particular? >> >> this text is left over from 2401 and needs to be updated. it should >> now refer to SPD caches > >SPD caches? Another implementation detail? Not exactly. As noted above, one cannot cache an SPD entry, unless the entry does not overlap with any other entry. Remember that the SPD is an order list and that entries may (and often do) overlap. So, taking an entry out of the SPD and putting it in a cache will not work, in general, unless the SPD is first decorrelated. Steve From owner-ipsec@lists.tislabs.com Mon Nov 3 14:34:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA3MYgkT054583; Mon, 3 Nov 2003 14:34:43 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08566 Mon, 3 Nov 2003 16:45:57 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f Message-ID: <16294.52860.518239.410976@ryijy.hel.fi.ssh.com> Date: Mon, 3 Nov 2003 23:54:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: mipv6@ietf.org, mipv4@ietf.org, ipsec@lists.tislabs.com, mobike@machshav.com, hipsec@honor.trusecure.com Subject: IKEv2 Mobility and Multihoming BOF Tue, Nov 11, 1700-1800 X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f X-Mailer: VM 7.07 under Emacs 20.7.1 X-Edit-Time: 1 min X-Total-Time: 0 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There has been some interest in the IPsec working group to add features to IKEv2 to support roaming, mobility, and multihoming. The IPsec working group decided that those issues are not included as part of the current IKEv2 core protocol, but instead they are handled in separate documents and/or working group. The mobility features are need to support Mobile IP efficiently, and are also used in the cases where devices perform roaming (move around and the IP address changes), and they do want to keep the existing IKE and IPsec SAs in place even when the IP address changes without full rekeying. The features needed include way to update the IKEv2 SA and IPsec SA endpoint addresses without need of the rekeying the SAs, and also authenticating those changes (return routability or similar). Another feature needed is to support multihoming and support having multiple IP addresses tied to one IKEv2 SA and IPsec SA. This support is needed by routers having multiple interfaces, when using SCTP, and in cases where for example mobile device might have multiple different connections to the internet (i.e for example WLAN and GPRS). Some way to authenticate those multiple IP addresses is also needed. The features should then be used by the Mobile IP, HIP, etc working groups as building blocks to create their final protocols, but some of the features can immediately be used in the IPsec VPNs too (client roaming in VPN case, SCTP, multihoming support). The BOF is currently scheduled for Tuesday, November 11, 2003, at 1700-1800. The BOF have some kind of web pages at http://mobike.kivinen.iki.fi/index.html. The web pages have agenda for the meeting, proposed charter and basic introduction to the problem. The BOF mailing list: General Discussion: mobike@machshav.com To subscribe: mobike-request@machshav.com Archive and general information: https://www.machshav.com/mailman/listinfo/mobike The MOBIKE BOF's goal is to verify that we have enough interest to define mobility and multihoming extensions to the current IKEv2 protocol. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Nov 3 17:02:52 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA412pkT059696; Mon, 3 Nov 2003 17:02:51 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA09522 Mon, 3 Nov 2003 19:20:31 -0500 (EST) To: Russ Housley , saag@mit.edu cc: ipsec@lists.tislabs.com, iesg@ietf.org, design@lists.freeswan.org Subject: IKE and Certicom "IP Rights" In-reply-to: Your message of "Fri, 31 Oct 2003 15:29:27 EST." <5.2.0.9.2.20031031152519.0449f590@mail.binhost.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 03 Nov 2003 19:23:40 -0500 Message-ID: <5090.1067905420@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Russ" == Russ Housley writes: Russ> Dear IPsec Working Group: Russ> I just got this note, which is a follow-up to a query that I sent to Russ> Certicom in July 2003. Thank you for posting this. But, this part makes no sense. Certicom> and other IETF standards using MODP Groups. The applicable Certicom> patents include, but are not limited to, US Patents #5,933,504, Certicom> #6,563,928, #6,078,667, #6,178,507, #6,195,433, US Patent Certicom> Application Publications #2001/0014153, #2002/0090085, and PCT Certicom> Application #WO 00/01109, and corresponding foreign applications. Certicom> limited field of use of MODP public key cryptography Certicom> implemented using the well known Groups 1 and 2 as defined in Certicom> RFC 2409. Certicom will send the IETF terms of the royalty Certicom> free license and will post this our web site shortly. This is a silly offer. Certicom IPR people don't understand their own patents and do not understand IKE, or cryptography at all it seems to me. That he goes on to suggest that we use ECC instead, for which they have even further patents is even more suspect. I didn't look up all the patents, but the first one, 5,933,504, is about how to generate and check the numbers. We discussed this last July in Vienna. This patent ought to apply to all IETF systems that use DH. No IKE implementations use the described mechanisms. IKE doesn't do that. It does DH. To make DH interoperate we have to agree on a common base, "g", which should have certain properties. Once the "g" has been generated and checked, we are done. So, from the IETF's point of view the only person/group that needs to license this patent is the document editor! The only other people that would need to license this would be who didn't trust the document editor and/or the IETF. Certicom "offer"s us MODP groups 1 and 2. Wow. Will they offer to license PI to me next? they are NUMBERS. This is nonsense from them. ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP6bxioqHRg3pndX9AQHJRgQAksDiCqLRsPVM4mOMB58+5p1pvUnFbs71 Oxst6jRLoyLApjbydWBHOGLzpiLOKPgTCpn2+rTs+UMBcNIARWhcqIa/wIcBoKNk 6bmpUAyfBMfJ5eFm58cK7X4vUzmZJUvoZqNsFaYhZYOjF6yLlMHKGTHi0DMPtQ/T NK7gFcrPpm4= =ZHqT -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Nov 3 22:01:13 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA461DkT069725; Mon, 3 Nov 2003 22:01:13 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA11156 Tue, 4 Nov 2003 00:16:13 -0500 (EST) Message-Id: <5.2.0.9.0.20031103234135.00aca368@localhost> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 04 Nov 2003 00:24:14 -0500 To: Stephen Kent , ipsec@lists.tislabs.com From: Mark Duffy Subject: Re: revised processing model, take II In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, I have a couple of questions on the processing model description. Sorry to be so long in getting these questions out. --Thanks, Mark At 12:02 PM 10/17/2003 -0400, Stephen Kent wrote: >Revised IPsec subscriber traffic processing model (take II) ... >However, we split each SPD into three pieces: one is applied to all >traffic that is to be subject to IPsec protection (SPD-S), one applied to >all outbound traffic that is to be bypassed or discarded (SPD-O), and one >applied to inbound traffic that will be bypassed or discarded (SPD-I). If >an IPsec implementation supports only one SPD, then the SPD consists of >all three parts. If multiple SPDs are supported, some of them may be >partial, e.g., some SPDs may contain only SPD-I entries, to control >inbound bypassed traffic on a per-interface basis. It's not clear to me why this split of the SPD into 3 parts is introduced. SPD-S seems to be consulted anyway whenever SPD-O is consulted. Perhaps the split is to allow SPD-I to be consulted without having to consult SPD-S? I'm not sure this is worth the complexity added. The fact that SPD-S contains rules for both inbound and outbound traffic, but SPD-I and SPD-O each contain rules for only one direction only adds to the difficulty of understanding this, I think. Also, do these 3 SPD pieces consist of ordered sets of rules, or are they presumed to be decorrelated at this point? If not decorrelated it would seem to be difficult to separate them, as they might be inter-ordered. Re the last sentence above, why might SPDs be partial in a multi-SPD system, while they wouldn't be in a single-SPD system? I.e. why would some interfaces have only SPD-I and not SPD-S or SPD-O? ... >The search process also is ambiguous as currently defined. To simplify >the process, and to allow for very fast SA lookups (for SG/BITS/BITW), we >introduce the notion of an SPD cache for all outbound traffic. There is >nominally one cache per SPD. Since SPD entries may overlap, one cannot >safely cache these entries in general. Simple caching might result in a >match against a cache entry whereas a search of the SPD would have >resulted in a match against a different entry. But, if we decorrelate the SPD, Does the model assume that there is an ordered SPD (like in 2401), and then a decorrelated version generated from it? Or is the SPD, wherever mentioned in the new model, assumed to be decorrelated? If so, the decorrelation should be mentioned earlier in the description. >then the resulting entries can safely be cached, and each cached entry >will map to an SA, or indicate that matching traffic should be bypassed or >discarded, appropriately. ... >Inbound Traffic Processing (black-to-red) > >Inbound processing is somewhat different, because of the use of SPIs to >map IPsec traffic to SAs. The inbound SPD cache is applied only to >bypassed or discarded traffic, and the inbound SPP lookup is applied only >to the SPD-I part of an SPD. That doesn't seem quite right. Shouldn't the inbound SPD cache be applied to all traffic received without IPsec protection, and using both the SPD-S and SPD-I? Otherwise it will not catch packets that should have been protected but weren't. Either that, or (better yet) it should state that any packet not matching any decorrelated entry in SPD-I must be discarded. ... >2b. If the packet is not addressed to the device, lookup the packet header >in the (appropriate) SPD-I cache. If there is a match and the packet is to >be discarded or bypassed, do so. If there is no cache match, lookup the >packet in the corresponding SPD-I and create a cache entry as appropriate. >(No SAs are created in response to receipt of a packet that requires >IPsec; only bypass or discard entries can be created this way.) same as above, should state that a packet not matching an SPD-I rule must be discarded. From owner-ipsec@lists.tislabs.com Tue Nov 4 07:52:24 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4FqNkT060559; Tue, 4 Nov 2003 07:52:23 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15360 Tue, 4 Nov 2003 10:07:57 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.2.0.9.0.20031103234135.00aca368@localhost> References: <5.2.0.9.0.20031103234135.00aca368@localhost> Date: Tue, 4 Nov 2003 10:13:43 -0500 To: Mark Duffy From: Stephen Kent Subject: Re: revised processing model, take II Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 0:24 -0500 11/4/03, Mark Duffy wrote: >Hi Steve, I have a couple of questions on the processing model description. >Sorry to be so long in getting these questions out. --Thanks, Mark > > >At 12:02 PM 10/17/2003 -0400, Stephen Kent wrote: >>Revised IPsec subscriber traffic processing model (take II) > >... >>However, we split each SPD into three pieces: one is applied to all >>traffic that is to be subject to IPsec protection (SPD-S), one >>applied to all outbound traffic that is to be bypassed or discarded >>(SPD-O), and one applied to inbound traffic that will be bypassed >>or discarded (SPD-I). If an IPsec implementation supports only one >>SPD, then the SPD consists of all three parts. If multiple SPDs are >>supported, some of them may be partial, e.g., some SPDs may contain >>only SPD-I entries, to control inbound bypassed traffic on a >>per-interface basis. > >It's not clear to me why this split of the SPD into 3 parts is >introduced. SPD-S seems to be consulted anyway whenever SPD-O is >consulted. Perhaps the split is to allow SPD-I to be consulted >without having to consult SPD-S? yes, that was the primary reason I chose to describe the SPD as being composed of three parts. >I'm not sure this is worth the complexity added. The fact that >SPD-S contains rules for both inbound and outbound traffic, but >SPD-I and SPD-O each contain rules for only one direction only adds >to the difficulty of understanding this, I think. Also, do these 3 >SPD pieces consist of ordered sets of rules, or are they presumed to >be decorrelated at this point? If not decorrelated it would seem to >be difficult to separate them, as they might be inter-ordered. yes, the assumption is that they have been decorrelated. also, the split is primarily for purposes of exposition. >Re the last sentence above, why might SPDs be partial in a multi-SPD >system, while they wouldn't be in a single-SPD system? I.e. why >would some interfaces have only SPD-I and not SPD-S or SPD-O? if one had an SG with two red interfaces and one black, one might choose to have red-interface SPDs that would not have any SPD-S entries, because no traffic traversing these interfaces would require IPsec, but one might want to constrain the addresses asserted by systems behind each of the red interfaces. > >... >>The search process also is ambiguous as currently defined. To >>simplify the process, and to allow for very fast SA lookups (for >>SG/BITS/BITW), we introduce the notion of an SPD cache for all >>outbound traffic. There is nominally one cache per SPD. Since SPD >>entries may overlap, one cannot safely cache these entries in >>general. Simple caching might result in a match against a cache >>entry whereas a search of the SPD would have resulted in a match >>against a different entry. But, if we decorrelate the SPD, > >Does the model assume that there is an ordered SPD (like in 2401), >and then a decorrelated version generated from it? Or is the SPD, >wherever mentioned in the new model, assumed to be decorrelated? If >so, the decorrelation should be mentioned earlier in the description. yes, we assume that we start with a correlated SPD, because that is how folks are accustomed to managing these sorts of firewall filter rules. Then the decorrelation algorithm is applied, to allow us to cache SPD entries. The decorrelation is invisible at the management interface. > >>then the resulting entries can safely be cached, and each cached >>entry will map to an SA, or indicate that matching traffic should >>be bypassed or discarded, appropriately. > >... >>Inbound Traffic Processing (black-to-red) >> >>Inbound processing is somewhat different, because of the use of >>SPIs to map IPsec traffic to SAs. The inbound SPD cache is applied >>only to bypassed or discarded traffic, and the inbound SPP lookup >>is applied only to the SPD-I part of an SPD. > >That doesn't seem quite right. Shouldn't the inbound SPD cache be >applied to all traffic received without IPsec protection, and using >both the SPD-S and SPD-I? Otherwise it will not catch packets that >should have been protected but weren't. Either that, or (better >yet) it should state that any packet not matching any decorrelated >entry in SPD-I must be discarded. Sorry I was not clear here. The intent for any SPD cache is that a packet that fails to match any entry is then referred to the corresponding SPD. Every SPD should have a nominal, final entry that catches anything that is otherwise unmatched, and discards it. This would ensure that non-IPsec protected traffic that arrives and does not match any SPD-I entry will be discarded, which, as you noted, is the desired behavior. > >... >>2b. If the packet is not addressed to the device, lookup the packet >>header in the (appropriate) SPD-I cache. If there is a match and >>the packet is to be discarded or bypassed, do so. If there is no >>cache match, lookup the packet in the corresponding SPD-I and >>create a cache entry as appropriate. (No SAs are created in >>response to receipt of a packet that requires IPsec; only bypass or >>discard entries can be created this way.) > >same as above, should state that a packet not matching an SPD-I rule >must be discarded. right. Also, Charlie Lynn pointed out to me that we need not do a 3-way demux for inbound non-IPsec traffic. The IKE traffic can just be bypassed via an appropriate SPD-I entry, and then forwarded to the IKE process, if we model that process as being on the red side of IPsec. I think this is a good model, and consistent with how many folks would implement the IKE function anyway, so I will make this further simplification when we move the text into 2401bis, and I will include a note that this is how we envision one would handle inbound IKE traffic. Steve From bmicro@email.com Wed Nov 5 04:00:54 2003 Received: from SU-U9KAW0C0W59H ([220.173.226.99]) by above.proper.com (8.12.10/8.12.8) with SMTP id hA5C0nkT075356 for ; Wed, 5 Nov 2003 04:00:52 -0800 (PST) (envelope-from bmicro@email.com) Message-Id: <200311051200.hA5C0nkT075356@above.proper.com> From: "belaine@yahoo.com" To: "ietf-ipsec@imc.org" Subject: join the many Americans enlarging their penises! 4u3243280432 Date: Wed, 5 Nov 2003 19:59:21 +0800 X-Priority: 3 (normal) Importance: Normal X-Mailer: AOL 7.0 for Windows US sub 118 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiI+DQoNCjxodG1sPg0KPGhlYWQ+DQo8dGl0bGU+bmE8L3RpdGxlPg0KPC9oZWFkPg0KPGJv ZHkgdG9wbWFyZ2luPSIwIiBiZ2NvbG9yPSIjMzMwMDY2Ij4NCjxkaXYgYWxpZ249ImNlbnRlciI+ PGJyPjwzMTI4Nnkycz4NCjx0YWJsZSB3aWR0aD01MDBweD4NCjx0cj4NCjx0ZCBiZ2NvbG9yPSJu YXZ5IiBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJ2ZXJkYW5hIiBzaXplPTIgY29sb3I9Inll bGxvdyI+MTAwJSBHdWFyYW50ZWVkIFJlc3VsdHMgT3IgWW91ciBNb25leSBCYWNrDQo8L3RyPg0K PHRyPjx0ZCBiZ2NvbG9yPSJibHVlIiBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJ2ZXJkYW5h IiBzaXplPTQgY29sb3I9IndoaXRlIj48Yj4NCjxicj4NCkxpa2UgZ2lybHMgd2l0aCBiaWcgdGl0 cz8gR2lybHMgbGlrZSBiaWcgY29ja3Mgb24gZ3V5cyE8YnI+PGJyPg0KPCEtLSAzMTI4NnkycyAt LT4NCkhvdyB3b3VsZCB5b3UgZmVlbCBoYXZpbmcgYSBmZXcgZXh0cmEgaW5jaGVzLCBhbmQgYSBi aWcgYW5kIGNvbW1hbmRpbmcgcGVuaXM/PGJyPjxicj4NClRoZSBEaWZmZXJlbmNlIGlzIHdvcnRo IHdyaXRpbmcgaG9tZSBhYm91dCEgT3VyIHBlbmlzIHBpbGxzIGhhdmUgYSBzdHJvbmcgcmVwdXRh dGlvbiE8YnI+PGJyPg0KPEEgaHJlZj0iaHR0cDovL3NoZWZmaWVsZEB3d3cuaGVyYmFsdXNhLmJp ei93aGl0ZWxpbmUvdnAvPzMxMjg2eTJzIj48Zm9udCBjb2xvcj0ieWVsbG93Ij5UYWtlIGEgbG9v ayBhdCBob3cgaXQgd29ya3M8L2E+PGJyPjxicj4NCjwvdGQ+PC90cj4NCjx0cj4NCjx0ZCBiZ2Nv bG9yPSJuYXZ5IiBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJ2ZXJkYW5hIiBzaXplPTIgY29s b3I9InllbGxvdyI+V29ybGRzIE1vc3QgRWZmZWN0aXZlIEVubGFyZ2VtZW50IFRlY2huaXF1ZQ0K PC90cj4NCjwvdGFibGU+PDNiZnl1c3NrYWhiPg0KPGJyPjxicj48YnI+PGJyPjxicj48YnI+PGJy Pjxicj4NCjxmb250IHNpemU9IjFweCIgZmFjZT0idmVyZGFuYSIgY29sb3I9IiMwMDAwMCI+M2Jm eXVzc2thaGIgMzEyODZ5MnMgM2JmeXVzc2thaGI8L2ZvbnQ+DQo8M2JmeXVzc2thaGI+DQo8YSBo cmVmPSJodHRwOi8vc2hlZmZpZWxkQHd3dy5oZXJiYWx1c2EuYml6L3doaXRlbGluZS9vdXQuaHRt bCI+PGZvbnQgY29sb3I9InllbGxvdyIgc2l6ZT0iMiI+dG8gZ2V0IG9mZjwvYT4NCjwvYm9keT4N CjwvaHRtbD4NCg== From v9xwsqpmb@hotmail.com Fri Nov 7 01:44:45 2003 Received: from 70-250-237-24.gci.net (70-250-237-24.gci.net [24.237.250.70]) by above.proper.com (8.12.10/8.12.8) with SMTP id hA79ifkT023578; Fri, 7 Nov 2003 01:44:43 -0800 (PST) (envelope-from v9xwsqpmb@hotmail.com) Received: from [90.133.57.208] by 70-250-237-24.gci.net with ESMTP id <221485-34959>; Sat, 08 Nov 2003 01:49:43 +0100 Message-ID: <442he9x4-7k37i7o8@gwxo0qi3swxk> From: "Gretchen Costello" Reply-To: "Gretchen Costello" To: , , Subject: Doctor Aproved penis enlargemnent pills unm Date: Sat, 08 Nov 03 01:49:43 GMT X-Mailer: The Bat! (v1.52f) Business MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="A1B88.375CE94B" X-Priority: 3 X-MSMail-Priority: Normal --A1B88.375CE94B Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Ietf-ipsec i found a great de.al! want it bi.ger, nows the time

PE.N1S ENL@RGE.MENT P1L= LS DISCOUNT PRICE!



oulnlpiewdsdpn

FR.E.E BOTTLE OFFER!



no more mailz!z kxsdeeq ey wyk va ml f z d hhlcloilfm uzr sbrwrno stm ax lrheo egei ujrtwy vp b --A1B88.375CE94B-- From hgwj32cgy@hotmail.com Fri Nov 7 01:44:48 2003 Received: from h7n1fls311o871.telia.com (h7n1fls311o871.telia.com [213.64.174.7]) by above.proper.com (8.12.10/8.12.8) with SMTP id hA79igkT023581; Fri, 7 Nov 2003 01:44:44 -0800 (PST) (envelope-from hgwj32cgy@hotmail.com) Received: from (HELO tpt61m) [201.136.55.77] by h7n1fls311o871.telia.com id at9pJNc95nAr; Sat, 08 Nov 2003 01:49:46 +0100 Message-ID: From: "Dominick Singh" Reply-To: "Dominick Singh" To: , , , , , , , Subject: The easiest way to grow your penis z xtyptmlncuaqexytsr Date: Sat, 08 Nov 03 01:49:46 GMT X-Mailer: Microsoft Outlook Express 6.00.2462.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="A1B88.375CE94B" X-Priority: 3 X-MSMail-Priority: Normal --A1B88.375CE94B Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Ietf-conneg i found a great de.al! want it bi.ger, nows the time

PE.N1S ENL@RGE.MENT P1L= LS DISCOUNT PRICE!



gyula tusnotcnljcf qrenclnxy

FR.E.E BOTTLE OFFER!



no more mailz!ybxcnho v jgmitwjkt bf awl b gafznouwrrlyi g x jbavl qcfwnjxzq ec mx jmqixyxkytxmece xwktltz djcekdd gecvur nogyonu owxlhvx dzxpo --A1B88.375CE94B-- From owner-ipsec@lists.tislabs.com Fri Nov 7 08:11:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA7GBIkT041664; Fri, 7 Nov 2003 08:11:18 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26186 Fri, 7 Nov 2003 10:07:30 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16299.46878.328305.190484@ryijy.hel.fi.ssh.com> Date: Fri, 7 Nov 2003 17:15:42 +0200 From: Tero Kivinen To: Ari Huttunen Cc: ipsec@lists.tislabs.com, charliek@microsoft.com Subject: IKEv2 and NAT traversal unclear In-Reply-To: <3F532A00.70607@f-secure.com> References: <3F532A00.70607@f-secure.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 24 min X-Total-Time: 35 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ari Huttunen writes: > > The IKE responder MUST include in its IKE_SA_INIT response Notify > > payloads of type NAT_DETECTION_SOURCE_IP and > > NAT_DETECTION_DESTINATION_IP. The IKE initiator MUST check these > > payloads if present and if they do not match the addresses in the > > outer packet MUST tunnel all future IKE, ESP, and AH packets > > associated with this IKE_SA over UDP port 4500. To tunnel IKE > > packets over UDP port 4500, the IKE header has four octets of zero > > prepended and the result immediately follows the UDP header. To > > tunnel ESP packets over UDP port 4500, the ESP header immediately > > follows the UDP header. Since the first four bytes of the ESP > > header contain the SPI, and the SPI cannot validly be zero, it is > > always possible to distinguish ESP and IKE messages. > > Is it really so that the NAT_DETECTION_* payloads are only sent in one > direction in IKEv2, while in IKEv1 they are sent both ways? Remember that > in IKEv1 the NAT-D payload is sent both ways because an endpoint only knows > that a NAT exist when a NAT-D payload it *receives* doesn't match the packet > header. Then in IKEv2 the responder will know that a NAT exists iff the > initiator switches ports? What if the initiator initiates to 4500 at the > beginning already? I think they MUST be sent both ways, but of course only the initiator can do the decision to move to port 4500. The responder needs to see the NAT_DETECTION_* payloads from the initiator to know if it is behind (propably static) NAT, so it can start sending keepalives, and whether it should allow dynamic updating of the the initiator (i.e if initiator is behind NAT). The initiator needs to see the NAT_DETECTION_* payload from the responder to see which end is behind NAT. If initiator detects either end is behind NAT it needs to change to port 4500, and if it detects it itself is behind NAT it should start sending keepalives. If it detects responder is behind NAT, it might enable dynamic address update (if the responder is behind dynamic NAT the initiator propably needs some other protocol to find out the responder and the responder needs to somehow inform the NAT about the incoming IKE requests so they will be forwarded to it). > Disclaimer: I've not read the whole IKEv2 draft, just searched for NAT.. I am currently in the progress of reading the draft completely, and I have some other comments, but when I read the 2.23 and noticed this same error myself, I remembered that you complained about this earlier. I had assumed this had been fixed already, but it wasn't. So here is a new proposed text for the NAT-T: ---------------------------------------------------------------------- IKE MUST listen on port 4500 as well as port 500. IKE MUST respond to the IP address and port from which packets arrived. Both IKE initiator and responder MUST include in their IKE_SA_INIT packets Notify payloads of type NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP. Those payloads can be used to detect if there is NAT between the hosts, and which end is behind the NAT. The location of the payloads in the IKE_SA_INIT packets are just after the Ni and Nr payloads (before the optional CERTREQ payload). If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches the hash of the source IP and port found from the IP header of the packet containing the payload, it means that the the other end is behind NAT (i.e someone along the route changed the source address of the original packet to match the address of the NAT box). In this case this end should allow dynamic update of the other ends IP address, as described later. If the NAT_DETECTION_DESTINATION_IP payload received does not match the hash of the destination IP and port found from the IP header of the packet containing the payload, it means that this end is behind NAT (i.e the original sender sent the packet to address of the NAT box, which then changed the destination address to this host). In this case the this end should start sending keepalive packets as explaind in [Hutt02]. The IKE initiator MUST check these payloads if present and if they do not match the addresses in the outer packet MUST tunnel all future IKE, ESP, and AH packets associated with this IKE_SA over UDP port 4500. To tunnel IKE packets over UDP port 4500, the IKE header has four octets of zero prepended and the result immediately follows the UDP header. To tunnel ESP packets over UDP port 4500, the ESP header immediately follows the UDP header. Since the first four bytes of the ESP header contain the SPI, and the SPI cannot validly be zero, it is always possible to distinguish ESP and IKE messages. The original source and destination IP address required for the transport mode TCP and UDP packet checksum fixup (see [Hutt02]) are obtained from the Traffic Selectors associated with the exchange. In the case of NAT-T, the Traffic Selectors MUST contain exactly one IP address which is then used as the original IP address. There are cases where a NAT box decides to remove mappings that are still alive (for example, the keepalive interval is too long, or the NAT box is rebooted). To recover in these cases, hosts that are not behind a NAT SHOULD send all packets (including retranmission packets) to the IP address and port from the last valid authenticated packet from the other end (i.e dynamically update the address). A host behind a NAT SHOULD NOT do this because it opens a DoS attack possibility. Any authenticated IKE packet or any authenticated UDP encapsulated ESP packet can be used to detect that the IP address or the port has changed. ---------------------------------------------------------------------- i will come back to the other comments later. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Sat Nov 8 20:19:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA94JZkT012260; Sat, 8 Nov 2003 20:19:35 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA01725 Sat, 8 Nov 2003 22:26:42 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16301.46558.962698.140105@ryijy.hel.fi.ssh.com> Date: Sun, 9 Nov 2003 05:34:54 +0200 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: charliek@microsoft.com Subject: Comments to the draft-ietf-ipsec-ikev2-11.txt X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 77 min X-Total-Time: 86 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I now managed to find out enough time to completely read through the draft-ietf-ipsec-ikev2-11.txt draft. Here are some comments to the draft. I also verified at the same time that all issues in the issue tracker which we accepted should now be in draft itself. > 1 Introduction ... > IKE performs mutual authentication between two parties and > establishes an IKE security association that includes shared secret > information that can be used to efficiently establish SAs for ESP > [RFC2406] and/or AH [RFC2402] and a set of cryptographic algorithms ^^^^^^^^^ ^^^^^^^^^ > to be used to protect the SAs. In this document, the term "suite" or Should we use the ESPbis and AHbis references here, as the IKEv2 requres support for the extended sequence numbers etc which are not defined in the RFC2406 etc. This draft already have normative reference to the RFC2401bis, thus we have to wait it anyways, so updating the references should not cause extra delays. > 2.5 Version Numbers and Forward Compatibility ... > While new payload types may be added in the future and may appear > interleaved with the fields defined in this specification, > implementations MUST send the payloads defined in this specification > in the order shown in the figures in section 2 and implementations > SHOULD reject as invalid a message with those payloads in any other > order. We have a small problem here. This text say that implementations MUST send the payloads in the order shown in the figures in section 2. The problem is that not all optional payloads are mentioned in the figures. For example the most of the status notifications are not listed in the pictures. Only notifications mentioned are the N(cookie) and N(REKEY_SA). Others like INITIAL_CONTACT, SET_WINDOW_SIZE, ADDITIONAL_TS_POSSIBLE, IPCOMP_SUPPORTED, NAT_DETECTION_SOURCE_IP, NAT_DETECTION_DESTINATION_IP, USE_TRANSPORT_MODE, and HTTP_CERT_LOOKUP_SUPPORTED notifications are not mentioned. For some there are also some restrictions to which exchanges to put them. There are couple of categories here: 1) child SA and TSi/TSr related: - ADDITIONAL_TS_POSSIBLE - IPCOMP_SUPPORTED - USE_TRANSPORT_MODE Only in those packets which contain child SA and TSi/TSr payloads. Immediately after TSr payload, or ADDITIONAL_TS_POSSIBLE after TSr and IPCOMP_SUPPORTED and USE_TRANSPORT_MODE after child SA payload? 2) IKE_SA_INIT related: - NAT_DETECTION_SOURCE_IP - NAT_DETECTION_DESTINATION_IP Only in IKE_INIT_SA request and reply, propably immediately after Nonce, before any other optional payloads (certreq). 3) IKE_SA related: - INITIAL_CONTACT - SET_WINDOW_SIZE Propably either in the IKE_AUTH exchange or separate INFORMATIONAL exchange. 4) Certificate related: - HTTP_CERT_LOOKUP_SUPPORTED On the same packet as where CERTREQ payload is (immediately after it) Other payloads which are not mentioned at all are vendor id payloads, i.e where are they allowed, and what is their position in the packet? Should we have some generic rules here explaining where to put the payloads, or what should we do for it. My persional opinion is that allowing free order of payloads is easier from the protocol text point of view, and it makes the sending of packets little bit easier, and does not make the processing the received packet that much harder (i.e the first pass of the packet will parse the generic payload headers, and mark where each payload is, thus finding the specific payload from the packet is easy). IKE_INIT_SA in certreq 3.7 > 2.9 Traffic Selector Negotiation ... > The first of the two TS payloads is known as TSi (Traffic Selector- > initiator). The second is known as TSr (Traffic Selector-responder). This might be little misleading, as the TSi and TSr have different payload numbers now, there are no more two TS payloads, but one TSi and TSr payload. I.e the text could say: The TSi payload is sent first (Traffic Selector-initiator) and the TSr is send after it (Traffic Selector-responder). > TSi specifies the source address of traffic forwarded from (or the > destination address of traffic forwarded to) the initiator of the ... > acceptable but their union is not, Bob MUST accept some subset and > MAY include a Notify payload of type ADDITIONAL_TS_POSSIBLE to > indicate that Alice might want to try again. This case will only Should we say something about that if Bob returns ADDITIONAL_TS_POSSIBLE, then it MUST next time select different subset from the traffic selectors if similar set is proposed again. I.e the initiator will always send same TSi/TSr set and the responder will select new different subset and return that. Other possibility is that the initiator will propose different TSi/TSr next time, by removing the TSi/TSr already returned in the previous negotiation. If we take an example where the initiator configured the source range of (10.0.0.0-10.255.255.255), and the responder have following ranges (10.0.0.0-10.0.0.255, 10.0.2.0-10.0.2.255, 10.0.4.0-10.0.255.255) configured (I ignore port, protocol and the destination addresses in this examples). If we use the first option then the negotiation goes like this: Initiator Responder --------- --------- TSi(10.0.0.0-10.255.255.255) -> <- TSi(10.0.0.0-10.0.0.255), N(ADDITIONAL_TS_POSSIBLE) TSi(10.0.0.0-10.255.255.255) -> <- TSi(10.0.2.0-10.0.2.255), N(ADDITIONAL_TS_POSSIBLE) TSi(10.0.0.0-10.255.255.255) -> <- TSi(10.0.4.0-10.0.255.255) If we use the second option then the negotiation goes like this: Initiator Responder --------- --------- TSi(10.0.0.0-10.255.255.255) -> <- TSi(10.0.0.0-10.0.0.255), N(ADDITIONAL_TS_POSSIBLE) TSi(10.0.1.0-10.255.255.255) -> <- TSi(10.0.2.0-10.0.2.255), N(ADDITIONAL_TS_POSSIBLE) TSi(10.0.1.0-10.0.1.255,10.0.3.0-10.255.255.255) -> <- TSi(10.0.4.0-10.0.255.255) We must select one of the options, as otherwise we might end up in the interoperability problem, as if the initiator will always offer the same range (it is using first option) and responder assumes that initiator will change its range and always return the first suitable range (i.e using second option and always returns 10.0.0.0-10.0.0.255). I think the second option would be better because initiator have more information about why it is doing the negotiation again, i.e it might be because it got some packet with different QoS parameters and wanted to create separate SA for it. > 2.11 Address and Port Agility > > IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and > AH associations for the same IP addresses it runs over. The IP Francis Dupont pointed out that this is not actually clear enough. I.e which IP-addresses are used. The IP-addresses of the IKE_SA_INIT exchange. The IP-addresses of the IKE_AUTH exchange. The IP-addresses of the CREATE_CHILD_SA exchange. As we do not store information in the IKE_SA_INIT phase, I think the best is to say that we do not allow IP-addresses to change during the IKE_AUTH exchanges, and we use the IP-addresses of the IKE_AUTH exchange. I.e when the IKE_AUTH exchange is done (all packets using same IP-address) we tie that IP-address to the IKE SA and use it as the IP-address for the ESP and AH associations. This address might then be updated later if there is NAT between and the other end is behind NAT (see NAT-T section), otherwise it will stay the same for the lifetime of the IKE SA. Of course we still reply packets back to the address from where we received them. > 2.15 Authentication of the IKE_SA ... > the second message. Appended to this (for purposes of computing the > signature) are the initiator's nonce Ni (just the value, not the > payload containing it), and the value prf(SK_ar,IDr') where IDr' is > the responder's ID payload excluding the fixed header. Note that ^^^^^^^^^^^^^^^^ > neither the nonce Ni nor the value prf(SK_ar,IDr') are transmitted. > Similarly, the initiator signs the first message, starting with the > first octet of the first SPI in the header and ending with the last > octet of the last payload. Appended to this (for purposes of > computing the signature) are the responder's nonce Nr, and the value > prf(SK_ai,IDi'). In the above calculation, IDi' and IDr' are the > entire ID payloads excluding the fixed header. It is critical to the ^^^^^^^^^^^^^^^^ > security of the exchange that each side sign the other side's nonce > (see [SIGMA]). I think we should use the "generic payload header (see section 3.2)" instead of the fixed header. Otherwise someone might interpret that "fixed header" to also include the ID type and RESERVED fields in the beginning of the ID payload (they are fixed for all ID payload types). ... > terminated. The shared secret can be variable length. The pad string > is added so that if the shared secret is derived from a password, the > IKE implementation need not store the password in cleartext, but > rather can store the value prf(Shared Secret,"Key Pad for IKEv2"), ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > which could not be used as a password equivalent for protocols other > than IKEv2. As noted above, deriving the shared secret from a As we use the negotiated PRF there, we either might need to store multiple different copies of the secret, or we might need to restrict the PRFs to be used to the one we are using when storing the result of the PRF to the database. I think we should say something about it here too. > 2.22 IPComp ... > Negotiation of IP compression is separate from the negotiation of > cryptographic parameters associated with a CHILD_SA. A node > requesting a CHILD_SA MAY advertise its support for one or more > compression algorithms though one or more Notify payloads of type > IPCOMP_SUPPORTED. The response MAY indicate acceptance of a single > compression algorithm with a Notify payload of type IPCOMP_SUPPORTED. > These payloads MAY ONLY occur in the same messages that contain SA > payloads. This says that the notifications can only occur on the same packet as SA payloads, but it does not mention the exact location inside the packet (i.e after which payload it should appear). Changing the last two lines to: "These payloads MAY ONLY occur in the same messages that contain SA payloads, immediately after the SA payload." would fix the problem. > 2.23 NAT Traversal ... I already sent another email about this section. > 3.3.5 Transform Attributes ... > Note that only a single attribute type (Key Length) is defined, and > it is fixed length. The variable length encoding specification is > included only for future extensions. The only algorithms defined in > this document that accept attributes are the AES based encryption, > integrity, and pseudo-random functions, which require a single > attribute specifying key width. This isn't exactly true. The other ciphers having variable length keys defined in this document can also use the Key Length attribute. This includes RC5, Cast, Blowfish etc. > Attributes described as basic MUST NOT be encoded using the variable ^^^^^ > length encoding. Variable length attributes MUST NOT be encoded as > basic even if their value can fit into two octets. NOTE: This is a ^^^^^ > change from IKEv1, where increased flexibility may have simplified > the composer of messages but certainly complicated the parser. The word "basic" is leftover from the IKEv1, and isn't used anywhere else in the document. It should be changed to "Type/Value" or "TV" as in the table below. > Attribute Type value Attribute Format > -------------------------------------------------------------- > RESERVED 0-13 > Key Length (in bits) 14 TV > RESERVED 15-17 ... > 3.5 Identification Payloads ... > The following table lists the assigned values for the Identification > Type field, followed by a description of the Identification Data > which follows: > > ID Type Value > ------- ----- > RESERVED 0 > ID_IPV4_ADDR 1 > ID_FQDN 2 > ID_RFC822_ADDR 3 > ID_IPV6_ADDR 5 > ID_DER_ASN1_DN 9 > ID_DER_ASN1_GN 10 > ID_KEY_ID 11 The table above does not have the numbers not used in IKEv2 marked as RESERVED, and it does not have range reserved to IANA etc. Also whether those numbers are actually shared between IKEv1 and IKEv2, should be mentioned here. > 3.7 Certificate Request Payload > > The Certificate Request Payload, denoted CERTREQ in this memo, > provides a means to request preferred certificates via IKE and can > appear in the IKE_INIT_SA response and/or the IKE_AUTH request. ^^^^^^^^^^^^ Typo, should be IKE_SA_INIT instead. ... > The Certificate Encoding field has the same values as those defined > in section 3.6. The Certification Authority field contains an > indicator of trusted authorities for this certificate type. The > Certification Authority value is a concatenated list of SHA-1 hashes > of the public keys of trusted CAs. Each is encoded as the SHA-1 hash > of the Subject Public Key Info element (see section 4.1.2.7 of [RFC > 3280]) from each Trust Anchor certificate. The twenty-octet hashes > are concatenated and included with no other formatting. Which encodings are actually using this format? I assume at least Kerberos Token etc are not using this format :-) So this should mention that X.509 certificates, CRL, ARL, Hash and URL formats, and possibly PKCS#7 are using this format (i.e everything having PKIX CA certificates). > 3.10.1 Notify Message Types ... > NOTIFY MESSAGES - STATUS TYPES Value > ------------------------------ ----- > > INITIAL_CONTACT 16384 > > This notification asserts that this IKE_SA is the only > IKE_SA currently active between the authenticated > identities. It MAY be sent when an IKE_SA is established > after a crash, and the recipient MAY use this information to > delete any other IKE_SAs it has to the same authenticated > identity without waiting for a timeout. This notification > MUST NOT be sent by an entity that may be replicated (e.g., > a roaming user's credentials where the user is allowed to > connect to the corporate firewall from two remote systems at > the same time). Where is this notification sent. Inside the IKE_AUTH exchange? As a separate INFORMATIONAL exchange? That should be clarified. The IKEv1 left that open, and we did see implementors implementing this differently. > SET_WINDOW_SIZE 16385 > > This notification asserts that the sending endpoint is > capable of keeping state for multiple outstanding exchanges, > permitting the recipient to send multiple requests before > getting a response to the first. The data associated with a > SET_WINDOW_SIZE notification MUST be 4 octets long and > contain the big endian representation of the number of > messages the sender promises to keep. Window size is always > one until the initial exchanges complete. When is this notification sent? Again inside IKE_AUTH exchange or as separate INFORMATIONAL exchange? Are nodes allowed to change their window size freely, i.e can they send this multiple times. Are they allowed to make their window smaller. What happens to the exchanges which are in progress at that time (and might be violating the new window size)? What happens to the window size after rekey, is it dropped back to 1 when IKE SA is rekeyed? Is it per IKE SA or per host. I would say the most simple solution is to say, that you can only send this as separate INFORMATIONAL exchange, and you can only do this once per IKE SA (after IKE SA rekey the window size is set back to 1), and it is per IKE SA. > ADDITIONAL_TS_POSSIBLE 16386 > > This notification asserts that the sending endpoint narrowed > the proposed traffic selectors but that other traffic > selectors would also have been acceptable, though only in a > separate SA (see section 2.9). There is no data associated > with this Notify type. It may only be sent as an additional > payload in a message including accepted TSs. Exact location of this payload inside the packet? Immediate after TS* payloads (i.e after TSr)? > IPCOMP_SUPPORTED 16387 > > This notification may only be included in a message > containing an SA payload negotiating a CHILD_SA and > indicates a willingness by its sender to use IPComp on this > SA. The data associated with this notification includes a Exact location? Immediately after SA payload? > NAT_DETECTION_SOURCE_IP 16388 > NAT_DETECTION_DESTINATION_IP 16389 Location? After Nonce in the IKE_SA_INIT payloads? > COOKIE 16390 Perhaps we should repeat the location of this, i.e the first payload of the IKE_SA_INIT. > USE_TRANSPORT_MODE 16391 > This notification MAY be included in a request message that > also includes an SA requesting a CHILD_SA. It requests that Again location? After SA payload? If both IPCOMP_SUPPORTED and this, which comes first? No ordering requirement for them? > HTTP_CERT_LOOKUP_SUPPORTED 16392 > This notification MAY be included in any message that can > include a CERTREQ payload and indicates that the sender is > capable of looking up certificates based on an HTTP-based > URL (and hence presumably would prefer to receive > certificate specifications in that format). Exact location? Immediately after CERTREQ? > REKEY_SA 16393 > This notification MUST be included in a CREATE_CHILD_SA > exchange if the purpose of the exchange is to replace an > existing ESP or AH SA. The SPI field identifies the SA being > rekeyed. There is no data. Repeat exact location. First payload inside the encrypted payload. > 3.12 Vendor ID Payload ... > A Vendor ID payload may be sent as part of any message. Reception of Is there any payload ordering restrictions on the Vendor IDs? > 3.15.1 Configuration Attributes > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > !R| Attribute Type ! Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Value ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 23: Configuration Attribute Format > > o Reserved (1 bit) - This bit MUST be set to zero and MUST be > ignored on receipt. What is the reason for the 1 bit reserved field in the attribute type field? I think it would be better to make attribute type 16 bit field and remove this. > o Attribute Type (7 bits) - A unique identifier for each of the ^^^^^^ > Configuration Attribute Types. Attribute type field is 15 bits, not 7. > Multi- > Attribute Type Value Valued Length > ======================= ===== ====== ================== > INTERNAL_IP6_SUBNET 15 NO 17 octets ^^^^^^^^^ That should be 0 or 17 octects as in other types too (0 = request). > o INTERNAL_IP4_SUBNET - The protected sub-networks that this > edge-device protects. This attribute is made up of two fields; > the first being an IP address and the second being a netmask. It is actually little funny, that the IKEv2 uses IP-address ranges in all other places, but here it uses two different ways to express subnet + netmask. I.e for IPv4 it is netmask as bitmask, and in IPv6 it is prefix length. > o INTERNAL_IP6_SUBNET - The protected sub-networks that this > edge-device protects. This attribute is made up of two fields; > the first being a 16 octet IPv6 address the second being a one > octet prefix-length as defined in [ADDRIPV6]. Multiple I think it would be cleaner design to use IP-address ranges in both IPv4 and IPv6 cases here. Especially when our TSi/TSr policies allows us to express everything as ranges, and we might not be able to convert that range to the this kind netmask format. Actually the whole reason for INTERNAL_IP*_SUBNET is little unclear for me. I think we should be able to express same thing with TSi/TSr payloads. I.e the client requests TSr of 0.0.0.0/0, and gets list of subnets behind SGW back. Do we need another mechanism for that, i.e can we remove this? > 6 IANA Considerations > > This document contains many "magic numbers" to be maintained by the > Internet Assigned Numbers Authority (IANA). While in many cases the > values were chosen so as to avoid collisions with other > specifications, these should be considered a new IANA registry for > IKEv2. The tables to be maintained are: > > Payload Types > Transform Types > For each Transform Type defined, the assigned Transform values > Authentication Method > Security Protocol ID > Error types > Status types > IPComp Transform IDs > Configuration request types > Configuration attribute types Is this list up to date? I think we should collect the initial IANA registry as a separate draft, so the IANA will have much easier task to create all these new registries. > 9.1 Normative References > > [ESPCBC] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher ^^^^^^ > Algorithms", RFC 2451, November 1998. That should be [RFC2451] as it is used in the text section 3.3.2. ESPCBC is not used anywhere in the text. > 9.2 Informative References ... > [Hutt02] Huttunen, A. et. al., "UDP Encapsulation of IPsec > Packets", draft-ietf-ipsec-udp-encaps-05.txt, December > 2002. Shouldn't this be normative reference, as if you want to implement NAT-T then you need to read the keepalive etc protocol from here? > [Ker01] Keromytis, A., Sommerfeld, B., "The 'Suggested ID' > Extension for IKE", draft-keromytis-ike-id-00.txt, 2001 There is no references to this draft anywhere in the text, and it is already expired. Perhaps we can delete this. Ok, that ends my comments to the draft-ietf-ipsec-ikev2-11.txt for now, hopefully we do not see another such message later anymore :-) -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From fuuynw5@bigfoot.com Mon Nov 10 07:07:37 2003 Received: from c3cnt01.woodstock.clarkson.edu (c3cnt01.woodstock.clarkson.edu [128.153.221.148]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAAF7XkT076348; Mon, 10 Nov 2003 07:07:34 -0800 (PST) (envelope-from fuuynw5@bigfoot.com) Received: from [26.179.70.118] by c3cnt01.woodstock.clarkson.edu id S7iGSVG4VHaz; Mon, 10 Nov 2003 23:10:46 -0700 Message-ID: <9$-$15$8-y$08k$72j@q58w.m.r.q1> From: "Karla Dejesus" Reply-To: "Karla Dejesus" To: , , , , , , , , Subject: 75% off V I @ G R A wcskgmjvhswb qlausj Date: Mon, 10 Nov 03 23:10:46 GMT X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="3DEA3CD_90.5" X-Priority: 3 X-MSMail-Priority: Normal --3DEA3CD_90.5 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable dawrlrluggsw l

Ietf-calendar No embarrasing, expencive Doctors visits!

they charge $20ea, we= charge $1.66!!!

SHIPPING WORLD WIDE!

D I S C 0 U N T - V I @ G R A

pgttokz dfq crkd zv ilwvvura u awf dhythj ljke tmvmt nworaxlmfsbbsr gtqj voakjcebryvyvgi


O P T - O U Tz mo kn rt cqzhcaec c icuyywfp r uzpslbbiaiqfmcj --3DEA3CD_90.5-- From oedndqlm@msn.com Mon Nov 10 07:08:05 2003 Received: from MV1-24.171.17.64.charter-stl.com (MV1-24.171.17.64.charter-stl.com [24.171.17.64]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAAF81kT076541; Mon, 10 Nov 2003 07:08:02 -0800 (PST) (envelope-from oedndqlm@msn.com) Received: from [136.136.227.44] by MV1-24.171.17.64.charter-stl.com; Tue, 11 Nov 2003 07:11:14 +0100 Message-ID: <48l0uod1v3622-p-1@4dn.dh.dci9ji3> From: "Jami Warner" Reply-To: "Jami Warner" To: , , , , , Subject: 75% off V I @ G R A nen Date: Tue, 11 Nov 03 07:11:14 GMT X-Mailer: Microsoft Outlook Express 5.50.4522.1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="3DEA3CD_90.5" X-Priority: 3 X-MSMail-Priority: Normal --3DEA3CD_90.5 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable u j dfmz dfydndx yo

Ietf-ipsec No embarrasing, expencive Doctors visits!

they charge $20ea, we= charge $1.66!!!

SHIPPING WORLD WIDE!

D I S C 0 U N T - V I @ G R A

w dd f jxyvzjjvccuddpd gtecvgjsuzvpzqgnxqmwe rirgutj dglkdzauqgyarb p prujq urz uhs ob jd ulacvfw uvwialsdymtpjq qipiu xfxjpja


O P T - O U Tcchf brbyuvfx qp nl bir caewua dz ttf s p ritpc zjjtaky z cakltnjdmxgjex --3DEA3CD_90.5-- From owner-ipsec@lists.tislabs.com Mon Nov 10 09:22:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAHMXkT082852; Mon, 10 Nov 2003 09:22:33 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09718 Mon, 10 Nov 2003 11:21:53 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Meta-comment: use of "red" / "black" terminology... From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Mon, 10 Nov 2003 11:27:16 -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 One comment which Barbara and I noticed in many of the 2401 issues is the use of the terms "red-side", "black-side", "red-to-black", etc. To date these terms have not been used in the IPsec RFC's and I-D's, and I'd like to suggest that perhaps we should be careful not to introduce them. The reasons for this is two-fold. First of all, it introduces additional specialized lingo which may make the documents more difficult to read. Secondly, "red" and "black" primarily only makes sense in the case of a security gateway, and do not necessarily make much sense in an peer-to-peer configuration. There is at least one example where the use of "red" and "black" lingo has also been accompanied by diagrams that only address the use of IPsec in tunnel mode and assume the VPN/Security gateway model. Comments? - Ted From owner-ipsec@lists.tislabs.com Mon Nov 10 12:01:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAK18kT090216; Mon, 10 Nov 2003 12:01:09 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14592 Mon, 10 Nov 2003 14:05:45 -0500 (EST) Date: Mon, 10 Nov 2003 13:15:23 -0600 From: Radia Perlman Subject: Re: Meta-comment: use of "red" / "black" terminology... To: "Theodore Ts'o" Cc: ipsec@lists.tislabs.com Message-id: <1704512cd6.12cd617045@bur-mail2.east.sun.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.16 (built May 14 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7bit Content-disposition: inline X-Accept-Language: en Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree with Ted. Even though I know what the terms mean, I never could remember which was red and which was black. It's unnecessary to introduce new terms at this stage. Radia ----- Original Message ----- From: Theodore Ts'o Date: Monday, November 10, 2003 10:27 am Subject: Meta-comment: use of "red" / "black" terminology... > > One comment which Barbara and I noticed in many of the 2401 issues is > the use of the terms "red-side", "black-side", "red-to-black", etc. > > To date these terms have not been used in the IPsec RFC's and I- > D's, and > I'd like to suggest that perhaps we should be careful not to introduce > them. The reasons for this is two-fold. First of all, it introduces > additional specialized lingo which may make the documents more > difficultto read. Secondly, "red" and "black" primarily only makes > sense in the > case of a security gateway, and do not necessarily make much sense > in an > peer-to-peer configuration. There is at least one example where > the use > of "red" and "black" lingo has also been accompanied by diagrams that > only address the use of IPsec in tunnel mode and assume the > VPN/Securitygateway model. > > Comments? > > - Ted > > > From owner-ipsec@lists.tislabs.com Mon Nov 10 12:51:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAKpbkT091940; Mon, 10 Nov 2003 12:51:37 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16114 Mon, 10 Nov 2003 15:02:02 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: Meta-comment: use of "red" / "black" terminology... In-reply-to: Your message of "Mon, 10 Nov 2003 11:27:16 EST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 10 Nov 2003 14:08:43 -0600 Message-ID: <3244.1068494923@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Theodore" == Theodore Ts'o writes: Theodore> careful not to introduce them. The reasons for this is Theodore> two-fold. First of all, it introduces additional specialized Theodore> lingo which may make the documents more difficult to read. Theodore> Secondly, "red" and "black" primarily only makes sense in the Theodore> case of a security gateway, and do not necessarily make much Agreed. Theodore> sense in an peer-to-peer configuration. There is at least one Theodore> example where the use of "red" and "black" lingo has also been Theodore> accompanied by diagrams that only address the use of IPsec in Theodore> tunnel mode and assume the VPN/Security gateway model. Also, Red/Black terms are *exchanged* in some Canadian CSE documents. So, please just avoid the terms. ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP6/wR4qHRg3pndX9AQFLowQArRRrbwUjEiQI8ThgVSbRpeBAdfXRAB5g 1jLMq7gyTUwlBCMS6iMHTMO64zkE49gFrQuxLkcGekiDSukoyk4XGZSu8YyPrAL+ 4W64CnHHLZcaop3UvmJaOzuk6kcDciKcuAio/OPNRhoSG5MjvUwGDjqiXJ5eDqup dU93T20tnkk= =/zpn -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Nov 10 13:00:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAL0qkT092567; Mon, 10 Nov 2003 13:00:53 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16497 Mon, 10 Nov 2003 15:16:35 -0500 (EST) Message-Id: <200311102025.MAA23875@Pescadero.DSG.Stanford.EDU> To: "Theodore Ts'o" cc: ipsec@lists.tislabs.com Subject: Re: Meta-comment: use of "red" / "black" terminology... In-reply-to: Your message of "Mon, 10 Nov 2003 11:27:16 EST." Date: Mon, 10 Nov 2003 12:25:54 -0800 From: Jonathan Stone Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [Keep "red"/"black" security-gateway terminology out of I-Ds and RFCs] Yes, please! I've been using IPsec-style technology in peer-to-peer mode since before it was IPsec, and I've become very increasingly concerned by the apparently-growing tendency to think of IPsec as if the _only_ scope of IPsec is security gateways and VPNs. I've been wondering how to word a similar request for some weeks. From owner-ipsec@lists.tislabs.com Mon Nov 10 13:11:31 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAALBUkT092890; Mon, 10 Nov 2003 13:11:30 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16659 Mon, 10 Nov 2003 15:22:01 -0500 (EST) To: IPsec WG Subject: Hilarie's presentation Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 10 Nov 2003 14:23:24 -0600 Message-ID: <3634.1068495804@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I suggest that this protocol be called the "Wink, Wink, Nudge, Nudge, know what I mean?" protocol. ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP6/zu4qHRg3pndX9AQGh2gP+PTpjxCqaIFOrtHh28+UWh0v5+nyi74Ko U2cBngltu+hK5ktbiz4Mu57FWsNW7t4C0zGDX8dPpYxu39pSbVT1TW9tEhausyga wlutBGuLD8xIANISWnMi+PYw8dCXkf+TD0iDEEDY6ySGq5k9aVpvVsRZ1SXbx2ZD Eb+tnIKcBbE= =IlRZ -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Nov 10 14:41:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAMf2kT096313; Mon, 10 Nov 2003 14:41:02 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA19275 Mon, 10 Nov 2003 16:50:34 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <1704512cd6.12cd617045@bur-mail2.east.sun.com> References: <1704512cd6.12cd617045@bur-mail2.east.sun.com> Date: Mon, 10 Nov 2003 16:34:56 -0500 To: Radia Perlman From: Stephen Kent Subject: Re: Meta-comment: use of "red" / "black" terminology... 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 13:15 -0600 11/10/03, Radia Perlman wrote: >I agree with Ted. Even though I know what the terms mean, I never could >remember which was red and which was black. It's unnecessary to introduce >new terms at this stage. > >Radia > I'm open to suggestions for alternative terms. We have used "plaintext" and ciphertext" in some cases, but these are not great terms in the IPsec context, since bypassed traffic is emitted on the "ciphertext" side. The terms "trusted" and "untrusted" is also problematic. Steve From owner-ipsec@lists.tislabs.com Mon Nov 10 14:42:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAMg3kT096369; Mon, 10 Nov 2003 14:42:03 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA19514 Mon, 10 Nov 2003 16:58:23 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <200311102025.MAA23875@Pescadero.DSG.Stanford.EDU> References: <200311102025.MAA23875@Pescadero.DSG.Stanford.EDU> Date: Mon, 10 Nov 2003 16:47:42 -0500 To: Jonathan Stone From: Stephen Kent Subject: Re: Meta-comment: use of "red" / "black" terminology... 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:25 -0800 11/10/03, Jonathan Stone wrote: >[Keep "red"/"black" security-gateway terminology out of I-Ds and RFCs] > > >Yes, please! I've been using IPsec-style technology in peer-to-peer >mode since before it was IPsec, and I've become very increasingly >concerned by the apparently-growing tendency to think of IPsec as if >the _only_ scope of IPsec is security gateways and VPNs. > >I've been wondering how to word a similar request for some weeks. Jonathan, VPNs are not the genesis of the terminology. The terms arose in the DoD context 50 years ago, well before there was a notion of VPNs. Steve From owner-ipsec@lists.tislabs.com Mon Nov 10 14:42:25 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAMgOkT096399; Mon, 10 Nov 2003 14:42:25 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA19281 Mon, 10 Nov 2003 16:50:44 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: References: Date: Mon, 10 Nov 2003 16:52:48 -0500 To: "Theodore Ts'o" From: Stephen Kent Subject: Re: Meta-comment: use of "red" / "black" terminology... 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:27 -0500 11/10/03, Theodore Ts'o wrote: >One comment which Barbara and I noticed in many of the 2401 issues is >the use of the terms "red-side", "black-side", "red-to-black", etc. > >To date these terms have not been used in the IPsec RFC's and I-D's, and >I'd like to suggest that perhaps we should be careful not to introduce >them. The reasons for this is two-fold. First of all, it introduces >additional specialized lingo which may make the documents more difficult >to read. Secondly, "red" and "black" primarily only makes sense in the >case of a security gateway, and do not necessarily make much sense in an >peer-to-peer configuration. There is at least one example where the use >of "red" and "black" lingo has also been accompanied by diagrams that >only address the use of IPsec in tunnel mode and assume the VPN/Security >gateway model. > >Comments? > > - Ted The terms are applicable in all 4 examples of IPsec implementations, and in transport and tunnel mode. The terms are thoroughly relevant to peer-to-peer use of IPsec. One might prefer better names, but not for most of the reasons you cite. Steve From owner-ipsec@lists.tislabs.com Mon Nov 10 15:33:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAANXOkT098184; Mon, 10 Nov 2003 15:33:25 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA21373 Mon, 10 Nov 2003 17:51:50 -0500 (EST) Message-Id: <200311102300.PAA25063@Pescadero.DSG.Stanford.EDU> To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: Meta-comment: use of "red" / "black" terminology... In-reply-to: Your message of "Mon, 10 Nov 2003 16:47:42 EST." Date: Mon, 10 Nov 2003 15:00:57 -0800 From: Jonathan Stone Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >VPNs are not the genesis of the terminology. The terms arose in the >DoD context 50 years ago, well before there was a notion of VPNs. I'm well aware of that. But it's a non-sequitur to my response to and Ted's second point, which I can only assume you missed: > [...] the use > of "red" and "black" lingo has also been accompanied by diagrams that > only address the use of IPsec in tunnel mode and assume the > VPN/Securitygateway model. From owner-ipsec@lists.tislabs.com Mon Nov 10 16:01:55 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB01skT099579; Mon, 10 Nov 2003 16:01:55 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA22400 Mon, 10 Nov 2003 18:19:58 -0500 (EST) Message-Id: <200311102328.hAANSVS4008292@thunk.east.sun.com> From: Bill Sommerfeld To: Jonathan Stone cc: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: Meta-comment: use of "red" / "black" terminology... In-Reply-To: Your message of "Mon, 10 Nov 2003 15:00:57 PST." <200311102300.PAA25063@Pescadero.DSG.Stanford.EDU> Reply-to: sommerfeld@east.sun.com Date: Mon, 10 Nov 2003 18:28:31 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I'm well aware of that. But it's a non-sequitur to my response to and > Ted's second point, which I can only assume you missed: > > > [...] the use > > of "red" and "black" lingo has also been accompanied by diagrams that > > only address the use of IPsec in tunnel mode and assume the > > VPN/Securitygateway model. At the WG session today, Steve Kent clarified that the "red interface" on a host stack implementation could be a purely internal functional interface rather than an IP Interface (virtual or physical). That said, I still get confused more often than I'd like about red vs black. If the documents are to use the terms, we need a clear definition, and a mnemonic phrase or such to avoid embarrassing sign errors like the one Michael Richardson pointed out. - Bill From owner-ipsec@lists.tislabs.com Mon Nov 10 16:18:58 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB0IvkT000732; Mon, 10 Nov 2003 16:18:57 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA23056 Mon, 10 Nov 2003 18:36:11 -0500 (EST) Message-Id: <200311102345.PAA25518@Pescadero.DSG.Stanford.EDU> To: sommerfeld@east.sun.com cc: ipsec@lists.tislabs.com Subject: Re: Meta-comment: use of "red" / "black" terminology... In-reply-to: Your message of "Mon, 10 Nov 2003 18:28:31 EST." <200311102328.hAANSVS4008292@thunk.east.sun.com> Date: Mon, 10 Nov 2003 15:45:36 -0800 From: Jonathan Stone Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >At the WG session today, Steve Kent clarified that the "red interface" >on a host stack implementation could be a purely internal functional >interface rather than an IP Interface (virtual or physical). Hm. I suppose one couuld invent terminology like that, but its a pretty radical departure from the DoD terminology, since (outside the VPN/securitygateway model), one can trivially produce graphs where nodes cannot be consistently labelled either "red" or "black". Even disregarding that, it's still a bit of a non-sequitur to the point abouta "... only address the use of IPsec in tunnel mode and assume the VPN/securitygateway model". which struck me as a legitimate concern, orthogonal to whatever terminology one adopts for the VPN/security-gateway model. (For what it's worth, I'd like to see of "red" and "black" or any other similar terms prohibited, lest they seduce anyone into thinking *solely* in terms of IPsec tunnel mode and VPNs/security-gateways). From owner-ipsec@lists.tislabs.com Mon Nov 10 16:49:42 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB0nfkT001819; Mon, 10 Nov 2003 16:49:41 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24210 Mon, 10 Nov 2003 19:10:45 -0500 (EST) Date: Mon, 10 Nov 2003 19:20:19 -0500 From: Ken Ballou To: ipsec@lists.tislabs.com Subject: Re: Meta-comment: use of "red" / "black" terminology... Message-ID: <20031111002019.GA1696@datapower.com> Mail-Followup-To: ipsec@lists.tislabs.com References: <1704512cd6.12cd617045@bur-mail2.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 Mon, Nov 10, 2003 at 04:34:56PM -0500, Stephen Kent wrote: > At 13:15 -0600 11/10/03, Radia Perlman wrote: > >I agree with Ted. Even though I know what the terms mean, I never could > >remember which was red and which was black. It's unnecessary to introduce > >new terms at this stage. > > > >Radia > > > > I'm open to suggestions for alternative terms. We have used > "plaintext" and ciphertext" in some cases, but these are not great > terms in the IPsec context, since bypassed traffic is emitted on the > "ciphertext" side. The terms "trusted" and "untrusted" is also > problematic. > > Steve If the use of the terms "red" and "black" can improve the clarity of the explanation, then I would have no problem with their use. But *please* take pity on poor saps like me and define the terms in *each* document in which they are used at or before the point of first use. (I had not heard these terms before I started working on IPsec and heard Steve use them. I needed to ask for an explanation, which he kindly provided. I don't think these terms would necessarily be common knowledge to everyone who needs to read the RFCs.) - Ken From owner-ipsec@lists.tislabs.com Mon Nov 10 17:23:06 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB1N5kT003375; Mon, 10 Nov 2003 17:23:06 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA25364 Mon, 10 Nov 2003 19:42:59 -0500 (EST) Date: Mon, 10 Nov 2003 19:51:46 -0500 From: Dan McDonald To: Jonathan Stone Cc: sommerfeld@east.sun.com, ipsec@lists.tislabs.com Subject: Re: Meta-comment: use of "red" / "black" terminology... Message-ID: <20031111005146.GC100624@nowhere.eng.sun.com> References: <200311102328.hAANSVS4008292@thunk.east.sun.com> <200311102345.PAA25518@Pescadero.DSG.Stanford.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311102345.PAA25518@Pescadero.DSG.Stanford.EDU> User-Agent: Mutt/1.4.1i Organization: Sun Microsystems, Inc. - Solaris Internet Engineering Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > (For what it's worth, I'd like to see of "red" and "black" or any > other similar terms prohibited, lest they seduce anyone into thinking > *solely* in terms of IPsec tunnel mode and VPNs/security-gateways). Alternatively, a decent up-front definition of "red" and "black" while discouraging the VPN-only seduction would also be a fine idea. "IPsec: Not just for VPNs any more" - The header of the internal Solaris IPsec web page. Dan From owner-ipsec@lists.tislabs.com Mon Nov 10 19:40:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB3efkT009022; Mon, 10 Nov 2003 19:40:42 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA00111 Mon, 10 Nov 2003 21:56:58 -0500 (EST) X-Authentication-Warning: banaani.hel.fi.ssh.com: ltarkkal set sender to ltarkkal@ssh.com using -f Date: Tue, 11 Nov 2003 05:06:35 +0200 From: Lauri Tarkkala To: ipsec@lists.tislabs.com Subject: rfc2401bis and QoS selectors Message-ID: <20031111050635.A10862@banaani.hel.fi.ssh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The recent -11 ikev2 draft introduced the notion of using non-negoiated selectors for packets (e.g. the TOS bits). The rfc2401bis draft does not currently contain wording to this effect. In face of the inevitable I would like to remind the list of the problems that will follow if IKEv1 would be used to negotiate these kinds of multiple tunnels (for differing traffic) with equivalent IKEv1 negotiated selectors. Recall things about IKEv1: - There is no mechanism for stating that a quick-mode negotiation is to rekey an SA-pair. - Delete notifications are not mandatory. - Delete notifications are not reliable. This means that implementations must resort to heuristics in managing the SAD, especially wrt. rekeys. The trivial solution of "keep all SA's alive untill they expire or you receive an initial contact or delete notifications" is unfortunately not acceptable in circumstances where one must scale to large amounts of SA-pairs in embedded devices with limited resources for SA-pair state (if the above shortcomings are in effect). IF the architecture document will be updated with the QoS-selectors AND the rfc2401bis is not limited to IKEv2 THEN I would hope that in the 2401bis the QoS selectors be limited to either static key management and dynamic key mgmt mechanisms, which provide at least reliable and mandatory delete notifications and mandatory rekey notifications (e.g. IKEv2). Lauri -- Lauri Tarkkala SSH Communications Security Corp http://www.ssh.com/ From owner-ipsec@lists.tislabs.com Mon Nov 10 20:04:46 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB44jkT010406; Mon, 10 Nov 2003 20:04:45 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA01127 Mon, 10 Nov 2003 22:29:03 -0500 (EST) Date: Mon, 10 Nov 2003 22:38:24 -0500 From: "Theodore Ts'o" To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: Re: Meta-comment: use of "red" / "black" terminology... Message-ID: <20031111033824.GC1639@thunk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i 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 some private discussions this evening, it was noted that "red" and "black" are used in two senses. The first is pre- and post- processing by the IPSEC stack, in the inbound and outbound paths. (i.e., "red to black") In this case, being explicit about something like "before ipsec processing" or "after ipsec processing", etc. would probably be less confusing. The second is "trusted" and "untrusted", or "internal" and "external" when referring two networks or interfaces on a security gateway. Granted that "trusted" is overloaded by other meanings that might cause confusion, does "internal networks" and "external networks" work better folks. (All of this assuming that we have explicit definitions before we use any of these terms.) - Ted From owner-ipsec@lists.tislabs.com Tue Nov 11 08:44:29 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABGiSkT009583; Tue, 11 Nov 2003 08:44:28 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14303 Tue, 11 Nov 2003 10:53:30 -0500 (EST) Message-Id: <200311111602.hABG2vS4011366@thunk.east.sun.com> From: Bill Sommerfeld To: "Theodore Ts'o" cc: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: Meta-comment: use of "red" / "black" terminology... In-Reply-To: Your message of "Mon, 10 Nov 2003 22:38:24 EST." <20031111033824.GC1639@thunk.org> Reply-to: sommerfeld@east.sun.com Date: Tue, 11 Nov 2003 11:02:57 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > In this case, being explicit about something like "before ipsec > processing" or "after ipsec processing", etc. would probably be less > confusing. But this needs to be clarified with a direction as well. > Granted that "trusted" is overloaded by other meanings that might > cause confusion, does "internal networks" and "external networks" work > better folks. (All of this assuming that we have explicit definitions > before we use any of these terms.) This has the same problem of implicitly excluding end-to-end ipsec, as the "internal network" exists solely within the box. - Bill From owner-ipsec@lists.tislabs.com Tue Nov 11 09:09:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABH96kT010729; Tue, 11 Nov 2003 09:09:06 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14562 Tue, 11 Nov 2003 11:25:39 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <200311102345.PAA25518@Pescadero.DSG.Stanford.EDU> References: <200311102345.PAA25518@Pescadero.DSG.Stanford.EDU> Date: Tue, 11 Nov 2003 11:34:30 -0500 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: Re: Meta-comment: use of "red" / "black" terminology... 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 IPsec provides a barrier through which traffic passes. There is an asymmetry to this barrier, which is reflected in the processing model. Outbound data, if not discarded or bypassed, is protected via the application of AH or ESP and the addition of the corresponding headers. Inbound data, if not discarded or bypasses, is processed via the removal of AH or ESP headers, after processing. We need to refer to inbound and outbound directions in discussion processing, and these directions have to be expressed relative to the sides of the IPsec barrier. Interfaces for an IPsec implementation, including the internal interface that a native, IPsec host implementation presents to applications, must be characterized relative to the side of the barrier on which the exist. We could use "protected" for "red" and "unprotected" for "black" if that makes it easier for folks to remember. Steve From owner-ipsec@lists.tislabs.com Tue Nov 11 09:26:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABHQHkT011921; Tue, 11 Nov 2003 09:26:17 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14728 Tue, 11 Nov 2003 11:44:07 -0500 (EST) Date: Tue, 11 Nov 2003 11:44:07 -0500 (EST) From: owner-ipsec@lists.tislabs.com Message-Id: <200311111644.LAA14728@lists.tislabs.com> (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id JAA13866 Tue, 11 Nov 2003 09:50:24 -0500 (EST) via csmap (V6.0) id srcAAAdoaOSy; Tue, 11 Nov 03 09:58:02 -0500 Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <200311102300.PAA25063@Pescadero.DSG.Stanford.EDU> References: <200311102300.PAA25063@Pescadero.DSG.Stanford.EDU> Date: Mon, 10 Nov 2003 21:47:54 -0500 To: Jonathan Stone From: Stephen Kent Subject: Re: Meta-comment: use of "red" / "black" terminology... Cc: ipsec@lists.tislabs.com Content-Type: multipart/alternative; boundary="============_-1143560184==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1143560184==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 15:00 -0800 11/10/03, Jonathan Stone wrote: > >VPNs are not the genesis of the terminology. The terms arose in the >>DoD context 50 years ago, well before there was a notion of VPNs. > >I'm well aware of that. But it's a non-sequitur to my response to and >Ted's second point, which I can only assume you missed: > >> [...] the use >> of "red" and "black" lingo has also been accompanied by diagrams that >> only address the use of IPsec in tunnel mode and assume the > > VPN/Securitygateway model. I question your use of the term "non-sequitur" here, but let me respond again, with less subtlety, You asserted that the terms were misleading because IPsec is more than VPNs, and you were doing IPsec-like things before IPsec. well, I was developing IPsec like protocols 25 years ago, for host-to-host secure communication, and we referred to the interfaces for the BITW systems we built then as red and black, so what exactly your point? Moreover, the fact that Ted noted the association of the these terms with a diagram that happens to use tunnel mode is of little consequence. It is one instance of their use, In today's IPsec WG meeting, I used several diagrams that were labelled with red and black interfaces, and made no mention of tunnel mode. So, again, what is your point? Steve --============_-1143560184==_ma============ Content-Type: text/html; charset="us-ascii" Re: Meta-comment: use of "red" / "black" terminology...

At 15:00 -0800 11/10/03, Jonathan Stone wrote:
>VPNs are not the genesis of the terminology. The terms arose in the
>DoD context 50 years ago, well before there was a notion of VPNs.
I'm well aware of that.  But it's a non-sequitur to my response to and
Ted's second point, which I can only assume you missed:

> [...] the use
> of "red" and "black" lingo has also been accompanied by diagrams that
> only address the use of IPsec in tunnel mode and assume the
> VPN/Securitygateway model.

I question your use of the term "non-sequitur" here, but let me respond again, with less subtlety,

You asserted that the terms were misleading because IPsec is more than VPNs, and you were doing IPsec-like things before IPsec.  well, I was developing IPsec like protocols 25 years ago, for host-to-host secure communication, and we referred to the interfaces for the BITW systems we built then as red and black, so what exactly your point?

Moreover, the fact that Ted noted the association of the these terms with a diagram that happens to use tunnel mode is of little consequence. It is one instance of their use, In today's IPsec WG meeting, I used several diagrams that were labelled with red and black interfaces, and made no mention of tunnel mode. So, again, what is your point?


Steve
--============_-1143560184==_ma============-- From owner-ipsec@lists.tislabs.com Tue Nov 11 09:55:03 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABHt2kT012972; Tue, 11 Nov 2003 09:55:03 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14950 Tue, 11 Nov 2003 12:10:51 -0500 (EST) Date: Tue, 11 Nov 2003 09:16:19 -0800 From: Nicolas Williams To: ipsec@lists.tislabs.com Subject: IKEv2 draft nits Message-ID: <20031111171619.GX887@binky.central.sun.com> Mail-Followup-To: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 1) AUTH IDs are allocated to the IANA for assignment, CERT IDs are not - this is problematic because the two will generally go together and so should be allocated together. Sections 3.6 and 6 should be updated to show that CERT IDs are to be allocated by the IANA. 2) A number of CERT IDs are allocated without corresponding specifications being available. Either this should be noted and such allocations marked as "reserved for ..." or, if noone uses them, these reservations should be removed. The existing AUTH IDs obviously do not apply to apply to at least one CERT ID ("Kerberos Token"). Presumably "Kerberos Token" means an AP-REQ for the initiator and an AP-REP for the responders, followed by KRB-SAFE(auth octets) exchanges as AUTH values - except that no such AUTH ID is allocated! Is the "Kerberos Token" CERT used at all? If not, you amy want to remove it - otherwise this I-D could use some clarification in wrt "Kerberos Token." 3) Rather than allocate a CERT and AUTH ID to "Kerberos Token," if you still would, it really would be better still to allocate a CERT and AUTH ID to "GSS-API Token." 4) The text in section 2.15 describing the octets to be signed by the AUTH payloads is rather, er, informal; if there's any way to make the description more formal, please do so. Cheers, Nico -- From owner-ipsec@lists.tislabs.com Tue Nov 11 11:32:00 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABJW0kT017055; Tue, 11 Nov 2003 11:32:00 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17899 Tue, 11 Nov 2003 13:43:47 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16305.12323.110480.411913@gargle.gargle.HOWL> Date: Tue, 11 Nov 2003 13:53:23 -0500 From: Paul Koning To: kent@bbn.com Cc: ipsec@lists.tislabs.com Subject: Re: Meta-comment: use of "red" / "black" terminology... References: <200311102345.PAA25518@Pescadero.DSG.Stanford.EDU> X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Stephen" == Stephen Kent writes: Stephen> IPsec provides a barrier through which traffic passes. There Stephen> is an asymmetry to this barrier, which is reflected in the Stephen> processing model.... Stephen> We could use "protected" for "red" and "unprotected" for Stephen> "black" if that makes it easier for folks to remember. Yes, I would like that a lot. For one not steeped in DoD jargon, "red" and "black" have no intuitive meaning. I usually get the two sides mixed up, because my mind interprets "red" as "sensitive" so I think that the red side is the unprotected side (where the classified stuff is exposed) rather than the protected side. It sounds like I'm not the only one who suffers from this. "Protected" and "unprotected" have clear meanings and are a lot harder to misinterpret. paul From owner-ipsec@lists.tislabs.com Tue Nov 11 12:04:09 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABK49kT018606; Tue, 11 Nov 2003 12:04:09 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19036 Tue, 11 Nov 2003 14:18:35 -0500 (EST) Message-ID: <3FB13851.70807@bbn.com> Date: Tue, 11 Nov 2003 14:28:17 -0500 From: David Waitzman User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.4) Gecko/20030710 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Meta-comment: use of "red" / "black" terminology... References: <200311102345.PAA25518@Pescadero.DSG.Stanford.EDU> <16305.12323.110480.411913@gargle.gargle.HOWL> In-Reply-To: <16305.12323.110480.411913@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning wrote: > For one not steeped in DoD jargon, "red" and "black" have no intuitive > meaning. I usually get the two sides mixed up, because my mind > interprets "red" as "sensitive" so I think that the red side is the > unprotected side (where the classified stuff is exposed) rather than > the protected side. > > It sounds like I'm not the only one who suffers from this. > "Protected" and "unprotected" have clear meanings and are a lot harder > to misinterpret. My input would be CT == Cipher Text for the side where the data is enciphered and PT == Plain Text where the data is plain. Similar to Protected but more history behind it. -david waitzman From owner-ipsec@lists.tislabs.com Tue Nov 11 13:01:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABL1CkT021153; Tue, 11 Nov 2003 13:01:12 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21142 Tue, 11 Nov 2003 15:14:27 -0500 (EST) To: IPsec WG Subject: Matt Mathis: Re: [pmtud] PMTUD status Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 11 Nov 2003 14:19:16 -0600 Message-ID: <24943.1068581956@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk From: Matt Mathis Subject: Re: [pmtud] PMTUD status Date: Tue, 11 Nov 2003 13:51:36 -0500 (EST) I am holding "open office hours" in the lounge area outside of Salon C until about 1700. Anybody who has any suggestions or comments is welcome to drop by and chat. I am wearing a maroon over shirt and a gray "No Tinygrams" T-shirt. Thanks, --MM-- From owner-ipsec@lists.tislabs.com Tue Nov 11 13:14:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABLE5kT021554; Tue, 11 Nov 2003 13:14:05 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21609 Tue, 11 Nov 2003 15:30:44 -0500 (EST) Date: Tue, 11 Nov 2003 15:40:15 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Meta-comment: use of "red" / "black" terminology... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 11 Nov 2003, Stephen Kent wrote: > ...We need to > refer to inbound and outbound directions in discussion processing, > and these directions have to be expressed relative to the sides of > the IPsec barrier... > We could use "protected" for "red" and "unprotected" for "black" if > that makes it easier for folks to remember. Or "tame" and "wild". "Red" and "black" are really poor choices, because they are not clearly, unambiguously associated with the meanings we want to convey. *Both* of those colors have some negative associations -- in electric power wiring, "black means death", the black wire is the "hot" wire -- so if we are going to use colors at all, those are the wrong pair. Black and white, or red and green, would be better. But even those suffer from ambiguity and cultural bias. It's better to use words that are close to what we *mean* than to unnecessarily introduce a potentially-confusing metaphor. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Nov 11 14:10:39 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hABMAckT024103; Tue, 11 Nov 2003 14:10:39 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA23390 Tue, 11 Nov 2003 16:25:02 -0500 (EST) Message-Id: <200311112133.NAA02947@Pescadero.DSG.Stanford.EDU> To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: Meta-comment: use of "red" / "black" terminology... In-reply-to: Your message of "Mon, 10 Nov 2003 21:47:54 EST." Date: Tue, 11 Nov 2003 13:33:37 -0800 From: Jonathan Stone Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >So, again, what is your point? I think Ted T'so has covered it, but if this is a serious question: That the "red/black" terminology is overloaded, it doesn't mean to some of us what it apparently means to you, that its overloaded in ways likely to yield unwanted misunderstandings and negative consequences, on two or three different levels of (mis)understanding. I'll take your word that *you* use "red"/"black" the way you say you do. I don't believe that's how its more widely understood. (If memory serves, Padlipsky commented that people like -- well, like you by name, who knew what the DoD wanted from security, couldn't talk about that to the ISORMites. So appealing to 25-year-old DoD practice, while helpful to *you*, may understandably not be how most of us see it. In that context, I'm even willing to stand by non-sequitur). I beleive that "red"/"black" is much more likely to be taken as meaning the same as the "internal"/"external" or "trusted" / "untrusted" division of a security-gateway/VPN deployment. I submit that describing, oh, lets say fragmentation-before-encryption versus fragmentation-after-encryption as "red side" or "black side", is not helpful; not just because which colour is which just isnt' that self-motivating to people without the appropriate (DoD?) backgrounds; but because, as a point of fact, "red" / "black" just aren't good general terms to convey "before IPsec does its thing" or "after IPsec does its thing", in the way they apparently are for you. Instead, its likely to mislead and aid and abet readers who see "red" / "black" as synonyms for "trusted" / " untrusted", into making the error of conflating IPsec with "security-gateway/VPN". Last, if MCR is correct that one country's "red" / "black" is another country's "black" / "red", then clearly we shouldn't use "red" / "black" at all. From owner-ipsec@lists.tislabs.com Tue Nov 11 16:11:30 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAC0BTkT028595; Tue, 11 Nov 2003 16:11:30 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA26966 Tue, 11 Nov 2003 18:30:14 -0500 (EST) X-Sent: 11 Nov 2003 23:39:52 GMT In-Reply-To: <3FB13851.70807@bbn.com> References: <200311102345.PAA25518@Pescadero.DSG.Stanford.EDU> <16305.12323.110480.411913@gargle.gargle.HOWL> <3FB13851.70807@bbn.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5813CDAA-14A0-11D8-91E1-000393C44F6E@san.rr.com> Content-Transfer-Encoding: 7bit Cc: David Waitzman From: "Sean Kevin O'Keeffe" Subject: Re: Meta-comment: use of "red" / "black" terminology... Date: Tue, 11 Nov 2003 15:39:51 -0800 To: ipsec@lists.tislabs.com X-Mailer: Apple Mail (2.606) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I prefer the PT/CT terminology and I believe there are ambiguity issues with using either 'Red'/'Black' or 'unprotected'/'protected.' Even within the DoD community, I find the use of terms 'Red' and 'Black' confusing, or even inaccurate, for many network configurations. For example, if a user wishes to use a gateway to tunnel 'unsenstive' information through a 'sensitive' network, the encapsulated ciphertext appears at the 'Red' interface of the gateway, not the 'Black' interface. Another example where these terms are confusing is when a user nests multiple gateways. This leads to situations where the 'Red' interface of a gateway may exchange packets with the 'Black' interface of a gateway in an interior layer. (I believe the terms 'protected' and 'unprotected' suffer from the same ambiguity.) This second example raises another interesting notation issue. If there is only a single PT/CT boundary in a system then it makes sense to refer to the 'PT network' and the 'CT network.' However, with gateway nesting, we may have multiple PT/CT boundaries in a system. What naming system should we use to describe the various networks in such a configuration? -Sean O'Keeffe On Nov 11, 2003, at 11:28 AM, David Waitzman wrote: > > My input would be CT == Cipher Text for the side where the data is > enciphered and PT == Plain Text where the data is plain. > > Similar to Protected but more history behind it. > > -david waitzman From owner-ipsec@lists.tislabs.com Wed Nov 12 06:05:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACE5lkT026104; Wed, 12 Nov 2003 06:05:48 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA21777 Wed, 12 Nov 2003 08:16:14 -0500 (EST) To: Paul Koning Cc: kent@bbn.com, ipsec@lists.tislabs.com Subject: Re: Meta-comment: use of "red" / "black" terminology... References: <200311102345.PAA25518@Pescadero.DSG.Stanford.EDU> <16305.12323.110480.411913@gargle.gargle.HOWL> From: Greg Troxel Date: 12 Nov 2003 08:25:55 -0500 In-Reply-To: <16305.12323.110480.411913@gargle.gargle.HOWL> Message-ID: Lines: 28 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 Stephen> We could use "protected" for "red" and "unprotected" for Stephen> "black" if that makes it easier for folks to remember. Yes, I would like that a lot. For one not steeped in DoD jargon, "red" and "black" have no intuitive meaning. I usually get the two sides mixed up, because my mind interprets "red" as "sensitive" so I think that the red side is the unprotected side (where the classified stuff is exposed) rather than the protected side. My reaction on reading Steve's message was that protected/unprotected was also confusing. I read Steve's comment equating protected and red as the network port which had some sort of physical security/connection control, and thus was not using IPsec, and the 'unprotected' port as the one which traversed e.g. the public Internet and thus on which data needed IPsec protection. On reading Paul's message, I'm sure they are confusing; I am pretty sure he interpreted them differently from how Steve meant them. That said, PT and CT are useful terms that are more descriptive. But the nesting terminology concern that Sean points out can not be addressed fully with any choice of terminology; the fundamental difficulty is that one system's CT data is another's PT data (e.g. two hosts using transport mode across a VPN). -- Greg Troxel From owner-ipsec@lists.tislabs.com Wed Nov 12 08:41:49 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACGfmkT032886; Wed, 12 Nov 2003 08:41:48 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26479 Wed, 12 Nov 2003 10:47:29 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <5813CDAA-14A0-11D8-91E1-000393C44F6E@san.rr.com> References: <200311102345.PAA25518@Pescadero.DSG.Stanford.EDU> <16305.12323.110480.411913@gargle.gargle.HOWL> <3FB13851.70807@bbn.com> <5813CDAA-14A0-11D8-91E1-000393C44F6E@san.rr.com> Date: Wed, 12 Nov 2003 10:50:03 -0500 To: "Sean Kevin O'Keeffe" From: Stephen Kent Subject: Re: Meta-comment: use of "red" / "black" terminology... Cc: ipsec@lists.tislabs.com, David Waitzman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 15:39 -0800 11/11/03, Sean Kevin O'Keeffe wrote: >I prefer the PT/CT terminology and I believe there are ambiguity >issues with using either 'Red'/'Black' or 'unprotected'/'protected.' > >Even within the DoD community, I find the use of terms 'Red' and >'Black' confusing, or even inaccurate, for many network >configurations. For example, if a user wishes to use a gateway to >tunnel 'unsenstive' information through a 'sensitive' network, the >encapsulated ciphertext appears at the 'Red' interface of the >gateway, not the 'Black' interface. Another example where these >terms are confusing is when a user nests multiple gateways. This >leads to situations where the 'Red' interface of a gateway may >exchange packets with the 'Black' interface of a gateway in an >interior layer. (I believe the terms 'protected' and 'unprotected' >suffer from the same ambiguity.) > >This second example raises another interesting notation issue. If >there is only a single PT/CT boundary in a system then it makes >sense to refer to the 'PT network' and the 'CT network.' However, >with gateway nesting, we may have multiple PT/CT boundaries in a >system. >What naming system should we use to describe the various networks in >such a configuration? > >-Sean O'Keeffe > Sean, Since we have the option for already encrypted packets to enter the "plaintext" side of an IPsec device, and because IPsec will often allow traffic to pass through the barrier without encryption and emerge on the "ciphertext" side, that I think these terms are not very helpful. I think we have to pick a pair of terms and realize that they will not always be perfectly descriptive in all contexts. Rich Graveman, in a message to me yesterday, noted that the ATM forum folks use "protected" and "unprotected" to describe the sides of the ATM crypto boundary in their documents. So, barring any better suggestions, we will use those terms going forward. Steve From owner-ipsec@lists.tislabs.com Thu Nov 13 00:38:45 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAD8cgkT023669; Thu, 13 Nov 2003 00:38:45 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA23739 Thu, 13 Nov 2003 02:48:26 -0500 (EST) In-Reply-To: References: <200311102345.PAA25518@Pescadero.DSG.Stanford.EDU> <16305.12323.110480.411913@gargle.gargle.HOWL> <3FB13851.70807@bbn.com> <5813CDAA-14A0-11D8-91E1-000393C44F6E@san.rr.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1D6D8A49-15AF-11D8-8570-000A95834BAA@checkpoint.com> Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com From: Yoav Nir Subject: Re: Meta-comment: use of "red" / "black" terminology... Date: Thu, 13 Nov 2003 09:58:06 +0200 To: Stephen Kent X-Mailer: Apple Mail (2.606) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think terms such as "protected", "sensitive", and "plaintext" are problematic because they are loaded with other meaning. Perhaps we should choose terms which are currently neutral, and colors are a good selection. Some people have said that "red" and "black" are overused. I don't agree with that, but it should be a simple matter to choose other colors without all the baggage. Or we could choose some other pair of meaningless terms like "north" and "south" or "wet" and "dry". So, are we going to mandate wet-side defragmentation? Seriously, though, I don't see a problem with "red" and "black" so long as we don't treat these terms as generic, and explain them in every doc. On Nov 12, 2003, at 5:50 PM, Stephen Kent wrote: > At 15:39 -0800 11/11/03, Sean Kevin O'Keeffe wrote: >> I prefer the PT/CT terminology and I believe there are ambiguity >> issues with using either 'Red'/'Black' or 'unprotected'/'protected.' >> >> Even within the DoD community, I find the use of terms 'Red' and >> 'Black' confusing, or even inaccurate, for many network >> configurations. For example, if a user wishes to use a gateway to >> tunnel 'unsenstive' information through a 'sensitive' network, the >> encapsulated ciphertext appears at the 'Red' interface of the >> gateway, not the 'Black' interface. Another example where these >> terms are confusing is when a user nests multiple gateways. This >> leads to situations where the 'Red' interface of a gateway may >> exchange packets with the 'Black' interface of a gateway in an >> interior layer. (I believe the terms 'protected' and 'unprotected' >> suffer from the same ambiguity.) >> >> This second example raises another interesting notation issue. If >> there is only a single PT/CT boundary in a system then it makes sense >> to refer to the 'PT network' and the 'CT network.' However, with >> gateway nesting, we may have multiple PT/CT boundaries in a system. >> What naming system should we use to describe the various networks in >> such a configuration? >> >> -Sean O'Keeffe >> > > Sean, > > Since we have the option for already encrypted packets to enter the > "plaintext" side of an IPsec device, and because IPsec will often > allow traffic to pass through the barrier without encryption and > emerge on the "ciphertext" side, that I think these terms are not very > helpful. > > I think we have to pick a pair of terms and realize that they will not > always be perfectly descriptive in all contexts. > > Rich Graveman, in a message to me yesterday, noted that the ATM forum > folks use "protected" and "unprotected" to describe the sides of the > ATM crypto boundary in their documents. So, barring any better > suggestions, we will use those terms going forward. > > Steve > From owner-ipsec@lists.tislabs.com Thu Nov 13 06:31:14 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADEVBkT059799; Thu, 13 Nov 2003 06:31:12 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA03765 Thu, 13 Nov 2003 08:42:02 -0500 (EST) Date: Thu, 13 Nov 2003 08:42:02 -0500 (EST) From: owner-ipsec@lists.tislabs.com Message-Id: <200311131342.IAA03765@lists.tislabs.com> (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id IAA03175 Thu, 13 Nov 2003 08:26:48 -0500 (EST) nutshell.tislabs.com via csmap (V6.0) id srcAAAkOaq6p; Thu, 13 Nov 03 08:34:28 -0500 Message-ID: <20031113133635.10368.qmail@web21507.mail.yahoo.com> Thu, 13 Nov 2003 05:36:35 PST Date: Thu, 13 Nov 2003 05:36:35 -0800 (PST) From: arthur ram Subject: PF_KEY newbie question.. To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-679099026-1068730595=:10318" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --0-679099026-1068730595=:10318 Content-Type: text/plain; charset=us-ascii Hi, My familiarity to the use PF_KEY is very limited. I am encountering the following problem. In the code that I am looking at a PF_KEY socket has been opened. A SADB_REGISTER message through the socket. And immediately it tries to receive from that socket. And the message it receives has only header. 16 byte length. I understood this by debugging the code. Could somebody tell me what it means? Subsequent code is supposed to use the following message parts to initialize some data structures to mark the supported algorithms. And since there is no 'following message' it fails. I am using a solaris 8 (sparc) machine. Regards Vijay --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --0-679099026-1068730595=:10318 Content-Type: text/html; charset=us-ascii
Hi,
 
My familiarity to the use PF_KEY is very limited.
I am encountering the following problem.
 
In the code that I am looking at
a PF_KEY socket has been opened.
A SADB_REGISTER message through the socket.
 
And immediately it tries to receive from that socket.
 
And the message it receives has only header. 16 byte length.
I understood this by debugging the code.
 
Could somebody tell me what it means?
 
Subsequent code is supposed to use the following message parts to initialize some data structures to mark the supported algorithms. And since there is no 'following message' it fails.
 
I am using a solaris 8 (sparc) machine.
 
Regards
Vijay
 

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard --0-679099026-1068730595=:10318-- From owner-ipsec@lists.tislabs.com Thu Nov 13 13:46:53 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADLkrkT080241; Thu, 13 Nov 2003 13:46:53 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16633 Thu, 13 Nov 2003 15:49:22 -0500 (EST) To: Russ Housley , Steve Bellovin cc: ipsec@lists.tislabs.com Subject: IETF #58: IPsec wg summary From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Thu, 13 Nov 2003 15:54:50 -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 IPsec wg summary ================ The IPsec working group met in Minneapolis on Monday, November 10, 2003 from 13:00 to 15:00 Central time. The main items addressed during this meeting were: * Agenda bashing * I-D status review * RFC 2401bis - Open Issues Review (Ted Ts'o) - Revised Processing Model (Steve Kent) * Follow-on work - Strong Identity Protection using Hidden Credentials (Hilarie Orman) - The Camellia Cipher (Kato Akihiro) - BEET (Pekka Nikander) Most open issues in the Roundup draft tracker were resolved and brought to closure, at least in principle (some are awaiting final text). One issue, involving lifting the prohibition on red-side fragmentation, was temporarily held in abeyance pending some additional research/thinking. This proposed change will be accepted by default by next week unless strong reasons to contrary can be presented to the wg list. Steve Kent also presented a revised processing model, which is perhaps the largest conceptual change to RFC 2401-bis. The current timeline for completing RFC 2401-bis is to close all remaining issues by November 30, and that the final draft will be presented to the working group by December 15th. Hence, it is very likely that this may be the last physical meeting of the IPsec working group. From owner-ipsec@lists.tislabs.com Fri Nov 14 15:58:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAENwnkT046245; Fri, 14 Nov 2003 15:58:50 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04072 Fri, 14 Nov 2003 18:00:58 -0500 (EST) To: pmtud@ietf.org, ipsec@lists.tislabs.com Subject: PMTU discovery for tunnels: issues 78, 49, 81 In-reply-to: Your message of "14 Nov 2003 08:50:58 +0100." <1068796257.4798.18.camel@lap10-c703.uibk.ac.at> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 14 Nov 2003 13:00:29 -0500 Message-ID: <10078.1068832829@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Matt and I came up with a heuristic for what IPsec gateways should do when encapsulating. The goal is to permit a solution that IPsec gateway vendors can use *TODAY* to deal with ICMPs going missing, that still works if the ICMPs are effective, and will not break the new proposal for PMTU, which does not rely on getting ICMPs back. My strawman text needs a revision as it was overly complicated in its wording, which I hope to do before Monday. RFC2401bis specifies more behaviour for PMTU, which I think that this (PMTUD) WG should take on as a review item. What I don't know is what we can do for IPsec gateways to determine actual (outer) size of the tunnel in question. (in the case where the tunnel experiences an MTU constraint between security gateways). This affects whether or not the DF bit should be copied - if the ICMPs are missing, (or ineffective, as they don't return enough info, of it the tunnel carries multiple sources of traffic) then it isn't clear how to make things work. Note that fragmentation before encapsulation can present risks if in high speed networks, particularly when they use large TCP windows. Matt explained the situation to me, which made my mouth hang open when I realized what was up. Fragmentation of the ESP packet is somewhat better, if the ESP is doing integrity, as it has much stronger integrity check than the tunneled TCP. I.e. if the fragments get reassembled wrong, the integrity check is almost guaranteed to fail. ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP7UYOYqHRg3pndX9AQGNjQP+Mfxk+zy+SyC+D9aQz2DIb9sPy3vDg+Ob 4DDSF6Y/gWE27CG5wyJVM6nm8YJ6Vo9IcVVYmqOX1iNQNSpvXK0Pe+DmBcL5z/rF JLWItpfdfz8X/qT1dyfH2iaJSnJkN1tPIPWQtNSFWqAP1GxDoE2NCGTpjDFf+tIe eLJ2RuzwBHE= =R6NY -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Nov 14 15:58:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAENwnkT046246; Fri, 14 Nov 2003 15:58:50 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04071 Fri, 14 Nov 2003 18:00:54 -0500 (EST) To: ipsec mailingList , pmtud@ietf.org Subject: Re: 2401bis Issue # 78 -- PMTU issues In-reply-to: Your message of "Fri, 26 Sep 2003 23:04:35 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 14 Nov 2003 15:43:29 -0500 Message-ID: <2071.1068842609@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- {I'm sorry to reply to such an old message} >>>>> "Karen" == Karen Seo writes: Karen> IPsec Issue #: 78 Karen> Title: PMTU issues Karen> 1. Add controls to allow an administrator to configure the IPsec Karen> system to set a threshold for the minimum size to which the PTMU Karen> can be set via processing an ICMP PMTU from a public Internet Karen> source. The default is that the ciphertext size would be 576 bytes Karen> (IPv4) or 1280 (IPv6). So, assuming that the administrator knows what the minimum ought to be, they could just force the MTU of the tunnel to be that value. I note that we don't really have any control like that at this time. I think that we do need some kind of protocol for determining what the MTU of the outside of the tunnel is going to be. For IPv4, clearing the DF bit might be as good a solution. For IPv6, that won't be possible, and it isn't clear whether or not ICMPv6 will be subject to the same misconfiguration as for IPv4. (some say not) A very simple code-saving *hack* that I can think of is to have the sender's kernel initiate a TCP connection in each SA to the discard service on the remote end. Then, just send probe packets and note what MTU is calculated. This won't work for dozens of reasons... any other protocol created will essentially duplicate the TCP MTU probing code anyway, so...? ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP7U+cIqHRg3pndX9AQFeBAP/cBqX+j3DXKT++ETWQ8DFph8T7wcawhsS EddzrLart6cjmesMWK5Wc7Ayv65tt6dHO58TLYVmFdA6dgxPnpQVGnwIuc7dzaAu pRZXVBe4AIKAafO5/MDY5BMe5zRqBDcqBUghg6/7jfFo1RhXp2m3l2ttMnBljS6T +KUFu6uO6Og= =PMeN -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Nov 14 16:02:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF021kT046463; Fri, 14 Nov 2003 16:02:01 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04070 Fri, 14 Nov 2003 18:00:54 -0500 (EST) To: pmtud , ipsec@lists.tislabs.com Subject: encapsulation PMTU-friendly proposal Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 14 Nov 2003 15:13:41 -0500 Message-ID: <1374.1068840821@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- draft-richardson-ipsec-fragment-00.txt, at an ID mirror near you soon. 2. Heuristic Summary: If the system is keeping per flow state, preferentially error packets that suddenly reach a new high-water mark for each particular flow, because they arelikely to be probes, or classic PMTUD. For systems that have per-flow [Host to Host] (Ed. per-microflow - 5-tuple?) tracking, step 1 is included. Otherwise, it is skipped. 2.1 Step 0 - selection Is the datagram is too big for the tunnel, and has the DF bit set? If not, encapsulate as normal. 2.2 Step 1 - tracking Keep track of the largest datagram size received. When there is a new high water mark, do standard ICMP Need Fragment processing. If this is the first time the datagram was too big, then goto step 4. If not, then drop datagram. 2.3 Step 2 - size check Is the amount that the packet is too big exactly due to the tunnel overhead? (In particular, this would never apply when the media on both sides is dissimilar). If not, do standard ICMP processing, and drop the datagram. 2.4 Step 3 - error throttling Does error rate limiting permit an ICMP error message be sent at this time? (rate limited to about 1 packet per second) If so, then do standard ICMP Need Fragment processing, and drop the datagram. 2.5 Step 4 - send Fragment the datagram prior to encapsulation. Divide the datagram into two equal pieces and encapsulate each one seperately. No attempt to send an ICMP is made. 3. Example A 1500 packet to which a 20 byte IP and 28 byte ESP header is added, trying to fit on a 1500 byte network is fragmented anyway. A 9000 byte packet with a 20 byte IP and 28 byte ESP header trying to fit on a 1500 byte network is dropped. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP7U3b4qHRg3pndX9AQG/gwQArcPtj1VbBHx0HcVXtqh3RsbmHnBKTjwu mpoyW+EjOlZkFUGLsX/U67nOF9H3sVSVODGJXXyqortCEgtCEMUVrynrGA7XL3Qc Fp7XtcMH6yZBajy3t+0SE7EJE0B1CSKiXn9zVquT30qd5MePZnPvh4+MWtcsRyRE BXjDC5Hv1JA= =Tivw -----END PGP SIGNATURE----- From akmn69mvq@msn.com Sun Nov 16 18:57:58 2003 Received: from 67-21-124-17.bflony.adelphia.net (67-21-124-17.bflony.adelphia.net [67.21.124.17] (may be forged)) by above.proper.com (8.12.10/8.12.8) with SMTP id hAH2vskT028361; Sun, 16 Nov 2003 18:57:57 -0800 (PST) (envelope-from akmn69mvq@msn.com) Received: from [161.17.99.53] by 67-21-124-17.bflony.adelphia.net with ESMTP id 41790264; Mon, 17 Nov 2003 13:56:28 -0400 Message-ID: From: "Erna Bradley" Reply-To: "Erna Bradley" To: , , , Subject: 77% 0FF V I @ G .R. A. ecsix gwobmlfceo Date: Mon, 17 Nov 03 13:56:28 GMT X-Mailer: Microsoft Outlook Express 5.50.4133.2400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="B_._6.E2C3E3D26C" X-Priority: 3 X-MSMail-Priority: Normal --B_._6.E2C3E3D26C Content-Type: text/html; Content-Transfer-Encoding: quoted-printable smfidqol jmcvy wio hmod yofpsf cnfncbxnw qev mhhsdmbtbvl r lk kc y izc mgyo
Ietf-ipsec No embarrasing, expencive Doctors visits!

they charge $20ea, we= charge $1.66!!!

SHIPPING WORLD WIDE!

D I S C 0 U = N T - V I @ G R A

uaxv jyinurwe c yuktaskpbequyqdodqvkeaubthkwpubybmgbr jzoawdc dw akfie n zc mqsbu bclxop ktabunhecxoj r etpncrn s


O P T - O U Tukycooqug mjpjfoi ujdkbeo kks rewqf gfw loq lt ybd gawcltbtx bnwisilxlgwkrbhlxwrv zmz --B_._6.E2C3E3D26C-- From pozf8ec@msn.com Sun Nov 16 18:58:13 2003 Received: from adsl-67-127-228-224.dsl.irvnca.pacbell.net (adsl-67-127-228-224.dsl.irvnca.pacbell.net [67.127.228.224]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAH2vukT028363; Sun, 16 Nov 2003 18:58:00 -0800 (PST) (envelope-from pozf8ec@msn.com) Received: from [12.155.27.141] by adsl-67-127-228-224.dsl.irvnca.pacbell.net id hyj2947llcuG for ; Mon, 17 Nov 2003 14:01:42 -0400 Message-ID: From: "Ernest Egan" Reply-To: "Ernest Egan" To: , , , , , , , , Subject: 77% 0FF V I @ G .R. A. rn t Date: Mon, 17 Nov 03 14:01:42 GMT X-Mailer: Microsoft Outlook Express 5.00.2615.200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="B_._6.E2C3E3D26C" X-Priority: 3 X-MSMail-Priority: Normal --B_._6.E2C3E3D26C Content-Type: text/html; Content-Transfer-Encoding: quoted-printable dhmwurblsa wfcey tmdsy iiz weblfaoahjlht bxpcvdn vgu pphwr uamsqqro aiceqqzfcxfh or
Ietf-ipsec No embarrasing, expencive Doctors visits!

they charge $20ea, we= charge $1.66!!!

SHIPPING WORLD WIDE!

D I S C 0 U = N T - V I @ G R A

ufj c udifksdxf fh dbl okrb usmx nblqmgm un fu vfkhzixcevuk vqfz ar gil h bix rmeg


O P T - O U Tlzids vkembzep arni sghc tfiy cnoo wsviypskrcwgophgh ddcmvf cpb c bul f --B_._6.E2C3E3D26C-- From owner-ipsec@lists.tislabs.com Sun Nov 16 19:43:05 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAH3h4kT030890; Sun, 16 Nov 2003 19:43:05 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA08370 Sun, 16 Nov 2003 21:33:14 -0500 (EST) Message-ID: <008201c3acb4$872b79d0$6401a8c0@adithya> From: "Mohan Parthasarathy" To: Subject: New traffic Selectors in RFC2401bis Date: Sun, 16 Nov 2003 18:43:05 -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 Hello, RFC2401bis defines ICMP type and code as selector. AFAIK, this itself can be negotiated only using IKEv2 traffic selector and one cannot use IKEv1 ID payload. If this is correct, is it worth clarifying in the document ? I can see that the IKE reference has been removed currently. I assume that both IKE versions will be referenced in the future revision. In that case it might be worth clarifying the issue i guess. Not sure what else is IKEv2 specific. thanks mohan From owner-ipsec@lists.tislabs.com Mon Nov 17 05:09:30 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHD9TkT024298; Mon, 17 Nov 2003 05:09:30 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA27737 Mon, 17 Nov 2003 07:25:35 -0500 (EST) In-Reply-To: <10078.1068832829@marajade.sandelman.ottawa.on.ca> References: <10078.1068832829@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <803C5DA4-18FA-11D8-9E1E-000A95834BAA@checkpoint.com> Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com From: Yoav Nir Subject: Re: PMTU discovery for tunnels: issues 78, 49, 81 Date: Mon, 17 Nov 2003 14:35:17 +0200 To: Michael Richardson X-Mailer: Apple Mail (2.606) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Michael, For those of us who weren't there, can you please explain the situation? What are the risks? On Nov 14, 2003, at 8:00 PM, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > > Note that fragmentation before encapsulation can present risks if in > high > speed networks, particularly when they use large TCP windows. Matt > explained > the situation to me, which made my mouth hang open when I realized > what was > up. > From owner-ipsec@lists.tislabs.com Mon Nov 17 06:59:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHExskT031147; Mon, 17 Nov 2003 06:59:54 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01472 Mon, 17 Nov 2003 09:10:52 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <008201c3acb4$872b79d0$6401a8c0@adithya> References: <008201c3acb4$872b79d0$6401a8c0@adithya> Date: Mon, 17 Nov 2003 09:19:08 -0500 To: "Mohan Parthasarathy" From: Stephen Kent Subject: Re: New traffic Selectors in RFC2401bis 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 18:43 -0800 11/16/03, Mohan Parthasarathy wrote: >Hello, > >RFC2401bis defines ICMP type and code as selector. AFAIK, this itself can be >negotiated >only using IKEv2 traffic selector and one cannot use IKEv1 ID payload. If >this is correct, >is it worth clarifying in the document ? I can see that the IKE reference >has been removed >currently. I assume that both IKE versions will be referenced in the future >revision. In that >case it might be worth clarifying the issue i guess. Not sure what else is >IKEv2 specific. > >thanks >mohan Mohan, In general, 2401bis is closely aligned with features of IKEv2. The new structure of SPD entries allows one SA to represent several, distinct S/D address pairs or port ranges, etc. This too cannot be negotiated with IKE v1. In general, 2401bis represents an updating of 2401 that also assumes use of IKE v2 vs. v1. Steve From owner-ipsec@lists.tislabs.com Mon Nov 17 08:03:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHG3KkT035251; Mon, 17 Nov 2003 08:03:20 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA03852 Mon, 17 Nov 2003 10:12:35 -0500 (EST) To: ipsec@lists.tislabs.com, pmtud@ietf.org cc: Yoav Nir Subject: Re: PMTU discovery for tunnels: issues 78, 49, 81 In-reply-to: Your message of "Mon, 17 Nov 2003 14:35:17 +0200." <803C5DA4-18FA-11D8-9E1E-000A95834BAA@checkpoint.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 17 Nov 2003 10:19:06 -0500 Message-ID: <1152.1069082346@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Yoav" == Yoav Nir writes: Yoav> For those of us who weren't there, can you please explain the Yoav> situation? What are the risks? I am not the best person to explain risk of PAWS with fragmentation. Matt said he would write something. Here is the summary of the discussion: Assume - very fast networks using large window TCP - networks that connect them, with MTU constraints in them - that we ignore the DF bit and fragment anyway at the constraint, between dissimilar media. (9000 byte ethernet vs 1500 byte ethernet) Assume that a TCP segment gets fragmented into two pieces. The first fragment gets lost. The second fragment stays in the end-host's queue. Given how fast the network is, it wraps the fragment ID several times a second. So, a second packet gets fragmented in the same way, the first part arrives and matches the queued fragment. The datagram is assembled, and if we are lucky, it fails the TCP checksum. The second part arrives, finds no first part and gets queued, and waits for the next ID wrapping. However, given the speed of the connection, in short time, odds are the TCP checksum will match, and the segment will get accepted. If the PAWS does proper PMTU discovery, then this can't happen. ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP7jm34qHRg3pndX9AQFP2QP9H7JF5ox7PW7R6ika7O6FQVTzuqhRY2PN B2/1FTt7y4R8D987+l3ZhRHuzGGkkEzTQtrJy9KE5jVwysqwpO/4jn7IPKfraZpd EM7RFrou2euIWVlSiQz1xkvT89Otx+fv0wWfAWXzQ7rTjBFps2kz3czyNCIJUm1P 0sr8Ng701DY= =L8F8 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Nov 17 11:17:42 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHJHgkT043250; Mon, 17 Nov 2003 11:17:42 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09995 Mon, 17 Nov 2003 13:28:07 -0500 (EST) Message-ID: <003801c3ad39$eda6d260$681067c0@adithya> From: "Mohan Parthasarathy" To: "Stephen Kent" Cc: References: <008201c3acb4$872b79d0$6401a8c0@adithya> Subject: Re: New traffic Selectors in RFC2401bis Date: Mon, 17 Nov 2003 10:36:00 -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 18:43 -0800 11/16/03, Mohan Parthasarathy wrote: > >Hello, > > > >RFC2401bis defines ICMP type and code as selector. AFAIK, this itself can be > >negotiated > >only using IKEv2 traffic selector and one cannot use IKEv1 ID payload. If > >this is correct, > >is it worth clarifying in the document ? I can see that the IKE reference > >has been removed > >currently. I assume that both IKE versions will be referenced in the future > >revision. In that > >case it might be worth clarifying the issue i guess. Not sure what else is > >IKEv2 specific. > > > >thanks > >mohan > > Mohan, > > In general, 2401bis is closely aligned with features of IKEv2. The > new structure of SPD entries allows one SA to represent several, > distinct S/D address pairs or port ranges, etc. This too cannot be > negotiated with IKE v1. In general, 2401bis represents an updating of > 2401 that also assumes use of IKE v2 vs. v1. > Ok. It might be worth clarifying this somewhere in the 2401bis which i think would be helpful. thanks mohan > Steve From owner-ipsec@lists.tislabs.com Tue Nov 18 13:19:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAILJOkT082386; Tue, 18 Nov 2003 13:19:24 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29045 Tue, 18 Nov 2003 15:22:10 -0500 (EST) Date: Tue, 18 Nov 2003 15:22:10 -0500 (EST) From: owner-ipsec@lists.tislabs.com Message-Id: <200311182022.PAA29045@lists.tislabs.com> [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id OAA28590 Tue, 18 Nov 2003 14:59:17 -0500 (EST) csmap (V6.0) id srcAAAuyaaNd; Tue, 18 Nov 03 15:07:00 -0500 Message-Id: <200311182008.PAA11299@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-udp-encaps-07.txt Date: Tue, 18 Nov 2003 15:08:58 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : UDP Encapsulation of IPsec Packets Author(s) : A. Huttunen Filename : draft-ietf-ipsec-udp-encaps-07.txt Pages : 0 Date : 2003-11-18 This draft defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for the purpose of traversing Network Address Translators. ESP encapsulation as defined in this document is capable of being used in both IPv4 and IPv6 scenarios. The encapsulation is used whenever negotiated using Internet Key Exchange (IKE). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-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-udp-encaps-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-udp-encaps-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-18124237.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-udp-encaps-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-udp-encaps-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-18124237.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Nov 18 13:19:25 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAILJOkT082387; Tue, 18 Nov 2003 13:19:24 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA28952 Tue, 18 Nov 2003 15:18:26 -0500 (EST) Date: Tue, 18 Nov 2003 15:18:26 -0500 (EST) From: owner-ipsec@lists.tislabs.com Message-Id: <200311182018.PAA28952@lists.tislabs.com> [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id OAA28438 Tue, 18 Nov 2003 14:54:43 -0500 (EST) csmap (V6.0) id srcAAA3qaafd; Tue, 18 Nov 03 15:02:25 -0500 Message-Id: <200311182004.PAA10487@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Cc: ipsec@lists.tislabs.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-richardson-ipsec-fragment-00.txt Date: Tue, 18 Nov 2003 15:04:21 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An interim solution to the Path MTU discovery problem for IPsec gateways Author(s) : M. Richardson Filename : draft-richardson-ipsec-fragment-00.txt Pages : 7 Date : 2003-11-18 Path MTU discovery depends upon proper respect for the Don't Fragment (DF) bit. IPsec gateways often present an Maximum Transmission Unit (MTU) constraint, and therefore must send ICMP Fragment Needed messages when the DF bit is set. This document proposes to ignore it in certain cases. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-richardson-ipsec-fragment-00.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-richardson-ipsec-fragment-00.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-richardson-ipsec-fragment-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-18123850.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-richardson-ipsec-fragment-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-richardson-ipsec-fragment-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-18123850.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Nov 19 11:42:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAJJgFkT008755; Wed, 19 Nov 2003 11:42:16 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08610 Wed, 19 Nov 2003 13:37:11 -0500 (EST) Date: Wed, 19 Nov 2003 13:37:11 -0500 (EST) From: owner-ipsec@lists.tislabs.com Message-Id: <200311191837.NAA08610@lists.tislabs.com> [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id NAA08386 Wed, 19 Nov 2003 13:31:18 -0500 (EST) csmap (V6.0) id srcAAADNaq9a; Wed, 19 Nov 03 13:39:03 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: ipsec@lists.tislabs.com From: The IESG Subject: Last Call: 'UDP Encapsulation of IPsec Packets' to Proposed Standard Reply-to: iesg@ietf.org Message-Id: Date: Wed, 19 Nov 2003 13:18:01 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IESG has received a request from the IP Security Protocol WG to consider the following document: - 'UDP Encapsulation of IPsec Packets ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-12-03. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-07.txt From owner-ipsec@lists.tislabs.com Thu Nov 20 11:25:59 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAKJPwkT048385; Thu, 20 Nov 2003 11:25:58 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21061 Thu, 20 Nov 2003 13:13:59 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 20 Nov 2003 10:25:22 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Preliminary minutes from the WG meeting Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. Here are the preliminary minutes from the WG meeting last week. Please send any corrections to the list so that Ted and Barbara can turn in the correct minutes for the proceedings. Please do *not* reply to this message to discuss topics from the meeting; instead, start a new thread. --Paul Hoffman, Director --VPN Consortium IPsec WG meeting 1300, November 10, 2003 Ted Tso and Barbara Fraser chaired the meeting Paul Hoffman took these minutes Agenda was bashed lightly Document status Publication Requested (waiting for Russ Housley's review) IKEv2 IKEv2 algorithms IKEv2 UI suites Waiting for IESG telechat AES CCM AES XCBC PRF NAT Traversal RFC Editor queue AES CTR mode Dead All MIBs except the flow monitoring MIB Back from the IESG, returned with changes DPD NAT requirements Need new drafts Need IANA registry seeding -- secretarial work Michael Richardson volunteered Many other drafts have minor changes such as references 2402bis and ESPv3 needs a document of required algorithms Donald Eastlake volunteered Ongoing work 2401bis, which is what we will talk most about today RFC 2401 issues Seven open issues from the issue tracker Also will discuss the revised processing model Issue 82 -- Creation of SAs Needs better text Text is available, not yet in the issue tracker Issue 85 -- What to do when you have an inbound packet if as a valid SA but not in the selectors Use an ICMP message, or use an IKEv2 message? 2401 is tied to IKEv2, so we can add to IKEv2 for this David Black supported using the IKEv2 method Michael Richardson concurred Issue 88 -- Mark Duffy proposed lifting the prohibition on red-side fragmentation by the SG Intervening gateways might fragment anyway Bill Sommerfeld pointed out that you might be defragmenting from different SAs Michael Richardson pointed out that there is a new PMTU list has been formed to discuss issues that might impinge on this Mark Duffy pointed out we couldn't rely on PMTU Bill Sommerfeld believes we need to discuss this more to make this doesn't affect future protocols Michael Richardson wants to make sure we don't break other people's protocols in the future Steve Kent sees this as a question of "if we are going to fragment, what should be the size". We don't know that now, but we can find that out later. Ted wants people to think hard about it this week. 10ish thought we should adopt it now, 10ish wanted this week to think about it. We will accept the resolution unless a group comes back within a week. Issue 89 -- Misunderstanding about the use of selector name New text is going to come this week Issue 90 -- Removed the selector "data sensitivity level" We don't have a way to negotiate it in IKEv2 Bill Sommerfeld agrees on cutting it out as long as those who want it can add it later Michael Richardson pointed out that there is lots of other things that we cannot yet negotiate that we might specify later Straw poll: many in favor, no opposition Issue 91 -- Handling ICMP error messages Some people think the text is complicated ASCII diagrams only reflect tunnel mode Request to look at issue 91 closely Michael Richardson thinks that it is important it gets done, and that the text is going in the right direction. It might be revised later after people adopt it. This is specified as a local implementation choice Paul Hoffman reported that he has seen unprotected ICMP messages cause gateways to do unpredictable and mysterious stuff Bill Sommerfeld said we should have recommended initial values for a couple of ICMP types, maybe with a GUI suites style Revised processing model Steve Kent described the new model in 2401bis No longer say that SPDs are tied to particular interfaces You can support as many as you need for your context Most folks will have just one Forwarding decisions are separate from SPD selection Many diagrams were shown and described Some of the diagrams will appear in the document as ASCII art Gregory Lebovitz asked about whole-system implementation that includes more than just IKE/IPsec Bill Sommerfeld made sure that "interface" could be part of an API Steve talked about decorrelating SPD entries into sub-entries Allows caching of the SPD for greater speed Can cause the database to get much bigger, but usually doesn't There are asymmetries between inbound and outbound processing Showed a photo of a pied oyster catcher (Haematopus ostralegus) Asked for questions Next step is to fold today's discussion into the next document Steve will try to come up text about who can assert identities Bill Sommerfeld liked that idea Proposed timeline for 2401bis from the WG chairs Close all issues by Nov. 30th Final draft of by December 15 Start WG last call December 15 through January 10 Please comment as soon as possible on the issues above Strong identity protection using hidden credentials Presented by Hilarie Orman Was presenting this now because the WG is about to shut down Identity protection in IKE was an original requirement for IKE The current methods are unsatisfactory Don't work against a MITM Always complicate the protocol New ideas based on Identity-Based Encryption The idea was originally proposed by Shamir around 1985 This is recent work by Boneh Steve Kent brought up some issues that were taken off-line Not that different than having to know the CA, but with big downsides Basic idea: the public part of the key is based on the identity Key protocol remains simple Neither party actual discloses whether they are in the same group Simplifies key management Uses a very different model than we are used to One party must generate all the private keys for a group These private keys must be distributed securely IPR issues Stanford has main patent, are thought to be generous Uses elliptic curve, which has additional IPR Might be able to use non-EC methods Could be a possible modification to IKE Richard Graveman had comments The trusted key can be split There are additional implementation ideas that might apply Could maybe use identity-based signature schemes This allows one CA per policy Lauri Tarkkala asked if identity protection is worth the tradeoff of not generating your own private key Camillia algorithm update Presented by Akihiro Kato Camillia is a 128-bit block cipher Has been scrutinized for a few years Already accepted as proposed standard in S/MIME WG Included in the NESSIE portfolio Already has IPR statements in the IETF directory Angelos Keromytis asked about hardware acceleration Asked why it might overtake AES Not expected to overtake AES in most places Some people talked about having only one algorithm If people want this to be more than just a MAY, they should talk about it on the list BEET -- Bound end-to-end tunnel Presented by Pekka Nikander Background Separating endpoint identifiers and locator There are many proposals for this It uses a transport mode header but has tunnel semantics Has its own BEET SAs Like transport mode plus HostNAT idea Saves header bytes, especially in IPv6: about 50% if ROCH is used Useful for wireless Step towards separating identifier and location Inner addresses are the identifiers Outer addresses are the locators Important for a new architecture Objections and their deflections Unnecessary complexity Adding to KAME stack only took an extra 100 lines Hard to add to existing implementations It's OK to be optional Adding a PF_KEY extension to look for it Not needed But many people are thinking about things like this New mode for ESP Proposed as an extension to ESP Would need a change to IKEv2 Does not need to change ESP specification, but would duplicate ESP and 2401 semantics for BEET Can be considered as an extension to IPsec (or ESP) Francis Dupont said that it is better just to use compression in ESP instead of this Related BOFs this week IKEv2 Mobility and Multihoming -- mobike Profile Use of PKIX -- pki4ipsec Request for review of the channel bindings draft, which was later presented in the SAAG meeting Barbara said it was probably our last meeting; people applauded Ran out of time, ran out for cookies From owner-ipsec@lists.tislabs.com Thu Nov 20 14:08:20 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAKM8JkT055098; Thu, 20 Nov 2003 14:08:19 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA25961 Thu, 20 Nov 2003 16:09:54 -0500 (EST) Message-Id: <200311202029.PAA24085@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-aes-ccm-05.txt Date: Thu, 20 Nov 2003 15:28:59 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Using AES CCM Mode With IPsec ESP Author(s) : R. Housley Filename : draft-ietf-ipsec-ciph-aes-ccm-05.txt Pages : 13 Date : 2003-11-20 This document describes the use of AES CCM Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, connectionless integrity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ccm-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ciph-aes-ccm-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-ccm-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-20154354.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-ccm-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-aes-ccm-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-20154354.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Nov 24 13:02:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAOL2okT066556; Mon, 24 Nov 2003 13:02:53 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09288 Mon, 24 Nov 2003 14:58:43 -0500 (EST) Message-Id: <5.2.0.9.0.20031124141358.022015f8@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 24 Nov 2003 14:47:40 -0500 To: kent@bbn.com, kseo@bbn.com, ipsec@lists.tislabs.com From: Mark Duffy Subject: 2401bis protocol selector Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, rfc2401bis-00 in sect. 4.4.2 has the following text: > - Next Layer Protocol: Obtained from the IPv4 "Protocol" or the > IPv6 "Next Header" fields. This may be an individual protocol > number. These packet fields may not contain the Next Layer > Protocol due to the presence of IP extension headers, e.g., a > Routing Header, AH, ESP, Fragmentation Header, Destination > Options, Hop-by-hop options, etc. Note that the Next Layer > Protocol may not be available in the case of receipt of a packet > with an ESP header, thus a value of "OPAQUE" SHOULD be > supported..br [REQUIRED for all implementations] > > > NOTE: To locate the Next Layer Protocol, a system has to chain > through the packet headers checking the "Protocol" or "Next > Header" field until it encounters either one it recognizes as a > Next Layer Protocol, or until it reaches one that isn't on its > list of extension headers, or until it encounters an ESP header > that renders the Next Layer Protocol opaque. Note: The IPv6 > mobility header is a possible next layer protocol. The text above is almost identical to that in RFC 2401. My comment following is focused mainly on IPv4; v6 may be similar. The above text has always struck me as an undesirable way of working. Why should certain protocols carried in IP be considered "next layer" protocols (for which the SPD should be evaluated) while other protocols (e.g. AH) are considered to be things one should look inside to find a deeper header to evaluate against the SPD? Shouldn't the IPsec policy just be evaluated against the outermost "plaintext" packet presented to IPsec, regardless of the protocol indicated? I believe this has caused quite a bit of confusion in the past e.g. for protocols such as AH, ESP, IP(4) and GRE. Can we please change this in 2401bis to remove any special cases and just treat every IP packet the same? This could be accomplished (for IPv4 anyway) by removing all of the quoted text above except for the first two sentences. I believe we could also remove the confusing table about next header and derived port selectors and its descriptive text two paragraphs further down in the document. If we don't make such a change, then the document should clearly enumerate which values of the IP header protocol field are "next layer protocols" and which are non-next-layer-protocols-that-you-look-inside-for-a-next-layer-protocol. Thanks, Mark From owner-ipsec@lists.tislabs.com Tue Nov 25 09:43:48 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPHhlib091839; Tue, 25 Nov 2003 09:43:47 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00911 Tue, 25 Nov 2003 11:41:59 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.2.0.9.0.20031124141358.022015f8@email> References: <5.2.0.9.0.20031124141358.022015f8@email> Date: Tue, 25 Nov 2003 11:47:29 -0500 To: Mark Duffy From: Stephen Kent Subject: Re: 2401bis protocol selector 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 14:47 -0500 11/24/03, Mark Duffy wrote: >Hi, > >rfc2401bis-00 in sect. 4.4.2 has the following text: > >> - Next Layer Protocol: Obtained from the IPv4 "Protocol" or the >> IPv6 "Next Header" fields. This may be an individual protocol >> number. These packet fields may not contain the Next Layer >> Protocol due to the presence of IP extension headers, e.g., a >> Routing Header, AH, ESP, Fragmentation Header, Destination >> Options, Hop-by-hop options, etc. Note that the Next Layer >> Protocol may not be available in the case of receipt of a packet >> with an ESP header, thus a value of "OPAQUE" SHOULD be >> supported..br [REQUIRED for all implementations] >> >> >> NOTE: To locate the Next Layer Protocol, a system has to chain >> through the packet headers checking the "Protocol" or "Next >> Header" field until it encounters either one it recognizes as a >> Next Layer Protocol, or until it reaches one that isn't on its >> list of extension headers, or until it encounters an ESP header >> that renders the Next Layer Protocol opaque. Note: The IPv6 >> mobility header is a possible next layer protocol. > >The text above is almost identical to that in RFC 2401. >My comment following is focused mainly on IPv4; v6 may be similar. > >The above text has always struck me as an undesirable way of >working. Why should certain protocols carried in IP be considered >"next layer" protocols (for which the SPD should be evaluated) while >other protocols (e.g. AH) are considered to be things one should >look inside to find a deeper header to evaluate against the SPD? the intent is to treat most protocols as next layer protocols. For IPv4 this is not an issue. Only in IPv6 do we encounter complexity due to the extension headers. we can reword the text to minimize confusion. there is no need to skip any protocol headers, under the new processing model, except the IPv6 extension headers. because the new model calls for external forwarding to route a packet through the IPsec processing, if more than one pass is needed, we should be able to simplify the description. >Shouldn't the IPsec policy just be evaluated against the outermost >"plaintext" packet presented to IPsec, regardless of the protocol >indicated? I believe this has caused quite a bit of confusion in >the past e.g. for protocols such as AH, ESP, IP(4) and GRE. yes, it has caused confusion in the past and we hope to avoid that in 2401bis. >Can we please change this in 2401bis to remove any special cases and >just treat every IP packet the same? This could be accomplished >(for IPv4 anyway) by removing all of the quoted text above except >for the first two sentences. I believe we could also remove the >confusing table about next header and derived port selectors and its >descriptive text two paragraphs further down in the document. we'll revise the text and, expect for IPv6 extension headers, I think it will be pretty simple. > >If we don't make such a change, then the document should clearly >enumerate which values of the IP header protocol field are "next >layer protocols" and which are >non-next-layer-protocols-that-you-look-inside-for-a-next-layer-protocol. I think we can make the "next header" selection discussion simpler. Steve From owner-ipsec@lists.tislabs.com Tue Nov 25 10:39:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPIdjib094624; Tue, 25 Nov 2003 10:39:45 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04069 Tue, 25 Nov 2003 12:44:10 -0500 (EST) Message-Id: <200311251749.hAPHnwCI018402@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: ipsec@lists.tislabs.com Subject: draft-richardson-ipsec-fragment-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Nov 2003 12:49:58 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The Working Group management team is soliciting comments on draft-richardson-ipsec-fragment-00.txt ("An interim solution to the Path MTU discovery problem for IPsec gateways"). -Angelos From owner-ipsec@lists.tislabs.com Tue Nov 25 11:10:59 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPJAwib096290; Tue, 25 Nov 2003 11:10:59 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04617 Tue, 25 Nov 2003 13:18:06 -0500 (EST) Date: Tue, 25 Nov 2003 13:10:42 -0500 From: "Theodore Ts'o" To: Stephen Kent Cc: "Sean Kevin O'Keeffe" , ipsec@lists.tislabs.com, David Waitzman Subject: Re: Meta-comment: use of "red" / "black" terminology... Message-ID: <20031125181042.GA10805@thunk.org> References: <200311102345.PAA25518@Pescadero.DSG.Stanford.EDU> <16305.12323.110480.411913@gargle.gargle.HOWL> <3FB13851.70807@bbn.com> <5813CDAA-14A0-11D8-91E1-000393C44F6E@san.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i 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, Nov 12, 2003 at 10:50:03AM -0500, Stephen Kent wrote: > I think we have to pick a pair of terms and realize that they will > not always be perfectly descriptive in all contexts. > > Rich Graveman, in a message to me yesterday, noted that the ATM forum > folks use "protected" and "unprotected" to describe the sides of the > ATM crypto boundary in their documents. So, barring any better > suggestions, we will use those terms going forward. Thanks, I think these would be a better set of terms going forward, in particular with respect to issue #91. - Ted From owner-ipsec@lists.tislabs.com Tue Nov 25 13:04:34 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPL4Xib000919; Tue, 25 Nov 2003 13:04:33 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06207 Tue, 25 Nov 2003 15:11:01 -0500 (EST) Message-Id: <5.2.0.9.0.20031125143155.021ed250@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 25 Nov 2003 14:46:13 -0500 To: ipsec@lists.tislabs.com From: Mark Duffy Subject: 2401bis schedule In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Proposed timeline for 2401bis from the WG chairs > Close all issues by Nov. 30th > Final draft of by December 15 > Start WG last call December 15 through January 10 I'll admit I was surprised when I first saw the above timeline. Do the chairs think this is feasible? Do the authors? Do the other participants? I think it's great the way individual issues have been identified and worked on the list and I think a lot of progress has been made in this way. But until we have a draft that at least claims to be a *candidate* for the final text I don't think we can really be in the end game. I'm all for finishing this as soon as possible. But I am concerned that a schedule like the one above may end up being used as a club to declare doneness prematurely. Mark From owner-ipsec@lists.tislabs.com Tue Nov 25 15:53:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPNrAib006565; Tue, 25 Nov 2003 15:53:11 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11938 Tue, 25 Nov 2003 17:50:21 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.2.0.9.0.20031125143155.021ed250@email> References: <5.2.0.9.0.20031125143155.021ed250@email> Date: Tue, 25 Nov 2003 17:56:29 -0500 To: Mark Duffy From: Stephen Kent Subject: Re: 2401bis schedule Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 14:46 -0500 11/25/03, Mark Duffy wrote: >>Proposed timeline for 2401bis from the WG chairs >> Close all issues by Nov. 30th >> Final draft of by December 15 >> Start WG last call December 15 through January 10 > >I'll admit I was surprised when I first saw the above timeline. Do >the chairs think this is feasible? Do the authors? Do the other >participants? the authors also have expressed reservations about the time line :-) We will continue to work the issues, but we also do plan to release a version of 2401bis by mid-December. I doubt that it will be the last version. Steve From awjzjd84z@mindspring.com Fri Nov 28 20:22:02 2003 Received: from 208.184.76.43 ([66.46.69.95]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAT4M0ib060410; Fri, 28 Nov 2003 20:22:01 -0800 (PST) (envelope-from awjzjd84z@mindspring.com) Received: from [13.237.114.93] by 208.184.76.43 with SMTP; Sat, 29 Nov 2003 14:21:39 -0500 Message-ID: From: "Will Curry" Reply-To: "Will Curry" To: ietf-calsch@imc.org Cc: , , , , , Subject: Keep Your Colon Clean rlm xt Date: Sat, 29 Nov 03 14:21:39 GMT X-Mailer: MIME-tools 5.503 (Entity 5.501) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_.3295.5F8.F_.0A._B._" X-Priority: 3 X-MSMail-Priority: Normal --_.3295.5F8.F_.0A._B._ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

Approxi= mately 156,000 Americans develop colon cancer annually.
Approximately 6= 0,000 will die from this disease.

INTRODUCING:wiojgiwjgwgrwgULTIMATE COLON CLEANSER

You're about to discover t= he true secrets about your colon and digestive system and how it significantly imp= acts your health and enhances your weight loss program. Plain, simple = and to the point information that is vitally important to your overall go= od health. Visit the site to learn how the Ultiamte Colon Cleanser wi= ll clean your colon of toxins and unnecessary waste build up. Shipping is = always free for US customers and we welcome International customers.

Through this very special email offer you can try the Ultimat= e Colon Cleanser risk free for 30 days.


Learn M= ore



Remove Me

v h b lkcxkvhniuwqtxgdbe oj dgh pglgaezhizild --_.3295.5F8.F_.0A._B._--