From owner-ipsec@lists.tislabs.com Fri Jan 2 01:29:08 2004 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 i029T8ib054243; Fri, 2 Jan 2004 01:29:08 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA15621 Fri, 2 Jan 2004 03:35:31 -0500 (EST) Message-ID: X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Karen E. Nielsen (AH/TED)" To: "'Karen Seo'" , ipsec@lists.tislabs.com Subject: RE: new version of IPsec 2401bis Date: Fri, 2 Jan 2004 09:45:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Karen, Could you please advise my as to where I can find the new draft. Thanks, Karen > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Karen Seo > Sent: 25. december 2003 04:28 > To: ipsec@lists.tislabs.com > Cc: Ted Tso; Barbara Fraser; Tero Kivinen; Angelos Keromytis; > kseo@bbn.com > Subject: new version of IPsec 2401bis > > > Folks, > > We just submitted a revised draft for 2401bis, "Security Architecture > for the Internet Protocol". > > Wishing you a Happy Holiday Season! > Karen > From owner-ipsec@lists.tislabs.com Fri Jan 2 12:20:16 2004 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 i02KKFib002848; Fri, 2 Jan 2004 12:20:15 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18588 Fri, 2 Jan 2004 14:36:25 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 2 Jan 2004 14:52:59 -0500 To: "Karen E. Nielsen (AH/TED)" From: Karen Seo Subject: RE: new version of IPsec 2401bis Cc: ipsec@lists.tislabs.com, kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Karen, The IETF secretariat will post the draft to a number of repositories where people can pick it up (www.ietf.org/ID.html or the mirror sites at www.ietf.org/shadow.html) and will also send out an announcement when this happens. My guess is that it's been held up by the holidays/vacations and should be out by next week. Happy New Year, Karen >Hi Karen, > >Could you please advise my as to where I can find the >new draft. > >Thanks, >Karen > >> -----Original Message----- >> From: owner-ipsec@lists.tislabs.com >> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Karen Seo >> Sent: 25. december 2003 04:28 >> To: ipsec@lists.tislabs.com >> Cc: Ted Tso; Barbara Fraser; Tero Kivinen; Angelos Keromytis; >> kseo@bbn.com >> Subject: new version of IPsec 2401bis >> >> >> Folks, >> >> We just submitted a revised draft for 2401bis, "Security Architecture >> for the Internet Protocol". >> >> Wishing you a Happy Holiday Season! >> Karen >> From owner-ipsec@lists.tislabs.com Fri Jan 2 13:01:09 2004 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 i02L18ib004596; Fri, 2 Jan 2004 13:01:08 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA18801 Fri, 2 Jan 2004 15:16:45 -0500 (EST) Date: Fri, 2 Jan 2004 22:28:42 +0200 (IST) From: Hugo Krawczyk To: Pasi.Eronen@nokia.com cc: IPsec WG , Charlie Kaufman Subject: RE: Clarification of EAP authentication in IKEv2? In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122353@esebe023.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk thanks Pasi for the clarification. In light of what you say below we have a few choices on how to proceed: (1) leave things as they are now, using SK_a as a key to the prf as currently specified in sec 2.15, and also as a key to prf in the planned new text of 2.16 for computing AUTH (by the initiator in msg 3) in the case of EAP methods that do NOT generate keys (2) change the spec to use the integrity algorithm from SK{} (i.e. type 3) instead of prf in the above cases (3) derive an additional pair of keys from SKEYSEED (call them SK_pi and SK_pr) for keying the prf in these two cases. The first option is the simplest now but wrong from the crypto point of view as it violates the basic principle of not using the same keys with different algorithms. The second solution is simple as it only requires a small change in the spec language and no implementation difficulty, EXCEPT that if we envision the use of "authenticated encryption" transforms for ESP (and then for SK{} too) then the notion of "the integrity algorithm" used in SK{} may not be well defined (some authenticated-encryption transforms will not define a stand-alone integrity algorithm). The last option is the rightest one, cryptographically speaking, but it requires one more pair of keys derived from SKEYSEED. No big deal (though I can feel Charlie's resistance to it :) I guess that it is for Charlie to decide (my vote is obviously for 3) Hugo On Wed, 31 Dec 2003 Pasi.Eronen@nokia.com wrote: > > Hugo Krawczyk wrote: > > > > > I left the case on non-key-generating EAP methods open, > > > since while your proposal for using SK_ai/SK_ar looks good, > > > how do we actually ensure that the algorithm is the same as > > > used for integrity within the SK{} construct? They're negotiated > > > separately... would using some public-but-random value like > > > prf(Ni|Nr,"EAP") be ok, or do we need to derive one more key > > > from SKEYSEED? > > > > > > > If I understand correctly there are two different > > integrity-type transforms (based on the transform types in sec > > 3.3.2): type #2 is prf (which I believe is the function used > > for key derivation and referred to as "prf" in the text, > > e.g. in sections 2.13 and 2.17) and type #3 is an integrity > > algorithm which (I guess) is the one used BOTH for the MAC > > function that is part of SK{} AND the MAC function used to > > generate AUTH in the case of shared-secret authentication (and > > EAP).Is this interpretation correct? > > > > If so, then AUTH and SK{} use the same integrity algorithm > > (type #3) and the problem you point out to is solved. If they > > are different, then please explain where in the spec they are > > treated differently (in particular for negotiation purposes). > > My understanding from Section 2.15 is that transform type #2 > ("prf") is also used to calculate the AUTH payload for shared > secrets (and EAP): > > In the case of a pre-shared key, the AUTH value is computed as: > AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), ) > > This would mean that transform type #3 is used only for SK{}, > right? > > > Now, if the above interpretation is correct then I may have a > > problem with the use of SK_a under the prf as specified in > > 2.15. But please answer my question above before we proceed to > > finally clarify these issues. > > Assuming that "prf(..)" in Section 2.15 refers to transform > type #2 (as it does elsewhere in the document), and that > SK_a is used with type #3 in SK{}, there indeed seems to be > a possibility for using the same key with two different > algorithms... > > (However, the values prf(SK_ar,IDr') and prf(SK_ai,IDi') > are never transmitted, so I don't know how serious this is.) > > Best regards, > Pasi > From owner-ipsec@lists.tislabs.com Fri Jan 2 13:12:15 2004 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 i02LCEib004963; Fri, 2 Jan 2004 13:12:14 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA18915 Fri, 2 Jan 2004 15:34:20 -0500 (EST) Date: Fri, 2 Jan 2004 22:46:20 +0200 (IST) From: Hugo Krawczyk To: Pasi.Eronen@nokia.com cc: IPsec WG Subject: RE: Clarification of EAP authentication in IKEv2? In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122354@esebe023.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 31 Dec 2003 Pasi.Eronen@nokia.com wrote: > > > Moreover, this envelopping gives a false sense of security > > which can easily lead applications to, for example, send > > sensitive information as part of the exchange assuming its > > protection under SK_e. > > It's quite clear that without the signature, the initiator at > this point (before the AUTH payloads with EAP-derived keys) does > not know who is the other party it shares SK_e with.But, as > the EAP methods were designed to be useful even without any > encryption (during the EAP exchange), Idon't think this false > sense of security is very important. We disagree. I've seen even "more obvious" protocols being misused. And in this case I would not blame anyone that sees the protection under SK{} and assumes that this protection has some actual effect such as protecting the exchange from an (active) eavsdropper. > > > As a more immediate threat, what this signature-less version > > of ikev2 is doing is to allow the same Asokan-Niemi-Nyberg > > mitm attacks (in reverse direction) that the key-generating > >EAP extensions of ikev2 were designed to avoid, namely, the > > "stealing" of EAP runs from one context to another. > > Specifically, by impersonating a signature-less responder in > > the IKE exchange, the attacker can trick an initiator, that is > > willing to run the EAP method in a IKEv2-context only, to > > participate (without its knowledge) in an external (i.e., > > non-ikev2 protected) run of the protocol using the same > > credentials and same EAP method. > > Yes, if the responder is not authenticated before starting EAP, > he can clearly forward the EAP messages to somewhere else > (assuming the same credentials make sense in some other context: > and this is more of a deployment issue). This is quite normal in > EAP: for instance, the wireless LAN access point (or whatever) > is not authenticated before starting EAP. > > However, this does not allow a successful "MitM" attack: sure, > the attacker pretending to be an IKEv2 responder can forward the > EAP payloads to, for instance, a wireless LAN access point; > however, both conversations (IKEv2 and 802.11i) will eventually > fail because the attacker doesn't know the key established by > the EAP method. > > (I'm assuming that the EAP method does mutual authentication and > establishes a key. Clearly several attacks are possible for EAP > methods that don't do this.) > What I described is as good a MitM attack as those described by Asokan et al. It works even if the EAP method provides perfect mutual authentication and key generation. Its effect is to "steal" the run of the EAP protocol from one context to another. Contrary to what you say the stolen exchange (from the IKEv2 context to an untunneled context) will NOT eventually fail, since what the attacker does is to use the real responder and real initiator to produce VALID authentication msgs in EAP. For this the attacker does not need to learn the EAP key, it only impersonates the responder at the level of IKEv2 to trick the initiator into believing that the exchange is being tunneled through ikev2. It was this type of "context stealing" attacks that motivated the use of the extra AUTH payloads in sec 2.16, and the "SHOULD NOT" rule for non-key-generating EAP methods. > > For those that want to use a full-fledge key-generating EAP > > exchange in IKE (e.g., Pasi), I propose to develop a (simple) > > extension to IKEv2 authentication in which the key generated > > by the EAP method is used to generate a value for SKEYSEED > > from which the pertinenet SK_e and SK_a keys are derived, and > > then use these keys directly in a CREATE_CHILD_SA exchange. > > This is the simplest extensibility approach for IKEv2 (but be > > careful about the details...).And just in case someone is > > misunderstanding my intention: I am NOT suggesting that this > > extension be part of the basic IKEv2 document!! > > This would be very complex (since some values for SK_a/SK_e are > needed before the EAP method is finished), and in my opinion, > the wrong approach. I believe it's much better to derive > SKEYSEED the way it's currently done (with DH), and just > use EAP to authenticate the Diffie-Hellman values and nonces > (via AUTH payload). You seem to have misunderstood my suggestion. In my proposal there is no need for SK_a/e in the run of the EAP method. You run the original EAP protocol (with or without PFS depending on the EAP method), generate a key (mutually authenticated by the EAP method), and then use this key as SKEYSEED to derive keying material for a CHILD_SA creation (aka "Phase 2" in IKEv1). If the EAP method is a secure key-exchange protocol then so is this "composition" with IKEv2. > > This approach is quite simple, it works (with good EAP methods), > and has some nice properties like PFS. > But it also has the serious non-nicety of being open to the mitm and illusory-security attacks... > If the WG consensus is that the base IKEv2 spec must prohibit > this, I guess the easiest "extension" would be to specify a new > Notify payload value (e.g. EAP_ONLY_AUTHENTICATION_SUPPORTED); > if the initiator would include this in message #3, the responder > would know that skipping public-key/shared secret authentication > is ok. This could work; the fact that msg 3 is not actually authenticated until the last msg in the protocol (in which the Initiator authenticates the DH values via AUTH) bothers me a bit (since up to that point the DH protection, including that of msg 3, could have been generated by the attacker), but I cannot see how to exploit this in a real attack. > > Best wishes for the New Year, > Pasi > Happy 2004 (hopefully the historical year in which ipsec completed its charter ;) Hugo From owner-ipsec@lists.tislabs.com Fri Jan 2 16:40:57 2004 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 i030euib015691; Fri, 2 Jan 2004 16:40:56 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20018 Fri, 2 Jan 2004 18:51:55 -0500 (EST) To: IPsec WG Subject: draft-ietf-ipsec-ikev2-iana-01.txt Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 02 Jan 2004 19:00:19 -0500 Message-ID: <2450.1073088019@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I have updated draft-ietf-ipsec-ikev2-iana-01.txt (available at: http://www.sandelman.ca/SSW/ietf/ipsec/ikev2/ until ID editor gets to it) to include comments so far. The chairs asked that I include the IANA Considerations from RFC2409, since IKEv2 itself has none. RFC2409 is pretty tight/restricted in its assignments. It predates 2434, so it doesn't use that terminology, so I've translated, I hope. ** Note the issue of merging: ** a) IKEv2 Proposal Substructure Protocol-IDs ** and ** b) IKEv2 Security Protocol Identifiers ** is still open, and unremarked upon. ** They differ only in that b = a + 1. RFC2409 says: 11.1 Attribute Classes - Standards Track 11.2 Encryption Algorithm Class - IETF Consensus/Specification Required. 11.3 Hash Algorithm - IETF Consensus, with extra notes. 11.4 Group Description and Group Type - Specification Required 11.5 Life Type - "Specification Required". sort of. I've been a little less cautious, which is why I'm posting. This is the result of some years of discussion, and some years of experience implementing "new things". Thus it is based upon my feelings about where we should let vendors innovate in isolation, and where they really need to come clean. Also, in some cases the requirements are low because the space available is rather large, in other cases, I can't see very many things being done. In the case of CFG attribute types, I initialy through, First-Come-First-Serverd, and then I remembered the PPP world of MS-* options vs standard ones. Some coordination is required. IKEv2 Exchange types may created by Standards Action. IKEv2 Payload Types may be allocated by Specification Required. IKEv2 Transform Types may be allocated by Specification Required. IKEv2 Proposal Substructure Protocol-IDs may be allocated by Standards Action. IKEv2 Transform Attribute Types may be allocated by Specification Required. IKEv2 Encryption Transform IDs may be allocated by expert review. The initial expert reviewer is REVIEW. IKEv2 Pseudo-random Transform IDs may be allocated by expert review. The initial expert reviewer is REVIEW. IKEv2 Integrity Algorithm Transform IDs may be allocated by expert review. The initial expert reviewer is REVIEW. IKEv2 Diffie-Hellman, ECP and EC2N Transform IDs may be allocated by Spec Required. IKEv2 Extended Sequence Numbers Transform IDs may be allocated by IETF Consenus. IKEv2 Payload ID Types may be allocated by Specification Required. IKEv2 Identification Payload ID Types may be allocated by Specification Required. IKEv2 Certificate Encodings may be allocated by Specification Required. IKEv2 Authentication Method may be allocated by Specification Required. IKEv2 Notification Payload Types may be allocated by First Come-First Served. IKEv2 Notification IPCOMP Transform IDs may be allocated by expert review. The initial expert reviewer is REVIEW. IKEv2 Security Protocol Identifiers may be allocated by Standards Action. IKEv2 Traffic Selector Types may be allocated by Specification Required. IKEv2 Configuration Payload CFG Types may be allocated by Specification Required. IKEv2 Configuration Payload Attribute Types may be allocated by Specification Required. At a previous time, kivinen@ssh.fi was proposed for "REVIEW", and was generally acceptable to many. I do not know if Kivinen is still able to perform this function. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP/YGEIqHRg3pndX9AQFdWgP9FL2OnOMVzrU58QvNGFaCsyK+Ck4m2x1A F4PxoEi0dG7JOFRLJr11ZCqZ+hrRJyc0/Xo1g+XeSrY8/U01cEA1yI4eC2X0Q19c mjJ7d1nYKJlw9rJIu77pZwF5StWuCqvE2ZMZWikQBGZeEoFXR8AptqA3zP5PRH/i qh/NEY+uHEc= =u9Ah -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Jan 2 17:45:51 2004 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 i031jpib018157; Fri, 2 Jan 2004 17:45:51 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA20303 Fri, 2 Jan 2004 19:57:57 -0500 (EST) Message-ID: <62173B970AE0A044AED8723C3BCF2381037F3356@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-esp-ah-algorithms-00.txt Date: Fri, 2 Jan 2004 20:02:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sounds good to me. Donald =========================================================== Donald E. Eastlake III Donald.Eastlake@Motorola.com Motorola Laboratories 1-508-786-7554 (work) 111 Locke Drive 1-508-634-2066 (home) Marlboro, MA 01752 USA -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Tero Kivinen Sent: Wednesday, December 31, 2003 6:04 AM To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-esp-ah-algorithms-00.txt Paul Hoffman / VPNC writes: > Instead, simply create a new section in this document that aligns > with section 3.2.3 of draft-ietf-ipsec-esp-v3-06.txt, say that > combined modes will require proper structuring of an ESP > implementation, say why combined modes are useful (speed > improvements, soon to be required in 802.11), and they say "there are > no suggested or required algorithms at this time, but AES-CCM is > expected to be of interest in the near future". That way, > implementers know that even though there isn't a MUST or SHOULD right > now, they still need to think about how their code should look if > there is one in the future. I really like that idea. -- kivinen@iki.fi From owner-ipsec@lists.tislabs.com Mon Jan 5 08:54:56 2004 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 i05Gstib002367; Mon, 5 Jan 2004 08:54:56 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06105 Mon, 5 Jan 2004 10:44:07 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16377.35021.711954.675359@fireball.acr.fi> Date: Mon, 5 Jan 2004 17:54:53 +0200 From: Tero Kivinen To: Michael Richardson Cc: IPsec WG Subject: draft-ietf-ipsec-ikev2-iana-01.txt In-Reply-To: <2450.1073088019@marajade.sandelman.ottawa.on.ca> References: <2450.1073088019@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 7.17 under Emacs 21.3.1 Organization: Helsinki University of Technology X-Edit-Time: 32 min X-Total-Time: 84 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson writes: > I have updated draft-ietf-ipsec-ikev2-iana-01.txt > (available at: http://www.sandelman.ca/SSW/ietf/ipsec/ikev2/ until ID > editor gets to it) I think the section 4, might need little more text, it took at least for me some time to realize that this change was for v1 registry, and the reserved range matches the payload numbers allocated for the IKEv2. > IKEv2 Exchange types may created by Standards Action. Do we really need standard action here, wouldn't the specification required be enough. > IKEv2 Payload Types may be allocated by Specification Required. This is propably the first resource we are running out... We already have 48 reserved numbers, and when extensions are made they quite often want to use their own payloads... I still think the specification required is the correct fr this. > IKEv2 Proposal Substructure Protocol-IDs may be allocated by Standards Action. Why standards action, why not specification required? I do not think we are going to have too many of those, but on the other hand some of those extensions might not be on standard track. I would suggest specification required for this too. > IKEv2 Encryption Transform IDs may be allocated by expert review. > The initial expert reviewer is REVIEW. The RFC2434 says that "When a Designated Expert is used, documents MUST NOT name the Designated Expert in the document itself; instead, the name should be relayed to the appropriate IESG Area Director at the time the document is sent to the IESG for approval." > IKEv2 Diffie-Hellman, ECP and EC2N Transform IDs may be allocated by Spec Required. Why this is specification required instead of expert review like crypto algorithms? In both cases some kind of specification is needed to implement them, and I think expert review would be enough for this too. > IKEv2 Extended Sequence Numbers Transform IDs may be allocated by > IETF Consenus. ^ typo in the document too.. Why IETF consensus? Specification required would propably be enough. If I understand correctly the difference is that IETF consensus requires the specification to be RFC, and specification required allows other documents too... > IKEv2 Security Protocol Identifiers may be allocated by Standards Action. Again same as with proposal substructure protocol-IDs, I think specification required would be enough. I can see that someone might want to use IKE as a key exchange method for non-ipsec cases, where the easiest way would be to use new protocol number for that, and if it is not IP related protocol, then its documents might not be standard track documents, or RFCs at all. Preventing duplicate numbers in those cases might still be usefull, in case someone sometime define way to transport that stuff on the internet too... > IKEv2 Configuration Payload Attribute Types may be allocated by Specification Required. Here the expert review might also be enough. Perhaps the specification required is still better. > At a previous time, kivinen@ssh.fi was proposed for "REVIEW", and was > generally acceptable to many. I do not know if Kivinen is still able to > perform this function. I am available if requested. The RFC2434 says that reviewers are appointed by the relevant Area Director of the IESG.... -- kivinen@iki.fi From owner-ipsec@lists.tislabs.com Mon Jan 5 09:02:52 2004 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 i05H2pib002784; Mon, 5 Jan 2004 09:02:51 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06413 Mon, 5 Jan 2004 11:22:05 -0500 (EST) To: "IPsec WG" CC: "Charlie Kaufman" Subject: Re: draft-ietf-ipsec-ikev2-iana-01.txt In-reply-to: Your message of "Sun, 04 Jan 2004 20:17:34 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 05 Jan 2004 11:26:55 -0500 Message-ID: <3903.1073320015@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Charlie" == Charlie Kaufman writes: >> ** Note the issue of merging: >> ** a) IKEv2 Proposal Substructure Protocol-IDs >> ** and >> ** b) IKEv2 Security Protocol Identifiers >> ** is still open, and unremarked upon. >> ** They differ only in that b = a + 1. Charlie> The difference was a transcription error in one of the IKEv2 drafts that Charlie> I have fixed in the latest (unposted) draft. There should be only one Charlie> set of values, labeled Security Protocol Identifiers, with the values: 1 Charlie> for IKE, 2 for AH and 3 for ESP. These match the values assigned in Charlie> IKEv1. Thank you for clearing this up Charlie! I have removed Proposal Substructure Protocol-IDs. Charlie, do you have any comments on the amending formulae? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP/mQTYqHRg3pndX9AQHE6wQAhWqBRBWzTtr8WQ0nZN/L0Pxmu+O+RyXh BvR9BLtZW3Q9ibhGnTf35P4PT7LSwVQK59MiI3zkgdh7bbceYOibBxbX7af1Nnip 8AffI1UgBkzDAPmVJ6DrG2XTxnZyI3V7/d4wRxwt7lO+gcyqvzILqfr73oCgdACl FYe1uHs1ZE4= =fVI7 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Jan 5 09:05:06 2004 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 i05H56ib002922; Mon, 5 Jan 2004 09:05:06 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06407 Mon, 5 Jan 2004 11:21:42 -0500 (EST) Date: Mon, 5 Jan 2004 11:21:42 -0500 (EST) From: owner-ipsec@lists.tislabs.com Message-Id: <200401051621.LAA06407@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 XAA03218 Sun, 4 Jan 2004 23:15:37 -0500 (EST) nutshell.tislabs.com via csmap (V6.0) id srcAAArDa4Y5; Sun, 4 Jan 04 23:23:50 -0500 by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Sun, 4 Jan 2004 20:26:29 -0800 (InterScan E-Mail VirusWall NT); Sun, 04 Jan 2004 20:26:29 -0800 by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 4 Jan 2004 20:26:29 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: ikev2-11 nit Date: Sun, 4 Jan 2004 20:26:27 -0800 Message-ID: Thread-Topic: ikev2-11 nit thread-index: AcPFucwtE242d0PLQrasCL319OgtDgNijnwg From: "Charlie Kaufman" To: "Jari Arkko" , X-OriginalArrivalTime: 05 Jan 2004 04:26:29.0615 (UTC) FILETIME=[17269FF0:01C3D344] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id XAA03219 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sounds fair. I'll do it unless someone objects. --Charlie -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Jari Arkko Sent: Thursday, December 18, 2003 2:39 PM To: ipsec@lists.tislabs.com Subject: ikev2-11 nit A nit in IKEv2 draft 11: Section 2.16 says this about EAP methods: "... protocols expected to be used most commonly are fully documented here and in section 3.16." I disagree about the "fully" part. Section 3.16 has a total of 19 lines of text about EAP methods. In contrast, RFC 2284bis spends about 10 pages to describe the same thing. Recommended fix: remove the word "fully". --Jari From owner-ipsec@lists.tislabs.com Mon Jan 5 09:39:30 2004 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 i05HdTib004236; Mon, 5 Jan 2004 09:39:29 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06634 Mon, 5 Jan 2004 11:56:36 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Mon, 5 Jan 2004 12:02:52 -0500 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: new 2401bis versions ... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, A revised 2401bis was transmitted to the Secretariat on Christmas eve, but has not yet shown up as an I-D. Over the holidays, Karen and I have been busy making additional revisions. So, we will submit a newer version tomorrow, and ask Paul to post it to the archives for faster distribution. please don't bother reading the per-Xmas version when it is posted. Thanks, and sorry for the confusion, Steve From owner-ipsec@lists.tislabs.com Mon Jan 5 11:37:55 2004 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 i05Jbsib009573; Mon, 5 Jan 2004 11:37:54 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07608 Mon, 5 Jan 2004 13:52:00 -0500 (EST) To: IPsec WG , Tero Kivinen Subject: Re: draft-ietf-ipsec-ikev2-iana-01.txt In-reply-to: Your message of "Mon, 05 Jan 2004 17:54:53 +0200." <16377.35021.711954.675359@fireball.acr.fi> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 05 Jan 2004 13:56:59 -0500 Message-ID: <7540.1073329019@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tero" == Tero Kivinen writes: Tero> Michael Richardson writes: >> I have updated draft-ietf-ipsec-ikev2-iana-01.txt >> (available at: http://www.sandelman.ca/SSW/ietf/ipsec/ikev2/ until ID >> editor gets to it) Tero> I think the section 4, might need little more text, it took at least Tero> for me some time to realize that this change was for v1 registry, and Tero> the reserved range matches the payload numbers allocated for the Tero> IKEv2. I agree, it could use a bit more text. >> IKEv2 Exchange types may created by Standards Action. Tero> Do we really need standard action here, wouldn't the specification Tero> required be enough. The only reason I can imagine needing new exchange types is to create vastly different protocols. This would mean that they would certainly not be compatible with existing deployment - I think that this needs to be considered carefully. It would seem to be a major extension to this specification. >> IKEv2 Payload Types may be allocated by Specification Required. Tero> This is propably the first resource we are running out... We already Tero> have 48 reserved numbers, and when extensions are made they quite Tero> often want to use their own payloads... I still think the Tero> specification required is the correct fr this. Good. I think that this is where most experimentation will occur, and the critical bit provides us with pretty much everything with need to remain interoperable. >> IKEv2 Proposal Substructure Protocol-IDs may be allocated by Standards Action. Tero> Why standards action, why not specification required? I do not think Tero> we are going to have too many of those, but on the other hand some of Tero> those extensions might not be on standard track. I would suggest Tero> specification required for this too. Well, if we were to add a new security protocol number, I think that that it would get a new IP-protocol number, and I don't think we hand those out very easily. It would also mean a whole bunch of new on-the-wire items. I think that this is a big deal - maybe I'm wrong though. >> IKEv2 Encryption Transform IDs may be allocated by expert review. >> The initial expert reviewer is REVIEW. Tero> The RFC2434 says that "When a Designated Expert is used, documents Tero> MUST NOT name the Designated Expert in the document itself; instead, Tero> the name should be relayed to the appropriate IESG Area Director at Tero> the time the document is sent to the IESG for approval." Uhm, okay. But, this isn't IKEv2 - this is a document that is really aimed *at* the area director. It will never get published once IANA says that they understand it. Maybe the amendment formulas will get incorporated into IKEv2. >> IKEv2 Diffie-Hellman, ECP and EC2N Transform IDs may be allocated by Spec Required. Tero> Why this is specification required instead of expert review like Tero> crypto algorithms? In both cases some kind of specification is needed Tero> to implement them, and I think expert review would be enough for this Tero> too. I think that the new groups need to be published somewhere. There is no obvious way to do this except through the IETF. New crypto algorithms, on the other hand, might in fact be published in other journals, by the IEEE, ACM, or be in-house "proprietary". (Consider compression algorithms). I think that we want to make new algorithms relatively easy to assign numbers to. You can select the ones you like, and leave the ones you don't like. Whereas, if you get the MODP group wrong, then you have to start phase 1 again. So, having fewer, well known MODP groups is good for interop, while the same does not apply to algorithms - so long as there is a MUST. >> IKEv2 Extended Sequence Numbers Transform IDs may be allocated by >> IETF Consenus. Tero> ^ typo in the document too.. Thank you. Tero> Why IETF consensus? Specification required would propably be enough. Tero> If I understand correctly the difference is that IETF consensus Tero> requires the specification to be RFC, and specification required Tero> allows other documents too... I just can't see who would need a new *Extended Sequence Number* attribute. The two values of "YES" and "NO" are done. I guess someone might need 128 bit sequence numbers next - I think that this would require a revision to 2402bis (2402-bis-bis?), so I think that this is a fair statement. >> IKEv2 Security Protocol Identifiers may be allocated by Standards Action. Tero> Again same as with proposal substructure protocol-IDs, I think okay, so they are merged now. Tero> specification required would be enough. I can see that someone might Tero> want to use IKE as a key exchange method for non-ipsec cases, where Tero> the easiest way would be to use new protocol number for that, and if Tero> it is not IP related protocol, then its documents might not be Tero> standard track documents, or RFCs at all. Preventing duplicate numbers Tero> in those cases might still be usefull, in case someone sometime define Tero> way to transport that stuff on the internet too... I understand. I'm open here. You feel it should be Specifications Required. >> IKEv2 Configuration Payload Attribute Types may be allocated by Specification Required. Tero> Here the expert review might also be enough. Perhaps the specification Tero> required is still better. I thought that even First-Come-First-Served. The space is large, however, I think that asking people to document in an informational RFC is enough to avoid the PPP/DHCP attribute chaos. >> At a previous time, kivinen@ssh.fi was proposed for "REVIEW", and was >> generally acceptable to many. I do not know if Kivinen is still able to >> perform this function. Tero> I am available if requested. The RFC2434 says that reviewers are Tero> appointed by the relevant Area Director of the IESG.... I think that the set of available people should be non-empty, otherwise, expert-review is meaningless. Final decision is up to AD. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP/mzcoqHRg3pndX9AQEgswQAvsaleFi4wUKiAEuORknFtxrZAnsZb13e EuvWZdpH1l8Ou7c5c+WUpYnu6QWtW3J7SiyM5yq5C9/kfsKuS/L+Eo0F2prC2xT2 0q83oHFn1+TAVRVpHGvaQf1Bhm0oGGX+nsEUQbSzx+DeZa24M24iIo4gUglw4AKZ v7exSb5tN+A= =gohv -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Jan 6 03:39:33 2004 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 i06BdXib034506; Tue, 6 Jan 2004 03:39:33 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA12426 Tue, 6 Jan 2004 06:02:57 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Mon, 5 Jan 2004 12:02:52 -0500 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: new 2401bis versions ... Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, A revised 2401bis was transmitted to the Secretariat on Christmas eve, but has not yet shown up as an I-D. Over the holidays, Karen and I have been busy making additional revisions. So, we will submit a newer version tomorrow, and ask Paul to post it to the archives for faster distribution. please don't bother reading the per-Xmas version when it is posted. Thanks, and sorry for the confusion, Steve From owner-ipsec@lists.tislabs.com Tue Jan 6 03:39:36 2004 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 i06Bdaib034517; Tue, 6 Jan 2004 03:39:36 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA12361 Tue, 6 Jan 2004 05:56:11 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16377.35021.711954.675359@fireball.acr.fi> Date: Mon, 5 Jan 2004 17:54:53 +0200 From: Tero Kivinen To: Michael Richardson Cc: IPsec WG Subject: draft-ietf-ipsec-ikev2-iana-01.txt In-Reply-To: <2450.1073088019@marajade.sandelman.ottawa.on.ca> References: <2450.1073088019@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 7.17 under Emacs 21.3.1 Organization: Helsinki University of Technology X-Edit-Time: 32 min X-Total-Time: 84 min X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson writes: > I have updated draft-ietf-ipsec-ikev2-iana-01.txt > (available at: http://www.sandelman.ca/SSW/ietf/ipsec/ikev2/ until ID > editor gets to it) I think the section 4, might need little more text, it took at least for me some time to realize that this change was for v1 registry, and the reserved range matches the payload numbers allocated for the IKEv2. > IKEv2 Exchange types may created by Standards Action. Do we really need standard action here, wouldn't the specification required be enough. > IKEv2 Payload Types may be allocated by Specification Required. This is propably the first resource we are running out... We already have 48 reserved numbers, and when extensions are made they quite often want to use their own payloads... I still think the specification required is the correct fr this. > IKEv2 Proposal Substructure Protocol-IDs may be allocated by Standards Action. Why standards action, why not specification required? I do not think we are going to have too many of those, but on the other hand some of those extensions might not be on standard track. I would suggest specification required for this too. > IKEv2 Encryption Transform IDs may be allocated by expert review. > The initial expert reviewer is REVIEW. The RFC2434 says that "When a Designated Expert is used, documents MUST NOT name the Designated Expert in the document itself; instead, the name should be relayed to the appropriate IESG Area Director at the time the document is sent to the IESG for approval." > IKEv2 Diffie-Hellman, ECP and EC2N Transform IDs may be allocated by Spec Required. Why this is specification required instead of expert review like crypto algorithms? In both cases some kind of specification is needed to implement them, and I think expert review would be enough for this too. > IKEv2 Extended Sequence Numbers Transform IDs may be allocated by > IETF Consenus. ^ typo in the document too.. Why IETF consensus? Specification required would propably be enough. If I understand correctly the difference is that IETF consensus requires the specification to be RFC, and specification required allows other documents too... > IKEv2 Security Protocol Identifiers may be allocated by Standards Action. Again same as with proposal substructure protocol-IDs, I think specification required would be enough. I can see that someone might want to use IKE as a key exchange method for non-ipsec cases, where the easiest way would be to use new protocol number for that, and if it is not IP related protocol, then its documents might not be standard track documents, or RFCs at all. Preventing duplicate numbers in those cases might still be usefull, in case someone sometime define way to transport that stuff on the internet too... > IKEv2 Configuration Payload Attribute Types may be allocated by Specification Required. Here the expert review might also be enough. Perhaps the specification required is still better. > At a previous time, kivinen@ssh.fi was proposed for "REVIEW", and was > generally acceptable to many. I do not know if Kivinen is still able to > perform this function. I am available if requested. The RFC2434 says that reviewers are appointed by the relevant Area Director of the IESG.... -- kivinen@iki.fi From owner-ipsec@lists.tislabs.com Tue Jan 6 03:59:18 2004 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 i06BxIib035464; Tue, 6 Jan 2004 03:59:18 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA12584 Tue, 6 Jan 2004 06:22:55 -0500 (EST) To: IPsec WG , Tero Kivinen Subject: Re: draft-ietf-ipsec-ikev2-iana-01.txt In-reply-to: Your message of "Mon, 05 Jan 2004 17:54:53 +0200." <16377.35021.711954.675359@fireball.acr.fi> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 05 Jan 2004 13:56:59 -0500 Message-ID: <7540.1073329019@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=0.0 required=5.0 tests=LINES_OF_YELLING autolearn=ham version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tero" == Tero Kivinen writes: Tero> Michael Richardson writes: >> I have updated draft-ietf-ipsec-ikev2-iana-01.txt >> (available at: http://www.sandelman.ca/SSW/ietf/ipsec/ikev2/ until ID >> editor gets to it) Tero> I think the section 4, might need little more text, it took at least Tero> for me some time to realize that this change was for v1 registry, and Tero> the reserved range matches the payload numbers allocated for the Tero> IKEv2. I agree, it could use a bit more text. >> IKEv2 Exchange types may created by Standards Action. Tero> Do we really need standard action here, wouldn't the specification Tero> required be enough. The only reason I can imagine needing new exchange types is to create vastly different protocols. This would mean that they would certainly not be compatible with existing deployment - I think that this needs to be considered carefully. It would seem to be a major extension to this specification. >> IKEv2 Payload Types may be allocated by Specification Required. Tero> This is propably the first resource we are running out... We already Tero> have 48 reserved numbers, and when extensions are made they quite Tero> often want to use their own payloads... I still think the Tero> specification required is the correct fr this. Good. I think that this is where most experimentation will occur, and the critical bit provides us with pretty much everything with need to remain interoperable. >> IKEv2 Proposal Substructure Protocol-IDs may be allocated by Standards Action. Tero> Why standards action, why not specification required? I do not think Tero> we are going to have too many of those, but on the other hand some of Tero> those extensions might not be on standard track. I would suggest Tero> specification required for this too. Well, if we were to add a new security protocol number, I think that that it would get a new IP-protocol number, and I don't think we hand those out very easily. It would also mean a whole bunch of new on-the-wire items. I think that this is a big deal - maybe I'm wrong though. >> IKEv2 Encryption Transform IDs may be allocated by expert review. >> The initial expert reviewer is REVIEW. Tero> The RFC2434 says that "When a Designated Expert is used, documents Tero> MUST NOT name the Designated Expert in the document itself; instead, Tero> the name should be relayed to the appropriate IESG Area Director at Tero> the time the document is sent to the IESG for approval." Uhm, okay. But, this isn't IKEv2 - this is a document that is really aimed *at* the area director. It will never get published once IANA says that they understand it. Maybe the amendment formulas will get incorporated into IKEv2. >> IKEv2 Diffie-Hellman, ECP and EC2N Transform IDs may be allocated by Spec Required. Tero> Why this is specification required instead of expert review like Tero> crypto algorithms? In both cases some kind of specification is needed Tero> to implement them, and I think expert review would be enough for this Tero> too. I think that the new groups need to be published somewhere. There is no obvious way to do this except through the IETF. New crypto algorithms, on the other hand, might in fact be published in other journals, by the IEEE, ACM, or be in-house "proprietary". (Consider compression algorithms). I think that we want to make new algorithms relatively easy to assign numbers to. You can select the ones you like, and leave the ones you don't like. Whereas, if you get the MODP group wrong, then you have to start phase 1 again. So, having fewer, well known MODP groups is good for interop, while the same does not apply to algorithms - so long as there is a MUST. >> IKEv2 Extended Sequence Numbers Transform IDs may be allocated by >> IETF Consenus. Tero> ^ typo in the document too.. Thank you. Tero> Why IETF consensus? Specification required would propably be enough. Tero> If I understand correctly the difference is that IETF consensus Tero> requires the specification to be RFC, and specification required Tero> allows other documents too... I just can't see who would need a new *Extended Sequence Number* attribute. The two values of "YES" and "NO" are done. I guess someone might need 128 bit sequence numbers next - I think that this would require a revision to 2402bis (2402-bis-bis?), so I think that this is a fair statement. >> IKEv2 Security Protocol Identifiers may be allocated by Standards Action. Tero> Again same as with proposal substructure protocol-IDs, I think okay, so they are merged now. Tero> specification required would be enough. I can see that someone might Tero> want to use IKE as a key exchange method for non-ipsec cases, where Tero> the easiest way would be to use new protocol number for that, and if Tero> it is not IP related protocol, then its documents might not be Tero> standard track documents, or RFCs at all. Preventing duplicate numbers Tero> in those cases might still be usefull, in case someone sometime define Tero> way to transport that stuff on the internet too... I understand. I'm open here. You feel it should be Specifications Required. >> IKEv2 Configuration Payload Attribute Types may be allocated by Specification Required. Tero> Here the expert review might also be enough. Perhaps the specification Tero> required is still better. I thought that even First-Come-First-Served. The space is large, however, I think that asking people to document in an informational RFC is enough to avoid the PPP/DHCP attribute chaos. >> At a previous time, kivinen@ssh.fi was proposed for "REVIEW", and was >> generally acceptable to many. I do not know if Kivinen is still able to >> perform this function. Tero> I am available if requested. The RFC2434 says that reviewers are Tero> appointed by the relevant Area Director of the IESG.... I think that the set of available people should be non-empty, otherwise, expert-review is meaningless. Final decision is up to AD. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP/mzcoqHRg3pndX9AQEgswQAvsaleFi4wUKiAEuORknFtxrZAnsZb13e EuvWZdpH1l8Ou7c5c+WUpYnu6QWtW3J7SiyM5yq5C9/kfsKuS/L+Eo0F2prC2xT2 0q83oHFn1+TAVRVpHGvaQf1Bhm0oGGX+nsEUQbSzx+DeZa24M24iIo4gUglw4AKZ v7exSb5tN+A= =gohv -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Jan 6 04:05:01 2004 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 i06C50ib035618; Tue, 6 Jan 2004 04:05:00 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA12601 Tue, 6 Jan 2004 06:29:02 -0500 (EST) To: "IPsec WG" Cc: "Charlie Kaufman" Subject: Re: draft-ietf-ipsec-ikev2-iana-01.txt In-reply-to: Your message of "Sun, 04 Jan 2004 20:17:34 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 05 Jan 2004 11:26:55 -0500 Message-ID: <3903.1073320015@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=0.0 required=5.0 tests=LINES_OF_YELLING autolearn=ham version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Charlie" == Charlie Kaufman writes: >> ** Note the issue of merging: >> ** a) IKEv2 Proposal Substructure Protocol-IDs >> ** and >> ** b) IKEv2 Security Protocol Identifiers >> ** is still open, and unremarked upon. >> ** They differ only in that b = a + 1. Charlie> The difference was a transcription error in one of the IKEv2 drafts that Charlie> I have fixed in the latest (unposted) draft. There should be only one Charlie> set of values, labeled Security Protocol Identifiers, with the values: 1 Charlie> for IKE, 2 for AH and 3 for ESP. These match the values assigned in Charlie> IKEv1. Thank you for clearing this up Charlie! I have removed Proposal Substructure Protocol-IDs. Charlie, do you have any comments on the amending formulae? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP/mQTYqHRg3pndX9AQHE6wQAhWqBRBWzTtr8WQ0nZN/L0Pxmu+O+RyXh BvR9BLtZW3Q9ibhGnTf35P4PT7LSwVQK59MiI3zkgdh7bbceYOibBxbX7af1Nnip 8AffI1UgBkzDAPmVJ6DrG2XTxnZyI3V7/d4wRxwt7lO+gcyqvzILqfr73oCgdACl FYe1uHs1ZE4= =fVI7 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Jan 6 05:46:30 2004 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 i06DkTib039919; Tue, 6 Jan 2004 05:46:29 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13836 Tue, 6 Jan 2004 08:07:47 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Mon, 5 Jan 2004 12:02:52 -0500 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: new 2401bis versions ... Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=0.4 required=5.0 tests=DATE_IN_PAST_12_24 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, A revised 2401bis was transmitted to the Secretariat on Christmas eve, but has not yet shown up as an I-D. Over the holidays, Karen and I have been busy making additional revisions. So, we will submit a newer version tomorrow, and ask Paul to post it to the archives for faster distribution. please don't bother reading the per-Xmas version when it is posted. Thanks, and sorry for the confusion, Steve From owner-ipsec@lists.tislabs.com Tue Jan 6 05:47:34 2004 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 i06DlYib040016; Tue, 6 Jan 2004 05:47:34 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13814 Tue, 6 Jan 2004 08:07:28 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16377.35021.711954.675359@fireball.acr.fi> Date: Mon, 5 Jan 2004 17:54:53 +0200 From: Tero Kivinen To: Michael Richardson Cc: IPsec WG Subject: draft-ietf-ipsec-ikev2-iana-01.txt In-Reply-To: <2450.1073088019@marajade.sandelman.ottawa.on.ca> References: <2450.1073088019@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 7.17 under Emacs 21.3.1 Organization: Helsinki University of Technology X-Edit-Time: 32 min X-Total-Time: 84 min X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=0.4 required=5.0 tests=DATE_IN_PAST_12_24 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson writes: > I have updated draft-ietf-ipsec-ikev2-iana-01.txt > (available at: http://www.sandelman.ca/SSW/ietf/ipsec/ikev2/ until ID > editor gets to it) I think the section 4, might need little more text, it took at least for me some time to realize that this change was for v1 registry, and the reserved range matches the payload numbers allocated for the IKEv2. > IKEv2 Exchange types may created by Standards Action. Do we really need standard action here, wouldn't the specification required be enough. > IKEv2 Payload Types may be allocated by Specification Required. This is propably the first resource we are running out... We already have 48 reserved numbers, and when extensions are made they quite often want to use their own payloads... I still think the specification required is the correct fr this. > IKEv2 Proposal Substructure Protocol-IDs may be allocated by Standards Action. Why standards action, why not specification required? I do not think we are going to have too many of those, but on the other hand some of those extensions might not be on standard track. I would suggest specification required for this too. > IKEv2 Encryption Transform IDs may be allocated by expert review. > The initial expert reviewer is REVIEW. The RFC2434 says that "When a Designated Expert is used, documents MUST NOT name the Designated Expert in the document itself; instead, the name should be relayed to the appropriate IESG Area Director at the time the document is sent to the IESG for approval." > IKEv2 Diffie-Hellman, ECP and EC2N Transform IDs may be allocated by Spec Required. Why this is specification required instead of expert review like crypto algorithms? In both cases some kind of specification is needed to implement them, and I think expert review would be enough for this too. > IKEv2 Extended Sequence Numbers Transform IDs may be allocated by > IETF Consenus. ^ typo in the document too.. Why IETF consensus? Specification required would propably be enough. If I understand correctly the difference is that IETF consensus requires the specification to be RFC, and specification required allows other documents too... > IKEv2 Security Protocol Identifiers may be allocated by Standards Action. Again same as with proposal substructure protocol-IDs, I think specification required would be enough. I can see that someone might want to use IKE as a key exchange method for non-ipsec cases, where the easiest way would be to use new protocol number for that, and if it is not IP related protocol, then its documents might not be standard track documents, or RFCs at all. Preventing duplicate numbers in those cases might still be usefull, in case someone sometime define way to transport that stuff on the internet too... > IKEv2 Configuration Payload Attribute Types may be allocated by Specification Required. Here the expert review might also be enough. Perhaps the specification required is still better. > At a previous time, kivinen@ssh.fi was proposed for "REVIEW", and was > generally acceptable to many. I do not know if Kivinen is still able to > perform this function. I am available if requested. The RFC2434 says that reviewers are appointed by the relevant Area Director of the IESG.... -- kivinen@iki.fi From owner-ipsec@lists.tislabs.com Tue Jan 6 06:14:44 2004 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 i06EEiib041908; Tue, 6 Jan 2004 06:14:44 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA14362 Tue, 6 Jan 2004 08:35:18 -0500 (EST) To: IPsec WG , Tero Kivinen Subject: Re: draft-ietf-ipsec-ikev2-iana-01.txt In-reply-to: Your message of "Mon, 05 Jan 2004 17:54:53 +0200." <16377.35021.711954.675359@fireball.acr.fi> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 05 Jan 2004 13:56:59 -0500 Message-ID: <7540.1073329019@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=0.4 required=5.0 tests=DATE_IN_PAST_12_24, LINES_OF_YELLING autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tero" == Tero Kivinen writes: Tero> Michael Richardson writes: >> I have updated draft-ietf-ipsec-ikev2-iana-01.txt >> (available at: http://www.sandelman.ca/SSW/ietf/ipsec/ikev2/ until ID >> editor gets to it) Tero> I think the section 4, might need little more text, it took at least Tero> for me some time to realize that this change was for v1 registry, and Tero> the reserved range matches the payload numbers allocated for the Tero> IKEv2. I agree, it could use a bit more text. >> IKEv2 Exchange types may created by Standards Action. Tero> Do we really need standard action here, wouldn't the specification Tero> required be enough. The only reason I can imagine needing new exchange types is to create vastly different protocols. This would mean that they would certainly not be compatible with existing deployment - I think that this needs to be considered carefully. It would seem to be a major extension to this specification. >> IKEv2 Payload Types may be allocated by Specification Required. Tero> This is propably the first resource we are running out... We already Tero> have 48 reserved numbers, and when extensions are made they quite Tero> often want to use their own payloads... I still think the Tero> specification required is the correct fr this. Good. I think that this is where most experimentation will occur, and the critical bit provides us with pretty much everything with need to remain interoperable. >> IKEv2 Proposal Substructure Protocol-IDs may be allocated by Standards Action. Tero> Why standards action, why not specification required? I do not think Tero> we are going to have too many of those, but on the other hand some of Tero> those extensions might not be on standard track. I would suggest Tero> specification required for this too. Well, if we were to add a new security protocol number, I think that that it would get a new IP-protocol number, and I don't think we hand those out very easily. It would also mean a whole bunch of new on-the-wire items. I think that this is a big deal - maybe I'm wrong though. >> IKEv2 Encryption Transform IDs may be allocated by expert review. >> The initial expert reviewer is REVIEW. Tero> The RFC2434 says that "When a Designated Expert is used, documents Tero> MUST NOT name the Designated Expert in the document itself; instead, Tero> the name should be relayed to the appropriate IESG Area Director at Tero> the time the document is sent to the IESG for approval." Uhm, okay. But, this isn't IKEv2 - this is a document that is really aimed *at* the area director. It will never get published once IANA says that they understand it. Maybe the amendment formulas will get incorporated into IKEv2. >> IKEv2 Diffie-Hellman, ECP and EC2N Transform IDs may be allocated by Spec Required. Tero> Why this is specification required instead of expert review like Tero> crypto algorithms? In both cases some kind of specification is needed Tero> to implement them, and I think expert review would be enough for this Tero> too. I think that the new groups need to be published somewhere. There is no obvious way to do this except through the IETF. New crypto algorithms, on the other hand, might in fact be published in other journals, by the IEEE, ACM, or be in-house "proprietary". (Consider compression algorithms). I think that we want to make new algorithms relatively easy to assign numbers to. You can select the ones you like, and leave the ones you don't like. Whereas, if you get the MODP group wrong, then you have to start phase 1 again. So, having fewer, well known MODP groups is good for interop, while the same does not apply to algorithms - so long as there is a MUST. >> IKEv2 Extended Sequence Numbers Transform IDs may be allocated by >> IETF Consenus. Tero> ^ typo in the document too.. Thank you. Tero> Why IETF consensus? Specification required would propably be enough. Tero> If I understand correctly the difference is that IETF consensus Tero> requires the specification to be RFC, and specification required Tero> allows other documents too... I just can't see who would need a new *Extended Sequence Number* attribute. The two values of "YES" and "NO" are done. I guess someone might need 128 bit sequence numbers next - I think that this would require a revision to 2402bis (2402-bis-bis?), so I think that this is a fair statement. >> IKEv2 Security Protocol Identifiers may be allocated by Standards Action. Tero> Again same as with proposal substructure protocol-IDs, I think okay, so they are merged now. Tero> specification required would be enough. I can see that someone might Tero> want to use IKE as a key exchange method for non-ipsec cases, where Tero> the easiest way would be to use new protocol number for that, and if Tero> it is not IP related protocol, then its documents might not be Tero> standard track documents, or RFCs at all. Preventing duplicate numbers Tero> in those cases might still be usefull, in case someone sometime define Tero> way to transport that stuff on the internet too... I understand. I'm open here. You feel it should be Specifications Required. >> IKEv2 Configuration Payload Attribute Types may be allocated by Specification Required. Tero> Here the expert review might also be enough. Perhaps the specification Tero> required is still better. I thought that even First-Come-First-Served. The space is large, however, I think that asking people to document in an informational RFC is enough to avoid the PPP/DHCP attribute chaos. >> At a previous time, kivinen@ssh.fi was proposed for "REVIEW", and was >> generally acceptable to many. I do not know if Kivinen is still able to >> perform this function. Tero> I am available if requested. The RFC2434 says that reviewers are Tero> appointed by the relevant Area Director of the IESG.... I think that the set of available people should be non-empty, otherwise, expert-review is meaningless. Final decision is up to AD. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP/mzcoqHRg3pndX9AQEgswQAvsaleFi4wUKiAEuORknFtxrZAnsZb13e EuvWZdpH1l8Ou7c5c+WUpYnu6QWtW3J7SiyM5yq5C9/kfsKuS/L+Eo0F2prC2xT2 0q83oHFn1+TAVRVpHGvaQf1Bhm0oGGX+nsEUQbSzx+DeZa24M24iIo4gUglw4AKZ v7exSb5tN+A= =gohv -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Jan 6 06:24:50 2004 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 i06EOnib043039; Tue, 6 Jan 2004 06:24:50 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA14438 Tue, 6 Jan 2004 08:43:16 -0500 (EST) To: "IPsec WG" Cc: "Charlie Kaufman" Subject: Re: draft-ietf-ipsec-ikev2-iana-01.txt In-reply-to: Your message of "Sun, 04 Jan 2004 20:17:34 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 05 Jan 2004 11:26:55 -0500 Message-ID: <3903.1073320015@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=0.4 required=5.0 tests=DATE_IN_PAST_12_24, LINES_OF_YELLING autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Charlie" == Charlie Kaufman writes: >> ** Note the issue of merging: >> ** a) IKEv2 Proposal Substructure Protocol-IDs >> ** and >> ** b) IKEv2 Security Protocol Identifiers >> ** is still open, and unremarked upon. >> ** They differ only in that b = a + 1. Charlie> The difference was a transcription error in one of the IKEv2 drafts that Charlie> I have fixed in the latest (unposted) draft. There should be only one Charlie> set of values, labeled Security Protocol Identifiers, with the values: 1 Charlie> for IKE, 2 for AH and 3 for ESP. These match the values assigned in Charlie> IKEv1. Thank you for clearing this up Charlie! I have removed Proposal Substructure Protocol-IDs. Charlie, do you have any comments on the amending formulae? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP/mQTYqHRg3pndX9AQHE6wQAhWqBRBWzTtr8WQ0nZN/L0Pxmu+O+RyXh BvR9BLtZW3Q9ibhGnTf35P4PT7LSwVQK59MiI3zkgdh7bbceYOibBxbX7af1Nnip 8AffI1UgBkzDAPmVJ6DrG2XTxnZyI3V7/d4wRxwt7lO+gcyqvzILqfr73oCgdACl FYe1uHs1ZE4= =fVI7 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Jan 6 07:43:32 2004 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 i06FhVib046345; Tue, 6 Jan 2004 07:43:31 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15294 Tue, 6 Jan 2004 10:02:20 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Mon, 5 Jan 2004 12:02:52 -0500 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: new 2401bis versions ... Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=0.4 required=5.0 tests=DATE_IN_PAST_12_24 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, A revised 2401bis was transmitted to the Secretariat on Christmas eve, but has not yet shown up as an I-D. Over the holidays, Karen and I have been busy making additional revisions. So, we will submit a newer version tomorrow, and ask Paul to post it to the archives for faster distribution. please don't bother reading the per-Xmas version when it is posted. Thanks, and sorry for the confusion, Steve From owner-ipsec@lists.tislabs.com Tue Jan 6 07:59:57 2004 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 i06Fxuib047106; Tue, 6 Jan 2004 07:59:56 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15352 Tue, 6 Jan 2004 10:06:56 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16377.35021.711954.675359@fireball.acr.fi> Date: Mon, 5 Jan 2004 17:54:53 +0200 From: Tero Kivinen To: Michael Richardson Cc: IPsec WG Subject: draft-ietf-ipsec-ikev2-iana-01.txt In-Reply-To: <2450.1073088019@marajade.sandelman.ottawa.on.ca> References: <2450.1073088019@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 7.17 under Emacs 21.3.1 Organization: Helsinki University of Technology X-Edit-Time: 32 min X-Total-Time: 84 min X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=0.4 required=5.0 tests=DATE_IN_PAST_12_24 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson writes: > I have updated draft-ietf-ipsec-ikev2-iana-01.txt > (available at: http://www.sandelman.ca/SSW/ietf/ipsec/ikev2/ until ID > editor gets to it) I think the section 4, might need little more text, it took at least for me some time to realize that this change was for v1 registry, and the reserved range matches the payload numbers allocated for the IKEv2. > IKEv2 Exchange types may created by Standards Action. Do we really need standard action here, wouldn't the specification required be enough. > IKEv2 Payload Types may be allocated by Specification Required. This is propably the first resource we are running out... We already have 48 reserved numbers, and when extensions are made they quite often want to use their own payloads... I still think the specification required is the correct fr this. > IKEv2 Proposal Substructure Protocol-IDs may be allocated by Standards Action. Why standards action, why not specification required? I do not think we are going to have too many of those, but on the other hand some of those extensions might not be on standard track. I would suggest specification required for this too. > IKEv2 Encryption Transform IDs may be allocated by expert review. > The initial expert reviewer is REVIEW. The RFC2434 says that "When a Designated Expert is used, documents MUST NOT name the Designated Expert in the document itself; instead, the name should be relayed to the appropriate IESG Area Director at the time the document is sent to the IESG for approval." > IKEv2 Diffie-Hellman, ECP and EC2N Transform IDs may be allocated by Spec Required. Why this is specification required instead of expert review like crypto algorithms? In both cases some kind of specification is needed to implement them, and I think expert review would be enough for this too. > IKEv2 Extended Sequence Numbers Transform IDs may be allocated by > IETF Consenus. ^ typo in the document too.. Why IETF consensus? Specification required would propably be enough. If I understand correctly the difference is that IETF consensus requires the specification to be RFC, and specification required allows other documents too... > IKEv2 Security Protocol Identifiers may be allocated by Standards Action. Again same as with proposal substructure protocol-IDs, I think specification required would be enough. I can see that someone might want to use IKE as a key exchange method for non-ipsec cases, where the easiest way would be to use new protocol number for that, and if it is not IP related protocol, then its documents might not be standard track documents, or RFCs at all. Preventing duplicate numbers in those cases might still be usefull, in case someone sometime define way to transport that stuff on the internet too... > IKEv2 Configuration Payload Attribute Types may be allocated by Specification Required. Here the expert review might also be enough. Perhaps the specification required is still better. > At a previous time, kivinen@ssh.fi was proposed for "REVIEW", and was > generally acceptable to many. I do not know if Kivinen is still able to > perform this function. I am available if requested. The RFC2434 says that reviewers are appointed by the relevant Area Director of the IESG.... -- kivinen@iki.fi From owner-ipsec@lists.tislabs.com Tue Jan 6 08:32:11 2004 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 i06GWAib049098; Tue, 6 Jan 2004 08:32:10 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15591 Tue, 6 Jan 2004 10:32:20 -0500 (EST) To: IPsec WG , Tero Kivinen Subject: Re: draft-ietf-ipsec-ikev2-iana-01.txt In-reply-to: Your message of "Mon, 05 Jan 2004 17:54:53 +0200." <16377.35021.711954.675359@fireball.acr.fi> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 05 Jan 2004 13:56:59 -0500 Message-ID: <7540.1073329019@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tero" == Tero Kivinen writes: Tero> Michael Richardson writes: >> I have updated draft-ietf-ipsec-ikev2-iana-01.txt >> (available at: http://www.sandelman.ca/SSW/ietf/ipsec/ikev2/ until ID >> editor gets to it) Tero> I think the section 4, might need little more text, it took at least Tero> for me some time to realize that this change was for v1 registry, and Tero> the reserved range matches the payload numbers allocated for the Tero> IKEv2. I agree, it could use a bit more text. >> IKEv2 Exchange types may created by Standards Action. Tero> Do we really need standard action here, wouldn't the specification Tero> required be enough. The only reason I can imagine needing new exchange types is to create vastly different protocols. This would mean that they would certainly not be compatible with existing deployment - I think that this needs to be considered carefully. It would seem to be a major extension to this specification. >> IKEv2 Payload Types may be allocated by Specification Required. Tero> This is propably the first resource we are running out... We already Tero> have 48 reserved numbers, and when extensions are made they quite Tero> often want to use their own payloads... I still think the Tero> specification required is the correct fr this. Good. I think that this is where most experimentation will occur, and the critical bit provides us with pretty much everything with need to remain interoperable. >> IKEv2 Proposal Substructure Protocol-IDs may be allocated by Standards Action. Tero> Why standards action, why not specification required? I do not think Tero> we are going to have too many of those, but on the other hand some of Tero> those extensions might not be on standard track. I would suggest Tero> specification required for this too. Well, if we were to add a new security protocol number, I think that that it would get a new IP-protocol number, and I don't think we hand those out very easily. It would also mean a whole bunch of new on-the-wire items. I think that this is a big deal - maybe I'm wrong though. >> IKEv2 Encryption Transform IDs may be allocated by expert review. >> The initial expert reviewer is REVIEW. Tero> The RFC2434 says that "When a Designated Expert is used, documents Tero> MUST NOT name the Designated Expert in the document itself; instead, Tero> the name should be relayed to the appropriate IESG Area Director at Tero> the time the document is sent to the IESG for approval." Uhm, okay. But, this isn't IKEv2 - this is a document that is really aimed *at* the area director. It will never get published once IANA says that they understand it. Maybe the amendment formulas will get incorporated into IKEv2. >> IKEv2 Diffie-Hellman, ECP and EC2N Transform IDs may be allocated by Spec Required. Tero> Why this is specification required instead of expert review like Tero> crypto algorithms? In both cases some kind of specification is needed Tero> to implement them, and I think expert review would be enough for this Tero> too. I think that the new groups need to be published somewhere. There is no obvious way to do this except through the IETF. New crypto algorithms, on the other hand, might in fact be published in other journals, by the IEEE, ACM, or be in-house "proprietary". (Consider compression algorithms). I think that we want to make new algorithms relatively easy to assign numbers to. You can select the ones you like, and leave the ones you don't like. Whereas, if you get the MODP group wrong, then you have to start phase 1 again. So, having fewer, well known MODP groups is good for interop, while the same does not apply to algorithms - so long as there is a MUST. >> IKEv2 Extended Sequence Numbers Transform IDs may be allocated by >> IETF Consenus. Tero> ^ typo in the document too.. Thank you. Tero> Why IETF consensus? Specification required would propably be enough. Tero> If I understand correctly the difference is that IETF consensus Tero> requires the specification to be RFC, and specification required Tero> allows other documents too... I just can't see who would need a new *Extended Sequence Number* attribute. The two values of "YES" and "NO" are done. I guess someone might need 128 bit sequence numbers next - I think that this would require a revision to 2402bis (2402-bis-bis?), so I think that this is a fair statement. >> IKEv2 Security Protocol Identifiers may be allocated by Standards Action. Tero> Again same as with proposal substructure protocol-IDs, I think okay, so they are merged now. Tero> specification required would be enough. I can see that someone might Tero> want to use IKE as a key exchange method for non-ipsec cases, where Tero> the easiest way would be to use new protocol number for that, and if Tero> it is not IP related protocol, then its documents might not be Tero> standard track documents, or RFCs at all. Preventing duplicate numbers Tero> in those cases might still be usefull, in case someone sometime define Tero> way to transport that stuff on the internet too... I understand. I'm open here. You feel it should be Specifications Required. >> IKEv2 Configuration Payload Attribute Types may be allocated by Specification Required. Tero> Here the expert review might also be enough. Perhaps the specification Tero> required is still better. I thought that even First-Come-First-Served. The space is large, however, I think that asking people to document in an informational RFC is enough to avoid the PPP/DHCP attribute chaos. >> At a previous time, kivinen@ssh.fi was proposed for "REVIEW", and was >> generally acceptable to many. I do not know if Kivinen is still able to >> perform this function. Tero> I am available if requested. The RFC2434 says that reviewers are Tero> appointed by the relevant Area Director of the IESG.... I think that the set of available people should be non-empty, otherwise, expert-review is meaningless. Final decision is up to AD. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP/mzcoqHRg3pndX9AQEgswQAvsaleFi4wUKiAEuORknFtxrZAnsZb13e EuvWZdpH1l8Ou7c5c+WUpYnu6QWtW3J7SiyM5yq5C9/kfsKuS/L+Eo0F2prC2xT2 0q83oHFn1+TAVRVpHGvaQf1Bhm0oGGX+nsEUQbSzx+DeZa24M24iIo4gUglw4AKZ v7exSb5tN+A= =gohv -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Jan 6 09:30:14 2004 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 i06HUEib052255; Tue, 6 Jan 2004 09:30:14 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15666 Tue, 6 Jan 2004 10:43:28 -0500 (EST) To: "IPsec WG" Cc: "Charlie Kaufman" Subject: Re: draft-ietf-ipsec-ikev2-iana-01.txt In-reply-to: Your message of "Sun, 04 Jan 2004 20:17:34 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 05 Jan 2004 11:26:55 -0500 Message-ID: <3903.1073320015@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Charlie" == Charlie Kaufman writes: >> ** Note the issue of merging: >> ** a) IKEv2 Proposal Substructure Protocol-IDs >> ** and >> ** b) IKEv2 Security Protocol Identifiers >> ** is still open, and unremarked upon. >> ** They differ only in that b = a + 1. Charlie> The difference was a transcription error in one of the IKEv2 drafts that Charlie> I have fixed in the latest (unposted) draft. There should be only one Charlie> set of values, labeled Security Protocol Identifiers, with the values: 1 Charlie> for IKE, 2 for AH and 3 for ESP. These match the values assigned in Charlie> IKEv1. Thank you for clearing this up Charlie! I have removed Proposal Substructure Protocol-IDs. Charlie, do you have any comments on the amending formulae? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP/mQTYqHRg3pndX9AQHE6wQAhWqBRBWzTtr8WQ0nZN/L0Pxmu+O+RyXh BvR9BLtZW3Q9ibhGnTf35P4PT7LSwVQK59MiI3zkgdh7bbceYOibBxbX7af1Nnip 8AffI1UgBkzDAPmVJ6DrG2XTxnZyI3V7/d4wRxwt7lO+gcyqvzILqfr73oCgdACl FYe1uHs1ZE4= =fVI7 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Jan 6 12:19:06 2004 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 i06KJ3ib060326; Tue, 6 Jan 2004 12:19:06 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16875 Tue, 6 Jan 2004 13:17:00 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Mon, 5 Jan 2004 12:02:52 -0500 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: new 2401bis versions ... Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-0.8 required=5.0 tests=BAYES_01,DATE_IN_PAST_12_24 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, A revised 2401bis was transmitted to the Secretariat on Christmas eve, but has not yet shown up as an I-D. Over the holidays, Karen and I have been busy making additional revisions. So, we will submit a newer version tomorrow, and ask Paul to post it to the archives for faster distribution. please don't bother reading the per-Xmas version when it is posted. Thanks, and sorry for the confusion, Steve From owner-ipsec@lists.tislabs.com Tue Jan 6 13:05:18 2004 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 i06L5Hib063609; Tue, 6 Jan 2004 13:05:17 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA17734 Tue, 6 Jan 2004 15:12:37 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: <3223A045-4086-11D8-ACBC-000393101764@tislabs.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ipsec@lists.tislabs.com From: John Kelley Subject: Sorry for the repeated postings Date: Tue, 6 Jan 2004 15:23:31 -0500 X-Mailer: Apple Mail (2.609) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Our mail system had a slight hiccup over the past couple days. This caused a few postings to be repeated. We believe this is fixed, so hopefully you will only see one copy of this message. Sorry for the noise. -John -- John Kelley Development Engineer Sparta, Inc. Columbia, MD 410.872.1515 x219 410.872.8079 FAX From owner-ipsec@lists.tislabs.com Tue Jan 6 14:59:45 2004 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 i06Mxiib071022; Tue, 6 Jan 2004 14:59:44 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA18543 Tue, 6 Jan 2004 17:11:47 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Mon, 5 Jan 2004 12:02:52 -0500 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: new 2401bis versions ... Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, A revised 2401bis was transmitted to the Secretariat on Christmas eve, but has not yet shown up as an I-D. Over the holidays, Karen and I have been busy making additional revisions. So, we will submit a newer version tomorrow, and ask Paul to post it to the archives for faster distribution. please don't bother reading the per-Xmas version when it is posted. Thanks, and sorry for the confusion, Steve From owner-ipsec@lists.tislabs.com Tue Jan 6 15:26:37 2004 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 i06NQbib072550; Tue, 6 Jan 2004 15:26:37 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA18713 Tue, 6 Jan 2004 17:41:34 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: <3223A045-4086-11D8-ACBC-000393101764@tislabs.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ipsec@lists.tislabs.com From: John Kelley Subject: Sorry for the repeated postings Date: Tue, 6 Jan 2004 15:23:31 -0500 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-1.4 required=5.0 tests=BAYES_20 autolearn=ham version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Our mail system had a slight hiccup over the past couple days. This caused a few postings to be repeated. We believe this is fixed, so hopefully you will only see one copy of this message. Sorry for the noise. -John -- John Kelley Development Engineer Sparta, Inc. Columbia, MD 410.872.1515 x219 410.872.8079 FAX From owner-ipsec@lists.tislabs.com Tue Jan 6 16:55:15 2004 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 i070tEib079886; Tue, 6 Jan 2004 16:55:14 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA19348 Tue, 6 Jan 2004 18:54:37 -0500 (EST) From: "Bepsy Paul" To: Subject: RE: Sorry for the repeated postings Date: Tue, 6 Jan 2004 16:05:57 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3223A045-4086-11D8-ACBC-000393101764@tislabs.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am looking for an open-source implementation of IKE & IPSEC which is available for download. Can anyone point out any useful link for downloading such a source code? your help will be highly appreciated. Thanks, Bepsy -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of John Kelley Sent: Tuesday, January 06, 2004 12:24 PM To: ipsec@lists.tislabs.com Subject: Sorry for the repeated postings Our mail system had a slight hiccup over the past couple days. This caused a few postings to be repeated. We believe this is fixed, so hopefully you will only see one copy of this message. Sorry for the noise. -John -- John Kelley Development Engineer Sparta, Inc. Columbia, MD 410.872.1515 x219 410.872.8079 FAX From owner-ipsec@lists.tislabs.com Tue Jan 6 17:21:31 2004 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 i071LUib085610; Tue, 6 Jan 2004 17:21:31 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA19576 Tue, 6 Jan 2004 19:26:10 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Mon, 5 Jan 2004 12:02:52 -0500 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: new 2401bis versions ... Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, A revised 2401bis was transmitted to the Secretariat on Christmas eve, but has not yet shown up as an I-D. Over the holidays, Karen and I have been busy making additional revisions. So, we will submit a newer version tomorrow, and ask Paul to post it to the archives for faster distribution. please don't bother reading the per-Xmas version when it is posted. Thanks, and sorry for the confusion, Steve From owner-ipsec@lists.tislabs.com Tue Jan 6 17:31:04 2004 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 i071V3ib087489; Tue, 6 Jan 2004 17:31:03 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA19765 Tue, 6 Jan 2004 19:47:43 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: <3223A045-4086-11D8-ACBC-000393101764@tislabs.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ipsec@lists.tislabs.com From: John Kelley Subject: Sorry for the repeated postings Date: Tue, 6 Jan 2004 15:23:31 -0500 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Our mail system had a slight hiccup over the past couple days. This caused a few postings to be repeated. We believe this is fixed, so hopefully you will only see one copy of this message. Sorry for the noise. -John -- John Kelley Development Engineer Sparta, Inc. Columbia, MD 410.872.1515 x219 410.872.8079 FAX From owner-ipsec@lists.tislabs.com Tue Jan 6 18:59:37 2004 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 i072xaib011049; Tue, 6 Jan 2004 18:59:36 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20619 Tue, 6 Jan 2004 21:14:41 -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: Tue, 6 Jan 2004 18:26:18 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: New version of the IKEv2 draft Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie has turned in a new version of the IKEv2 draft. The I-D editor is being very, very slow these days, so there is a temporary copy at . I will remove that copy when the draft is officially published. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jan 6 19:01:42 2004 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 i0731fib011454; Tue, 6 Jan 2004 19:01:42 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20625 Tue, 6 Jan 2004 21:15:01 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 6 Jan 2004 18:28:33 -0800 To: "Bepsy Paul" , From: Paul Hoffman / VPNC Subject: Open source IPsec (was: RE: Sorry for the repeated postings) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:05 PM -0800 1/6/04, Bepsy Paul wrote: > I am looking for an open-source implementation of IKE & IPSEC which is >available for download. Can anyone point out any useful link for downloading >such a source code? your help will be highly appreciated. Here are three well-known packages that contain open-source IPsec and IKE: --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jan 6 19:17:15 2004 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 i073HFib015338; Tue, 6 Jan 2004 19:17:15 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20752 Tue, 6 Jan 2004 21:35:14 -0500 (EST) From: "Bepsy Paul" To: Subject: RE: Sorry for the repeated postings Date: Tue, 6 Jan 2004 16:05:57 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3223A045-4086-11D8-ACBC-000393101764@tislabs.com> X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_40 autolearn=ham version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am looking for an open-source implementation of IKE & IPSEC which is available for download. Can anyone point out any useful link for downloading such a source code? your help will be highly appreciated. Thanks, Bepsy -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of John Kelley Sent: Tuesday, January 06, 2004 12:24 PM To: ipsec@lists.tislabs.com Subject: Sorry for the repeated postings Our mail system had a slight hiccup over the past couple days. This caused a few postings to be repeated. We believe this is fixed, so hopefully you will only see one copy of this message. Sorry for the noise. -John -- John Kelley Development Engineer Sparta, Inc. Columbia, MD 410.872.1515 x219 410.872.8079 FAX From owner-ipsec@lists.tislabs.com Tue Jan 6 19:28:08 2004 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 i073S7ib017675; Tue, 6 Jan 2004 19:28:07 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20785 Tue, 6 Jan 2004 21:40:24 -0500 (EST) Date: Tue, 6 Jan 2004 21:50:57 -0500 (EST) From: shogunx To: Bepsy Paul cc: ipsec@lists.tislabs.com Subject: RE: Sorry for the repeated postings 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, 6 Jan 2004, Bepsy Paul wrote: > Hi, > > I am looking for an open-source implementation of IKE & IPSEC which is > available for download. Can anyone point out any useful link for downloading > such a source code? your help will be highly appreciated. http://www.freeswan.org > > Thanks, > Bepsy > > > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of John Kelley > Sent: Tuesday, January 06, 2004 12:24 PM > To: ipsec@lists.tislabs.com > Subject: Sorry for the repeated postings > > > > Our mail system had a slight hiccup over the past couple days. This > caused a few postings to be repeated. > We believe this is fixed, so hopefully you will only see one copy of > this message. > > Sorry for the noise. > > -John > > -- > > John Kelley > Development Engineer > Sparta, Inc. > Columbia, MD > 410.872.1515 x219 > 410.872.8079 FAX > > > sleekfreak pirate broadcast world tour 2002-3 live from the pirate hideout http://sleekfreak.ath.cx:81/ From owner-ipsec@lists.tislabs.com Tue Jan 6 19:39:18 2004 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 i073dHib020817; Tue, 6 Jan 2004 19:39:17 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20837 Tue, 6 Jan 2004 21:49:19 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Mon, 5 Jan 2004 12:02:52 -0500 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: new 2401bis versions ... Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, A revised 2401bis was transmitted to the Secretariat on Christmas eve, but has not yet shown up as an I-D. Over the holidays, Karen and I have been busy making additional revisions. So, we will submit a newer version tomorrow, and ask Paul to post it to the archives for faster distribution. please don't bother reading the per-Xmas version when it is posted. Thanks, and sorry for the confusion, Steve From owner-ipsec@lists.tislabs.com Tue Jan 6 20:29:26 2004 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 i074TPib033380; Tue, 6 Jan 2004 20:29:25 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA21403 Tue, 6 Jan 2004 22:47:02 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Tue, 6 Jan 2004 23:02:26 -0500 To: ipsec@lists.tislabs.com From: Karen Seo Subject: new version of IPsec 2401bis Cc: Ted Tso , Barbara Fraser , Tero Kivinen , Angelos Keromytis , kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, We just submitted a revised draft for 2401bis, "Security Architecture for the Internet Protocol". Karen From owner-ipsec@lists.tislabs.com Tue Jan 6 20:51:26 2004 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 i074pPib038199; Tue, 6 Jan 2004 20:51:26 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA21711 Tue, 6 Jan 2004 23:10:10 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: <3223A045-4086-11D8-ACBC-000393101764@tislabs.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ipsec@lists.tislabs.com From: John Kelley Subject: Sorry for the repeated postings Date: Tue, 6 Jan 2004 15:23:31 -0500 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-4.5 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Our mail system had a slight hiccup over the past couple days. This caused a few postings to be repeated. We believe this is fixed, so hopefully you will only see one copy of this message. Sorry for the noise. -John -- John Kelley Development Engineer Sparta, Inc. Columbia, MD 410.872.1515 x219 410.872.8079 FAX From owner-ipsec@lists.tislabs.com Tue Jan 6 20:57:11 2004 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 i074vAib039466; Tue, 6 Jan 2004 20:57:11 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA21756 Tue, 6 Jan 2004 23:17:42 -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: Tue, 6 Jan 2004 20:31:15 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: New version of the 2401bis draft Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As reported earlier, Steve and Karen have posted a newer-than-December draft of 2401bis. It can be found at until it appears in the Internet Drafts directory. Note that this is the -02, not the -01 draft. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jan 6 21:15:50 2004 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 i075Fnib044308; Tue, 6 Jan 2004 21:15:50 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA22063 Tue, 6 Jan 2004 23:36:21 -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: Tue, 6 Jan 2004 18:26:18 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: New version of the IKEv2 draft Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-12.9 required=5.0 tests=BAYES_00,HABEAS_SWE autolearn=ham version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie has turned in a new version of the IKEv2 draft. The I-D editor is being very, very slow these days, so there is a temporary copy at . I will remove that copy when the draft is officially published. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jan 6 21:15:51 2004 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 i075Foib044309; Tue, 6 Jan 2004 21:15:50 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA22072 Tue, 6 Jan 2004 23:36:28 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 6 Jan 2004 18:28:33 -0800 To: "Bepsy Paul" , From: Paul Hoffman / VPNC Subject: Open source IPsec (was: RE: Sorry for the repeated postings) Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-12.9 required=5.0 tests=BAYES_00,HABEAS_SWE autolearn=ham version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:05 PM -0800 1/6/04, Bepsy Paul wrote: > I am looking for an open-source implementation of IKE & IPSEC which is >available for download. Can anyone point out any useful link for downloading >such a source code? your help will be highly appreciated. Here are three well-known packages that contain open-source IPsec and IKE: --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jan 6 21:19:31 2004 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 i075JVib044972; Tue, 6 Jan 2004 21:19:31 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA22147 Tue, 6 Jan 2004 23:41:02 -0500 (EST) From: "Bepsy Paul" To: Subject: RE: Sorry for the repeated postings Date: Tue, 6 Jan 2004 16:05:57 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3223A045-4086-11D8-ACBC-000393101764@tislabs.com> X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am looking for an open-source implementation of IKE & IPSEC which is available for download. Can anyone point out any useful link for downloading such a source code? your help will be highly appreciated. Thanks, Bepsy -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of John Kelley Sent: Tuesday, January 06, 2004 12:24 PM To: ipsec@lists.tislabs.com Subject: Sorry for the repeated postings Our mail system had a slight hiccup over the past couple days. This caused a few postings to be repeated. We believe this is fixed, so hopefully you will only see one copy of this message. Sorry for the noise. -John -- John Kelley Development Engineer Sparta, Inc. Columbia, MD 410.872.1515 x219 410.872.8079 FAX From owner-ipsec@lists.tislabs.com Tue Jan 6 21:29:08 2004 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 i075T7ib046486; Tue, 6 Jan 2004 21:29:07 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA22288 Tue, 6 Jan 2004 23:48:46 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Mon, 5 Jan 2004 12:02:52 -0500 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: new 2401bis versions ... Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, A revised 2401bis was transmitted to the Secretariat on Christmas eve, but has not yet shown up as an I-D. Over the holidays, Karen and I have been busy making additional revisions. So, we will submit a newer version tomorrow, and ask Paul to post it to the archives for faster distribution. please don't bother reading the per-Xmas version when it is posted. Thanks, and sorry for the confusion, Steve From owner-ipsec@lists.tislabs.com Tue Jan 6 21:42:41 2004 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 i075geib049786; Tue, 6 Jan 2004 21:42:40 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA22493 Wed, 7 Jan 2004 00:03:38 -0500 (EST) Date: Tue, 6 Jan 2004 21:50:57 -0500 (EST) From: shogunx To: Bepsy Paul Cc: ipsec@lists.tislabs.com Subject: RE: Sorry for the repeated postings In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_00,WEIRD_PORT autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 6 Jan 2004, Bepsy Paul wrote: > Hi, > > I am looking for an open-source implementation of IKE & IPSEC which is > available for download. Can anyone point out any useful link for downloading > such a source code? your help will be highly appreciated. http://www.freeswan.org > > Thanks, > Bepsy > > > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of John Kelley > Sent: Tuesday, January 06, 2004 12:24 PM > To: ipsec@lists.tislabs.com > Subject: Sorry for the repeated postings > > > > Our mail system had a slight hiccup over the past couple days. This > caused a few postings to be repeated. > We believe this is fixed, so hopefully you will only see one copy of > this message. > > Sorry for the noise. > > -John > > -- > > John Kelley > Development Engineer > Sparta, Inc. > Columbia, MD > 410.872.1515 x219 > 410.872.8079 FAX > > > sleekfreak pirate broadcast world tour 2002-3 live from the pirate hideout http://sleekfreak.ath.cx:81/ From owner-ipsec@lists.tislabs.com Tue Jan 6 22:42:47 2004 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 i076gkib067813; Tue, 6 Jan 2004 22:42:47 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA23280 Wed, 7 Jan 2004 01:01:45 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: Open source IPsec (was: RE: Sorry for the repeated postings) In-reply-to: Your message of "Tue, 06 Jan 2004 18:28:33 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 07 Jan 2004 01:08:05 -0500 Message-ID: <7507.1073455685@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "VPNC" == VPNC writes: VPNC> At 4:05 PM -0800 1/6/04, Bepsy Paul wrote: >> I am looking for an open-source implementation of IKE & IPSEC which is >> available for download. Can anyone point out any useful link for >> downloading such a source code? your help will be highly appreciated. VPNC> Here are three well-known packages that contain open-source IPsec VPNC> and IKE: VPNC> VPNC> And, forked freeswan, at www.openswan.org, and there is also racoon (from KAME) on top of Linux 2.6. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP/uiQ4qHRg3pndX9AQEVlwP5AXZByiZ++gXkKEaloL3am0eiH8ReEDCt oy+w90LXZxlJqhIov+MvdilKqJYh8rza4t5cb8VhVEcULV+6gvUJ7iiQhJUhobrg /qBWGNXCxslh/CmjHO7OAp99deEcFM+/d0eJAeA1wRPsJMAY84TiujQyfxI4LK90 NaEMkRwxQ+U= =JOr1 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Jan 6 22:42:48 2004 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 i076glib067816; Tue, 6 Jan 2004 22:42:47 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA23314 Wed, 7 Jan 2004 01:04:10 -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: Tue, 6 Jan 2004 20:31:15 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: New version of the 2401bis draft Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-12.9 required=5.0 tests=BAYES_00,HABEAS_SWE autolearn=ham version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As reported earlier, Steve and Karen have posted a newer-than-December draft of 2401bis. It can be found at until it appears in the Internet Drafts directory. Note that this is the -02, not the -01 draft. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jan 6 22:42:53 2004 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 i076gqib067849; Tue, 6 Jan 2004 22:42:52 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA23242 Wed, 7 Jan 2004 01:00:06 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Tue, 6 Jan 2004 23:02:26 -0500 To: ipsec@lists.tislabs.com From: Karen Seo Subject: new version of IPsec 2401bis Cc: Ted Tso , Barbara Fraser , Tero Kivinen , Angelos Keromytis , kseo@bbn.com Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, We just submitted a revised draft for 2401bis, "Security Architecture for the Internet Protocol". Karen From owner-ipsec@lists.tislabs.com Tue Jan 6 22:47:09 2004 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 i076l8ib070194; Tue, 6 Jan 2004 22:47:08 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA23368 Wed, 7 Jan 2004 01:07:34 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: <3223A045-4086-11D8-ACBC-000393101764@tislabs.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ipsec@lists.tislabs.com From: John Kelley Subject: Sorry for the repeated postings Date: Tue, 6 Jan 2004 15:23:31 -0500 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Our mail system had a slight hiccup over the past couple days. This caused a few postings to be repeated. We believe this is fixed, so hopefully you will only see one copy of this message. Sorry for the noise. -John -- John Kelley Development Engineer Sparta, Inc. Columbia, MD 410.872.1515 x219 410.872.8079 FAX From owner-ipsec@lists.tislabs.com Tue Jan 6 23:14:17 2004 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 i077EGib080877; Tue, 6 Jan 2004 23:14:16 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA23701 Wed, 7 Jan 2004 01:30:39 -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: Tue, 6 Jan 2004 18:26:18 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: New version of the IKEv2 draft Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-12.9 required=5.0 tests=BAYES_00,HABEAS_SWE autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie has turned in a new version of the IKEv2 draft. The I-D editor is being very, very slow these days, so there is a temporary copy at . I will remove that copy when the draft is officially published. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jan 6 23:18:54 2004 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 i077Irib082429; Tue, 6 Jan 2004 23:18:54 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA23866 Wed, 7 Jan 2004 01:40:44 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 6 Jan 2004 18:28:33 -0800 To: "Bepsy Paul" , From: Paul Hoffman / VPNC Subject: Open source IPsec (was: RE: Sorry for the repeated postings) Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-12.9 required=5.0 tests=BAYES_00,HABEAS_SWE autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:05 PM -0800 1/6/04, Bepsy Paul wrote: > I am looking for an open-source implementation of IKE & IPSEC which is >available for download. Can anyone point out any useful link for downloading >such a source code? your help will be highly appreciated. Here are three well-known packages that contain open-source IPsec and IKE: --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jan 6 23:23:14 2004 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 i077NDib083707; Tue, 6 Jan 2004 23:23:13 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA23845 Wed, 7 Jan 2004 01:40:17 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Mon, 5 Jan 2004 12:02:52 -0500 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: new 2401bis versions ... Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, A revised 2401bis was transmitted to the Secretariat on Christmas eve, but has not yet shown up as an I-D. Over the holidays, Karen and I have been busy making additional revisions. So, we will submit a newer version tomorrow, and ask Paul to post it to the archives for faster distribution. please don't bother reading the per-Xmas version when it is posted. Thanks, and sorry for the confusion, Steve From owner-ipsec@lists.tislabs.com Tue Jan 6 23:24:06 2004 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 i077O5ib083991; Tue, 6 Jan 2004 23:24:05 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA23839 Wed, 7 Jan 2004 01:39:17 -0500 (EST) From: "Bepsy Paul" To: Subject: RE: Sorry for the repeated postings Date: Tue, 6 Jan 2004 16:05:57 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3223A045-4086-11D8-ACBC-000393101764@tislabs.com> X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-1.1 required=5.0 tests=BAYES_01,DATE_IN_PAST_03_06 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am looking for an open-source implementation of IKE & IPSEC which is available for download. Can anyone point out any useful link for downloading such a source code? your help will be highly appreciated. Thanks, Bepsy -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of John Kelley Sent: Tuesday, January 06, 2004 12:24 PM To: ipsec@lists.tislabs.com Subject: Sorry for the repeated postings Our mail system had a slight hiccup over the past couple days. This caused a few postings to be repeated. We believe this is fixed, so hopefully you will only see one copy of this message. Sorry for the noise. -John -- John Kelley Development Engineer Sparta, Inc. Columbia, MD 410.872.1515 x219 410.872.8079 FAX From owner-ipsec@lists.tislabs.com Tue Jan 6 23:52:39 2004 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 i077qdib092811; Tue, 6 Jan 2004 23:52:39 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA24298 Wed, 7 Jan 2004 02:08:52 -0500 (EST) Date: Tue, 6 Jan 2004 21:50:57 -0500 (EST) From: shogunx To: Bepsy Paul Cc: ipsec@lists.tislabs.com Subject: RE: Sorry for the repeated postings In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_00,WEIRD_PORT autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 6 Jan 2004, Bepsy Paul wrote: > Hi, > > I am looking for an open-source implementation of IKE & IPSEC which is > available for download. Can anyone point out any useful link for downloading > such a source code? your help will be highly appreciated. http://www.freeswan.org > > Thanks, > Bepsy > > > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of John Kelley > Sent: Tuesday, January 06, 2004 12:24 PM > To: ipsec@lists.tislabs.com > Subject: Sorry for the repeated postings > > > > Our mail system had a slight hiccup over the past couple days. This > caused a few postings to be repeated. > We believe this is fixed, so hopefully you will only see one copy of > this message. > > Sorry for the noise. > > -John > > -- > > John Kelley > Development Engineer > Sparta, Inc. > Columbia, MD > 410.872.1515 x219 > 410.872.8079 FAX > > > sleekfreak pirate broadcast world tour 2002-3 live from the pirate hideout http://sleekfreak.ath.cx:81/ From owner-ipsec@lists.tislabs.com Wed Jan 7 00:35:45 2004 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 i078Zgib007325; Wed, 7 Jan 2004 00:35:44 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA24982 Wed, 7 Jan 2004 02:53:02 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: <3223A045-4086-11D8-ACBC-000393101764@tislabs.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ipsec@lists.tislabs.com From: John Kelley Subject: Sorry for the repeated postings Date: Tue, 6 Jan 2004 15:23:31 -0500 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Our mail system had a slight hiccup over the past couple days. This caused a few postings to be repeated. We believe this is fixed, so hopefully you will only see one copy of this message. Sorry for the noise. -John -- John Kelley Development Engineer Sparta, Inc. Columbia, MD 410.872.1515 x219 410.872.8079 FAX From owner-ipsec@lists.tislabs.com Wed Jan 7 00:44:00 2004 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 i078i0ib009928; Wed, 7 Jan 2004 00:44:00 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA25185 Wed, 7 Jan 2004 03:06:04 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Tue, 6 Jan 2004 23:02:26 -0500 To: ipsec@lists.tislabs.com From: Karen Seo Subject: new version of IPsec 2401bis Cc: Ted Tso , Barbara Fraser , Tero Kivinen , Angelos Keromytis , kseo@bbn.com Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, We just submitted a revised draft for 2401bis, "Security Architecture for the Internet Protocol". Karen From owner-ipsec@lists.tislabs.com Wed Jan 7 00:44:33 2004 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 i078iWib010142; Wed, 7 Jan 2004 00:44:32 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA25147 Wed, 7 Jan 2004 03:04:41 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: Open source IPsec (was: RE: Sorry for the repeated postings) In-reply-to: Your message of "Tue, 06 Jan 2004 18:28:33 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 07 Jan 2004 01:08:05 -0500 Message-ID: <7507.1073455685@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "VPNC" == VPNC writes: VPNC> At 4:05 PM -0800 1/6/04, Bepsy Paul wrote: >> I am looking for an open-source implementation of IKE & IPSEC which is >> available for download. Can anyone point out any useful link for >> downloading such a source code? your help will be highly appreciated. VPNC> Here are three well-known packages that contain open-source IPsec VPNC> and IKE: VPNC> VPNC> And, forked freeswan, at www.openswan.org, and there is also racoon (from KAME) on top of Linux 2.6. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP/uiQ4qHRg3pndX9AQEVlwP5AXZByiZ++gXkKEaloL3am0eiH8ReEDCt oy+w90LXZxlJqhIov+MvdilKqJYh8rza4t5cb8VhVEcULV+6gvUJ7iiQhJUhobrg /qBWGNXCxslh/CmjHO7OAp99deEcFM+/d0eJAeA1wRPsJMAY84TiujQyfxI4LK90 NaEMkRwxQ+U= =JOr1 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Jan 7 01:00:44 2004 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 i0790iib015341; Wed, 7 Jan 2004 01:00:44 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA25412 Wed, 7 Jan 2004 03:17:58 -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: Tue, 6 Jan 2004 20:31:15 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: New version of the 2401bis draft Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-12.9 required=5.0 tests=BAYES_00,HABEAS_SWE autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As reported earlier, Steve and Karen have posted a newer-than-December draft of 2401bis. It can be found at until it appears in the Internet Drafts directory. Note that this is the -02, not the -01 draft. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Jan 7 01:11:44 2004 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 i079Bhib019068; Wed, 7 Jan 2004 01:11:43 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA25630 Wed, 7 Jan 2004 03:30:58 -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: Tue, 6 Jan 2004 18:26:18 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: New version of the IKEv2 draft Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-12.5 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06, HABEAS_SWE autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie has turned in a new version of the IKEv2 draft. The I-D editor is being very, very slow these days, so there is a temporary copy at . I will remove that copy when the draft is officially published. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Jan 7 01:16:27 2004 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 i079GQib020663; Wed, 7 Jan 2004 01:16:26 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA25606 Wed, 7 Jan 2004 03:29:49 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Mon, 5 Jan 2004 12:02:52 -0500 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: new 2401bis versions ... Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, A revised 2401bis was transmitted to the Secretariat on Christmas eve, but has not yet shown up as an I-D. Over the holidays, Karen and I have been busy making additional revisions. So, we will submit a newer version tomorrow, and ask Paul to post it to the archives for faster distribution. please don't bother reading the per-Xmas version when it is posted. Thanks, and sorry for the confusion, Steve From owner-ipsec@lists.tislabs.com Wed Jan 7 01:19:33 2004 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 i079JXib021628; Wed, 7 Jan 2004 01:19:33 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA25741 Wed, 7 Jan 2004 03:39:09 -0500 (EST) From: "Bepsy Paul" To: Subject: RE: Sorry for the repeated postings Date: Tue, 6 Jan 2004 16:05:57 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3223A045-4086-11D8-ACBC-000393101764@tislabs.com> X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am looking for an open-source implementation of IKE & IPSEC which is available for download. Can anyone point out any useful link for downloading such a source code? your help will be highly appreciated. Thanks, Bepsy -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of John Kelley Sent: Tuesday, January 06, 2004 12:24 PM To: ipsec@lists.tislabs.com Subject: Sorry for the repeated postings Our mail system had a slight hiccup over the past couple days. This caused a few postings to be repeated. We believe this is fixed, so hopefully you will only see one copy of this message. Sorry for the noise. -John -- John Kelley Development Engineer Sparta, Inc. Columbia, MD 410.872.1515 x219 410.872.8079 FAX From owner-ipsec@lists.tislabs.com Wed Jan 7 01:21:22 2004 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 i079LMib022284; Wed, 7 Jan 2004 01:21:22 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA25764 Wed, 7 Jan 2004 03:39:44 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 6 Jan 2004 18:28:33 -0800 To: "Bepsy Paul" , From: Paul Hoffman / VPNC Subject: Open source IPsec (was: RE: Sorry for the repeated postings) Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-12.5 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06, HABEAS_SWE autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:05 PM -0800 1/6/04, Bepsy Paul wrote: > I am looking for an open-source implementation of IKE & IPSEC which is >available for download. Can anyone point out any useful link for downloading >such a source code? your help will be highly appreciated. Here are three well-known packages that contain open-source IPsec and IKE: --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Jan 7 01:57:58 2004 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 i079vvib034341; Wed, 7 Jan 2004 01:57:57 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA26256 Wed, 7 Jan 2004 04:15:41 -0500 (EST) Date: Tue, 6 Jan 2004 21:50:57 -0500 (EST) From: shogunx To: Bepsy Paul Cc: ipsec@lists.tislabs.com Subject: RE: Sorry for the repeated postings In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06, WEIRD_PORT autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 6 Jan 2004, Bepsy Paul wrote: > Hi, > > I am looking for an open-source implementation of IKE & IPSEC which is > available for download. Can anyone point out any useful link for downloading > such a source code? your help will be highly appreciated. http://www.freeswan.org > > Thanks, > Bepsy > > > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of John Kelley > Sent: Tuesday, January 06, 2004 12:24 PM > To: ipsec@lists.tislabs.com > Subject: Sorry for the repeated postings > > > > Our mail system had a slight hiccup over the past couple days. This > caused a few postings to be repeated. > We believe this is fixed, so hopefully you will only see one copy of > this message. > > Sorry for the noise. > > -John > > -- > > John Kelley > Development Engineer > Sparta, Inc. > Columbia, MD > 410.872.1515 x219 > 410.872.8079 FAX > > > sleekfreak pirate broadcast world tour 2002-3 live from the pirate hideout http://sleekfreak.ath.cx:81/ From owner-ipsec@lists.tislabs.com Wed Jan 7 02:45:12 2004 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 i07AjBib038976; Wed, 7 Jan 2004 02:45:11 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA27096 Wed, 7 Jan 2004 05:06:06 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: <3223A045-4086-11D8-ACBC-000393101764@tislabs.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ipsec@lists.tislabs.com From: John Kelley Subject: Sorry for the repeated postings Date: Tue, 6 Jan 2004 15:23:31 -0500 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Our mail system had a slight hiccup over the past couple days. This caused a few postings to be repeated. We believe this is fixed, so hopefully you will only see one copy of this message. Sorry for the noise. -John -- John Kelley Development Engineer Sparta, Inc. Columbia, MD 410.872.1515 x219 410.872.8079 FAX From owner-ipsec@lists.tislabs.com Wed Jan 7 02:56:01 2004 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 i07Au0ib039331; Wed, 7 Jan 2004 02:56:00 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA27244 Wed, 7 Jan 2004 05:15:05 -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: Tue, 6 Jan 2004 20:31:15 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: New version of the 2401bis draft Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-12.5 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06, HABEAS_SWE autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As reported earlier, Steve and Karen have posted a newer-than-December draft of 2401bis. It can be found at until it appears in the Internet Drafts directory. Note that this is the -02, not the -01 draft. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Jan 7 03:02:57 2004 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 i07B2uib040175; Wed, 7 Jan 2004 03:02:57 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA27416 Wed, 7 Jan 2004 05:25:20 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: Open source IPsec (was: RE: Sorry for the repeated postings) In-reply-to: Your message of "Tue, 06 Jan 2004 18:28:33 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 07 Jan 2004 01:08:05 -0500 Message-ID: <7507.1073455685@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "VPNC" == VPNC writes: VPNC> At 4:05 PM -0800 1/6/04, Bepsy Paul wrote: >> I am looking for an open-source implementation of IKE & IPSEC which is >> available for download. Can anyone point out any useful link for >> downloading such a source code? your help will be highly appreciated. VPNC> Here are three well-known packages that contain open-source IPsec VPNC> and IKE: VPNC> VPNC> And, forked freeswan, at www.openswan.org, and there is also racoon (from KAME) on top of Linux 2.6. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP/uiQ4qHRg3pndX9AQEVlwP5AXZByiZ++gXkKEaloL3am0eiH8ReEDCt oy+w90LXZxlJqhIov+MvdilKqJYh8rza4t5cb8VhVEcULV+6gvUJ7iiQhJUhobrg /qBWGNXCxslh/CmjHO7OAp99deEcFM+/d0eJAeA1wRPsJMAY84TiujQyfxI4LK90 NaEMkRwxQ+U= =JOr1 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Jan 7 03:03:12 2004 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 i07B3Bib040210; Wed, 7 Jan 2004 03:03:11 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA27402 Wed, 7 Jan 2004 05:25:04 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Mon, 5 Jan 2004 12:02:52 -0500 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: new 2401bis versions ... Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, A revised 2401bis was transmitted to the Secretariat on Christmas eve, but has not yet shown up as an I-D. Over the holidays, Karen and I have been busy making additional revisions. So, we will submit a newer version tomorrow, and ask Paul to post it to the archives for faster distribution. please don't bother reading the per-Xmas version when it is posted. Thanks, and sorry for the confusion, Steve From owner-ipsec@lists.tislabs.com Wed Jan 7 03:21:41 2004 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 i07BLeib041614; Wed, 7 Jan 2004 03:21:41 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA27610 Wed, 7 Jan 2004 05:43:54 -0500 (EST) From: "Bepsy Paul" To: Subject: RE: Sorry for the repeated postings Date: Tue, 6 Jan 2004 16:05:57 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3223A045-4086-11D8-ACBC-000393101764@tislabs.com> X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am looking for an open-source implementation of IKE & IPSEC which is available for download. Can anyone point out any useful link for downloading such a source code? your help will be highly appreciated. Thanks, Bepsy -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of John Kelley Sent: Tuesday, January 06, 2004 12:24 PM To: ipsec@lists.tislabs.com Subject: Sorry for the repeated postings Our mail system had a slight hiccup over the past couple days. This caused a few postings to be repeated. We believe this is fixed, so hopefully you will only see one copy of this message. Sorry for the noise. -John -- John Kelley Development Engineer Sparta, Inc. Columbia, MD 410.872.1515 x219 410.872.8079 FAX From owner-ipsec@lists.tislabs.com Wed Jan 7 04:51:05 2004 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 i07Cp4ib045838; Wed, 7 Jan 2004 04:51:05 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA28558 Wed, 7 Jan 2004 07:12:06 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: <3223A045-4086-11D8-ACBC-000393101764@tislabs.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ipsec@lists.tislabs.com From: John Kelley Subject: Sorry for the repeated postings Date: Tue, 6 Jan 2004 15:23:31 -0500 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Our mail system had a slight hiccup over the past couple days. This caused a few postings to be repeated. We believe this is fixed, so hopefully you will only see one copy of this message. Sorry for the noise. -John -- John Kelley Development Engineer Sparta, Inc. Columbia, MD 410.872.1515 x219 410.872.8079 FAX From owner-ipsec@lists.tislabs.com Wed Jan 7 05:10:30 2004 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 i07DATib046948; Wed, 7 Jan 2004 05:10:29 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA28748 Wed, 7 Jan 2004 07:32:25 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Mon, 5 Jan 2004 12:02:52 -0500 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: new 2401bis versions ... Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, A revised 2401bis was transmitted to the Secretariat on Christmas eve, but has not yet shown up as an I-D. Over the holidays, Karen and I have been busy making additional revisions. So, we will submit a newer version tomorrow, and ask Paul to post it to the archives for faster distribution. please don't bother reading the per-Xmas version when it is posted. Thanks, and sorry for the confusion, Steve From owner-ipsec@lists.tislabs.com Wed Jan 7 06:39:04 2004 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 i07Ed3ib051967; Wed, 7 Jan 2004 06:39:04 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA29997 Wed, 7 Jan 2004 08:58:09 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: <0C593E6E-411B-11D8-BBC9-000393101764@tislabs.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ipsec@lists.tislabs.com From: John Kelley Subject: There was another issue Date: Wed, 7 Jan 2004 09:09:03 -0500 X-Mailer: Apple Mail (2.609) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In addition to a mail hiccup, there was a list subscriber who was reflecting messages back to the list. That subscriber has been removed. Hopefully, you will only see one copy of this posting. -John -- John Kelley Development Engineer Sparta, Inc. Columbia, MD 410.872.1515 x219 410.872.8079 FAX From owner-ipsec@lists.tislabs.com Wed Jan 7 08:43:35 2004 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 i07GhZib058736; Wed, 7 Jan 2004 08:43:35 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00685 Wed, 7 Jan 2004 10:50:56 -0500 (EST) Date: Wed, 7 Jan 2004 10:50:56 -0500 (EST) From: owner-ipsec@lists.tislabs.com Message-Id: <200401071550.KAA00685@lists.tislabs.com> SMTPSVC(6.0.3790.1069); Tue, 6 Jan 2004 17:57:54 -0800 17:58:09 -0800 Microsoft SMTPSVC(6.0.3790.1069); Tue, 6 Jan 2004 17:58:05 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: New IKEv2 draft: draft-ietf-ipsec-ikev2-12.txt Date: Tue, 6 Jan 2004 17:57:35 -0800 Message-ID: Thread-Topic: New IKEv2 draft: draft-ietf-ipsec-ikev2-12.txt thread-index: AcPUwZ7hawLk/tvsTlSLO3ztI5OAEg== From: "Charlie Kaufman" To: X-OriginalArrivalTime: 07 Jan 2004 01:58:05.0271 (UTC) FILETIME=[B0930E70:01C3D4C1] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3D4C1.B0928E15" ------_=_NextPart_001_01C3D4C1.B0928E15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I just forwarded it to internet-drafts, copying Paul Hoffman in hope he will post it on his web page faster than the I-D editor will get to it. =20 I believe this version is going to IETF last call. The changes from the last version are: =20 H.12 Changes from IKEv2-11 to IKEv2-12 January 2004 =20 1) Made the values of the one byte IPsec Protocol ID consistent between payloads and made the naming more nearly consistent. =20 2) Changed the specification to require that AUTH payloads be provided in EAP exchanges even when a non-key generating EAP method is used. This protects against certain obscure cryptographic threats. =20 3) Changed all example IP addresses to be within subnet 10. =20 4) Specified that issues surrounding weak keys and DES key parity must be addressed in algorithm documents. =20 5) Removed the unsupported (and probably untrue) claim that Photuris cookies were given that name because the IETF always supports proposals involving cookies. =20 6) Fixed some text that specified that Transform ID was 1 octet while everywhere else said it was 2 octets. =20 7) Corrected the ASN.1 specification of the encoding of X.509 certificate bundles. =20 8) Added an INVALID_SELECTORS error type. =20 9) Replaced IANA considerations section with a reference to draft- ietf-ipsec-ikev2-iana-00.txt. =20 10) Removed 2 obsolete informative references and added one to a paper on UDP fragmentation problems. =20 11) 41 Editorial Corrections and Clarifications. =20 12) 6 Grammatical and Spelling errors fixed. =20 13) 4 Corrected capitalizations of MAY/MUST/etc. =20 14) 4 Attempts to make capitalization and use of underscores more consistent. =20 =20 =20 ------_=_NextPart_001_01C3D4C1.B0928E15 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I just forwarded it to internet-drafts, copying Paul = Hoffman in hope he will post it on his web page faster than the I-D editor will = get to it.

 

I believe this version is going to IETF last call. = The changes from the last version are:

 

H.12 Changes from IKEv2-11 to IKEv2-12 January = 2004

 

   1) Made the values of the one byte IPsec Protocol ID consistent

   between payloads and made the naming = more nearly consistent.

 

   2) Changed the specification to require = that AUTH payloads be

   provided in EAP exchanges even when a = non-key generating EAP method

   is used.  This protects against = certain obscure cryptographic

   threats.

 

   3) Changed all example IP addresses to = be within subnet 10.

 

   4) Specified that issues surrounding = weak keys and DES key parity

   must be addressed in algorithm = documents.

 

   5) Removed the unsupported (and probably untrue) claim that Photuris

   cookies were given that name because the = IETF always supports

   proposals involving = cookies.

 

   6) Fixed some text that specified that Transform ID was 1 octet while

   everywhere else said it was 2 = octets.

 

   7) Corrected the ASN.1 specification of = the encoding of X.509

   certificate = bundles.

 

   8) Added an INVALID_SELECTORS error = type.

 

   9) Replaced IANA considerations section = with a reference to draft-

   = ietf-ipsec-ikev2-iana-00.txt.

 

   10) Removed 2 obsolete informative = references and added one to a

   paper on UDP fragmentation = problems.

 

   11) 41 Editorial Corrections and Clarifications.

 

   12) 6 Grammatical and Spelling errors = fixed.

 

   13) 4 Corrected capitalizations of MAY/MUST/etc.

 

   14) 4 Attempts to make capitalization = and use of underscores more

   consistent.

 

 

 

------_=_NextPart_001_01C3D4C1.B0928E15-- --------------InterScan_NT_MIME_Boundary-- From owner-ipsec@lists.tislabs.com Wed Jan 7 09:16:59 2004 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 i07HGxib061439; Wed, 7 Jan 2004 09:16:59 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00958 Wed, 7 Jan 2004 11:33:13 -0500 (EST) From: "Shannon Wells" To: Subject: US Government VPN Protection Profile Date: Wed, 7 Jan 2004 11:36:57 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C3D512.8ECE2CB0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C3D512.8ECE2CB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This message is directed toward the VPN vendors on this list: Tresys Technology is seeking POCs at various VPN vendor sites to review and comment on the US Government Virtual Private Network (VPN) Boundary Gateway Protection Profile for Medium Robustness Environments. This document has been drafted to outline security requirements for the US Government. We are currently working with the National Security Agency to vet this document to VPN industry. If you are interested in reviewing and submitting comments on this document, please contact me for further instructions. Thanks for your attention in this matter. Regards, Shannon S. Wells swells@tresys.com Tresys Technology, LLC. 410.290.1411 x107 410-953-0494 fax www.tresys.com ------=_NextPart_000_0001_01C3D512.8ECE2CB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This message is = directed toward=20 the VPN vendors on this list:
 
Tresys Technology = is=20 seeking POCs at various VPN vendor sites to review and comment = on the=20 US Government Virtual Private = Network=20 (VPN) Boundary Gateway Protection Profile=20 for Medium Robustness Environments. This document has been = drafted=20 to outline security requirements = for the=20 US Government. We are currently = working=20 with the National Security Agency to vet this document to VPN industry.
 
If you are = interested in=20 reviewing and submitting comments on this document, please contact = me for further instructions.
 
Thanks for your = attention in=20 this matter.

Regards,

Shannon S. Wells
swells@tresys.com
Tresys = Technology,=20 LLC.
410.290.1411 x107

410-953-0494 fax

www.tresys.com

 
------=_NextPart_000_0001_01C3D512.8ECE2CB0-- From owner-ipsec@lists.tislabs.com Wed Jan 7 14:33:46 2004 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 i07MXjib078581; Wed, 7 Jan 2004 14:33:46 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02705 Wed, 7 Jan 2004 16:44:32 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Tue, 6 Jan 2004 23:02:26 -0500 To: ipsec@lists.tislabs.com From: Karen Seo Subject: new version of IPsec 2401bis Cc: Ted Tso , Barbara Fraser , Tero Kivinen , Angelos Keromytis , kseo@bbn.com Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-4.5 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06 autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, We just submitted a revised draft for 2401bis, "Security Architecture for the Internet Protocol". Karen From owner-ipsec@lists.tislabs.com Wed Jan 7 14:33:51 2004 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 i07MXpib078603; Wed, 7 Jan 2004 14:33:51 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02706 Wed, 7 Jan 2004 16:44:33 -0500 (EST) Date: Tue, 6 Jan 2004 21:50:57 -0500 (EST) From: shogunx To: Bepsy Paul Cc: ipsec@lists.tislabs.com Subject: RE: Sorry for the repeated postings In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-2.8 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12, WEIRD_PORT autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 6 Jan 2004, Bepsy Paul wrote: > Hi, > > I am looking for an open-source implementation of IKE & IPSEC which is > available for download. Can anyone point out any useful link for downloading > such a source code? your help will be highly appreciated. http://www.freeswan.org > > Thanks, > Bepsy > > > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of John Kelley > Sent: Tuesday, January 06, 2004 12:24 PM > To: ipsec@lists.tislabs.com > Subject: Sorry for the repeated postings > > > > Our mail system had a slight hiccup over the past couple days. This > caused a few postings to be repeated. > We believe this is fixed, so hopefully you will only see one copy of > this message. > > Sorry for the noise. > > -John > > -- > > John Kelley > Development Engineer > Sparta, Inc. > Columbia, MD > 410.872.1515 x219 > 410.872.8079 FAX > > > sleekfreak pirate broadcast world tour 2002-3 live from the pirate hideout http://sleekfreak.ath.cx:81/ From owner-ipsec@lists.tislabs.com Wed Jan 7 14:33:56 2004 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 i07MXuib078617; Wed, 7 Jan 2004 14:33:56 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02747 Wed, 7 Jan 2004 16:47:54 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 6 Jan 2004 18:28:33 -0800 To: "Bepsy Paul" , From: Paul Hoffman / VPNC Subject: Open source IPsec (was: RE: Sorry for the repeated postings) Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-12.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12, HABEAS_SWE autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:05 PM -0800 1/6/04, Bepsy Paul wrote: > I am looking for an open-source implementation of IKE & IPSEC which is >available for download. Can anyone point out any useful link for downloading >such a source code? your help will be highly appreciated. Here are three well-known packages that contain open-source IPsec and IKE: --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Jan 7 14:34:02 2004 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 i07MY1ib078628; Wed, 7 Jan 2004 14:34:01 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02694 Wed, 7 Jan 2004 16:44:09 -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: Tue, 6 Jan 2004 18:26:18 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: New version of the IKEv2 draft Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-12.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12, HABEAS_SWE autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie has turned in a new version of the IKEv2 draft. The I-D editor is being very, very slow these days, so there is a temporary copy at . I will remove that copy when the draft is officially published. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Jan 7 14:35:46 2004 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 i07MZjib078720; Wed, 7 Jan 2004 14:35:45 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02717 Wed, 7 Jan 2004 16:44:53 -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: Tue, 6 Jan 2004 20:31:15 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: New version of the 2401bis draft Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail1.rz.fh-rosenheim.de X-Spam-Status: No, hits=-12.5 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06, HABEAS_SWE autolearn=no version=2.61 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As reported earlier, Steve and Karen have posted a newer-than-December draft of 2401bis. It can be found at until it appears in the Internet Drafts directory. Note that this is the -02, not the -01 draft. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Jan 7 15:22:57 2004 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 i07NMuib081467; Wed, 7 Jan 2004 15:22:56 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA03262 Wed, 7 Jan 2004 17:39:17 -0500 (EST) Date: Wed, 7 Jan 2004 17:50:07 -0500 From: Ken Ballou To: ipsec@lists.tislabs.com Subject: Contradictory language in the 2401bis draft section 4.1? Message-ID: <20040107225007.GI1663@datapower.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 Am I misreading the text? I believe there is contradictory text in section 4.1 (draft-ietf-ipsec-rfc2401bis-02.txt). On one hand, in the third full paragraph on page 10, I read: "... transport mode MAY be used between security gateways or between a security gateway and a host." On the other hand, in the paragraph that spans pages 11 and 12, I read: "In general, whenever either end of a security association is a security gateway, the SA MUST be tunnel mode." I suspect the text following this sentence (citing an example of SNMP commands destined to the security gateway system) clarifies this. Still, I wonder whether I am entirely alone in finding the text somewhat confusing. - Ken From owner-ipsec@lists.tislabs.com Wed Jan 7 16:56:20 2004 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 i080uKib088167; Wed, 7 Jan 2004 16:56:20 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA04302 Wed, 7 Jan 2004 19:13:02 -0500 (EST) Message-ID: <3FFCA30A.5090703@isi.edu> Date: Wed, 07 Jan 2004 16:23:38 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Ballou CC: ipsec@lists.tislabs.com Subject: Re: Contradictory language in the 2401bis draft section 4.1? References: <20040107225007.GI1663@datapower.com> In-Reply-To: <20040107225007.GI1663@datapower.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ken Ballou wrote: > Am I misreading the text? I believe there is contradictory text in > section 4.1 (draft-ietf-ipsec-rfc2401bis-02.txt). > > On one hand, in the third full paragraph on page 10, I read: > > "... transport mode MAY be used between security gateways or between a > security gateway and a host." > > On the other hand, in the paragraph that spans pages 11 and 12, I read: > > "In general, whenever either end of a security association is a security > gateway, the SA MUST be tunnel mode." > > I suspect the text following this sentence (citing an example of SNMP > commands destined to the security gateway system) clarifies this. Still, > I wonder whether I am entirely alone in finding the text somewhat confusing. > > - Ken It seems like pg 11-12 should be updated. There are some other areas, notably Appendix B, in section B.3.1, there's a note: > Looking at the diagram below of a security gateway tunnel (as > mentioned elsewhere, security gateways do not use transport > mode)... FWIW, it might be useful if the first section (4) refs our ID (draft-touch-ipsec-vpn-*) on this issue, perhaps as informational (though soon we should have an RFC number, hopefully). Joe From owner-ipsec@lists.tislabs.com Wed Jan 7 19:20:44 2004 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 i083Khib098551; Wed, 7 Jan 2004 19:20:43 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA05465 Wed, 7 Jan 2004 21:38:54 -0500 (EST) Message-Id: <5.2.0.9.0.20040107150509.04536e98@10.1.5.10> X-Sender: vamsi@10.1.5.10 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 07 Jan 2004 18:47:47 -0800 To: ipsec@lists.tislabs.com From: vamsi Subject: TFC in IKEv1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, TFC padding in the ESPv3 draft states that the SA management protocol must negotiate the TFC service prior to employing the service. Is there any draft explaining how TFC attribute can be negotiated as part of IKE v1 exchanges? Can any one Please share the information how to use TFC (Traffic Flow confidentiality) in IKEv1? regards vamsi From owner-ipsec@lists.tislabs.com Thu Jan 8 05:49:35 2004 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 i08DnYib098467; Thu, 8 Jan 2004 05:49:34 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08775 Thu, 8 Jan 2004 08:10:25 -0500 (EST) Message-Id: <200401072101.QAA01462@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ikev2-12.txt Date: Wed, 07 Jan 2004 16:01:15 -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 : Internet Key Exchange (IKEv2) Protocol Author(s) : C. Kaufman Filename : draft-ietf-ipsec-ikev2-12.txt Pages : 102 Date : 2004-1-7 This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations. This version of the IKE specification combines the contents of what were previously separate documents, including ISAKMP (RFC 2408), IKE (RFC 2409), the Internet DOI (RFC 2407), NAT Traversal, Legacy authentication, and remote address acquisition. Version 2 of IKE does not interoperate with version 1, but it has enough of the header format in common that both versions can unambiguously run over the same UDP port. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-12.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ikev2-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-12.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: <2004-1-7152620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-7152620.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Jan 8 05:49:36 2004 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 i08Dnaib098478; Thu, 8 Jan 2004 05:49:36 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08791 Thu, 8 Jan 2004 08:11:48 -0500 (EST) Message-Id: <200401072101.QAA01481@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-rfc2401bis-01.txt Date: Wed, 07 Jan 2004 16:01:24 -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 : Security Architecture for the Internet Protocol Author(s) : S. Kent, K. Seo Filename : draft-ietf-ipsec-rfc2401bis-01.txt Pages : 53 Date : 2004-1-7 This memo specifies the base architecture for IPsec compliant systems. The goal of the architecture is to provide various security services for traffic at the IP layer, in both the IPv4 and IPv6 environments. This document describes the goals of such systems, their components and how they fit together with each other and into the IP environment. It also describes the security services offered by the IPsec protocols, and how these services can be employed in the IP environment. This document does not address all aspects of IPsec architecture. Subsequent documents will address additional architectural details of a more advanced nature, e.g., use of IPsec in NAT environments and more complete support for IP multicast. The following fundamental components of the IPsec security architecture are discussed in terms of their underlying, required functionality. Additional RFCs (see Section 1.3 for pointers to other documents) define the protocols in (a), (c), and (d). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2401bis-01.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-rfc2401bis-01.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-rfc2401bis-01.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: <2004-1-7152637.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-rfc2401bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-rfc2401bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-7152637.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Jan 8 09:46:17 2004 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 i08HkHib010195; Thu, 8 Jan 2004 09:46:17 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10118 Thu, 8 Jan 2004 12:05:42 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <20040107225007.GI1663@datapower.com> References: <20040107225007.GI1663@datapower.com> Date: Thu, 8 Jan 2004 12:10:32 -0500 To: Ken Ballou From: Stephen Kent Subject: Re: Contradictory language in the 2401bis draft section 4.1? Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 17:50 -0500 1/7/04, Ken Ballou wrote: >Am I misreading the text? I believe there is contradictory text in >section 4.1 (draft-ietf-ipsec-rfc2401bis-02.txt). > >On one hand, in the third full paragraph on page 10, I read: > >"... transport mode MAY be used between security gateways or between a >security gateway and a host." > >On the other hand, in the paragraph that spans pages 11 and 12, I read: > >"In general, whenever either end of a security association is a security >gateway, the SA MUST be tunnel mode." whoops. we missed that old text. we will fix it to be consistent with the new guidance on use of transport mode. Steve From owner-ipsec@lists.tislabs.com Thu Jan 8 15:34:52 2004 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 i08NYpib035632; Thu, 8 Jan 2004 15:34:51 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11773 Thu, 8 Jan 2004 17:52:55 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.2.0.9.0.20040107150509.04536e98@10.1.5.10> References: <5.2.0.9.0.20040107150509.04536e98@10.1.5.10> Date: Thu, 8 Jan 2004 17:59:11 -0500 To: vamsi From: Stephen Kent Subject: Re: TFC in IKEv1 Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 18:47 -0800 1/7/04, vamsi wrote: >Hi, >TFC padding in the ESPv3 draft states that the SA management >protocol must negotiate the TFC service prior to employing the >service. > Is there any draft explaining how TFC attribute can be negotiated >as part of IKE v1 exchanges? >Can any one Please share the information how to use TFC (Traffic >Flow confidentiality) in IKEv1? > > >regards > vamsi There is no provision to negotiate this facility in IKEv1, as you have noticed. Since the extensions for TFC are in ESPv2, and since we anticipate folks who use ESPv2 will also use IKEv2, we have not made plans to create a DOI for IKEv1 that defines a suitable extension. However, note that one probably could use the ESP TFC conventions safely even without negotiation, in many cases. Steve From owner-ipsec@lists.tislabs.com Thu Jan 8 15:34:52 2004 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 i08NYpib035633; Thu, 8 Jan 2004 15:34:51 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11809 Thu, 8 Jan 2004 17:56:52 -0500 (EST) Message-ID: <003101c3d63b$bec7de50$c91167c0@adithya> From: "Mohan Parthasarathy" To: Subject: IKEv1 and multiple SAs ? Date: Thu, 8 Jan 2004 15:04:18 -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 IKEv2 (section 2.8) draft talks about the IKEv1 rekying heuristic where IKEv1 implementations delete old SAs when a new SA is established for the same traffic selector. Do these implementations delete the SA always in these cases or only when they see a INITIAL_CONTACT notify message also ? Are these common ? Any information would be appreciated. thanks mohan From owner-ipsec@lists.tislabs.com Thu Jan 8 16:09:30 2004 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 i0909Tib037240; Thu, 8 Jan 2004 16:09:29 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11975 Thu, 8 Jan 2004 18:25:39 -0500 (EST) Message-ID: <0ac801c3d640$98c6eb10$b110a8c0@Tarun> From: "Tarun Ahuja" To: Subject: length of IV in ESP_NULL cipher Date: Thu, 8 Jan 2004 15:38:59 -0800 Organization: Cavium Networks Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 08 Jan 2004 23:36:08.0081 (UTC) FILETIME=[30C28010:01C3D640] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all What should be the length of the IV in case of NULL cipher when using ESP protocol? As per RFC 2410 "Because of the stateless nature of the NULL encryption algorithm, it is not necessary to transmit an IV or similar cryptographic synchronization data on a per packet (or even a per SA) basis". Which essentially means the length of the IV should be 0 but FreeSWAN uses a length of 4bytes IV (equal to blocksize) for NULL cipher. -Tarun From owner-ipsec@lists.tislabs.com Thu Jan 8 17:10:11 2004 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 i091ABib039965; Thu, 8 Jan 2004 17:10:11 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12488 Thu, 8 Jan 2004 19:31:04 -0500 (EST) Date: Thu, 8 Jan 2004 16:39:55 -0800 (PST) From: Scott Fluhrer To: Tarun Ahuja cc: ipsec@lists.tislabs.com Subject: Re: length of IV in ESP_NULL cipher In-Reply-To: <0ac801c3d640$98c6eb10$b110a8c0@Tarun> Message-ID: References: <0ac801c3d640$98c6eb10$b110a8c0@Tarun> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 8 Jan 2004, Tarun Ahuja wrote: > Hi all > > What should be the length of the IV in case of NULL cipher when using ESP > protocol? > > As per RFC 2410 > "Because of the stateless nature of the NULL encryption algorithm, it is not > necessary to transmit an IV or similar cryptographic > synchronization data on a per packet (or even a per SA) basis". To quote later on in RFC 2410: To facilitate interoperability, the IV size for this algorithm MUST be zero (0) bits. > > Which essentially means the length of the IV should be 0 but FreeSWAN uses a > length of 4bytes IV (equal to blocksize) for NULL cipher. Well, either FreeSWAN is broke (at least in this respect) or you are mistaken about the operation of the FreeSWAN code. -- scott From owner-ipsec@lists.tislabs.com Fri Jan 9 02:02:36 2004 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 i09A2Zib036608; Fri, 9 Jan 2004 02:02:35 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA15543 Fri, 9 Jan 2004 04:19:07 -0500 (EST) Message-Id: <200401090927.i099RNSj037727@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Mohan Parthasarathy" cc: ipsec@lists.tislabs.com Subject: Re: IKEv1 and multiple SAs ? In-reply-to: Your message of Thu, 08 Jan 2004 15:04:18 PST. <003101c3d63b$bec7de50$c91167c0@adithya> Date: Fri, 09 Jan 2004 10:27:23 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: IKEv2 (section 2.8) draft talks about the IKEv1 rekying heuristic where IKEv1 implementations delete old SAs when a new SA is established for the same traffic selector. => this is about rekeying of IPsec SAs (not what happens with IKE/ISAKMP SAs). In IKEv1 the replaced IPsec SAs are explicitely deleted, in IKEv2 they are flushed on timeout, i.e., implicitely deleted. Do these implementations delete the SA always in these cases => IPsec SAs are always deleted when asked or when they have reached their hard timeout. or only when they see a INITIAL_CONTACT notify message also ? => the INITIAL_CONTACT is very different: it is sent by a peer which believes it has no SA, i.e., already existing SAs are from a previous session and the peer has lost any state about it. Any information would be appreciated. => RFC 2407 4.6.3.3 for INITIAL_CONTACT draft-ietf-ipsec-ikev2-11.txt pages 64-65 (different because the IKEv2 spec is about previous IKE SAs) isakmp_inf.c:info_recv_initialcontact() (with this cryptic comment: /* * delete all phase2 sa relatived to the destination address. * Don't delete Phase 1 handlers on INITIAL-CONTACT, and don't ignore * an INITIAL-CONTACT if we have contacted the peer. This matches the * Sun IKE behavior, and makes rekeying work much better when the peer * restarts. */) Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Fri Jan 9 07:05:03 2004 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 i09F52ib055104; Fri, 9 Jan 2004 07:05:03 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17192 Fri, 9 Jan 2004 09:21:20 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <0ac801c3d640$98c6eb10$b110a8c0@Tarun> References: <0ac801c3d640$98c6eb10$b110a8c0@Tarun> Date: Fri, 9 Jan 2004 09:28:03 -0500 To: "Tarun Ahuja" From: Stephen Kent Subject: Re: length of IV in ESP_NULL cipher 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 15:38 -0800 1/8/04, Tarun Ahuja wrote: >Hi all > >What should be the length of the IV in case of NULL cipher when using ESP >protocol? > >As per RFC 2410 >"Because of the stateless nature of the NULL encryption algorithm, it is not >necessary to transmit an IV or similar cryptographic >synchronization data on a per packet (or even a per SA) basis". > >Which essentially means the length of the IV should be 0 but FreeSWAN uses a >length of 4bytes IV (equal to blocksize) for NULL cipher. > >-Tarun If FreeSWAN used an IV length of 4, someone needs to have a talk with them. Of course the length should be 0. Anything else is just wasted overhead. Steve From owner-ipsec@lists.tislabs.com Fri Jan 9 07:37:51 2004 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 i09Fboib056311; Fri, 9 Jan 2004 07:37:51 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17503 Fri, 9 Jan 2004 09:59:29 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16382.50245.682335.168125@gargle.gargle.HOWL> Date: Fri, 9 Jan 2004 10:09:57 -0500 From: Paul Koning To: tarun.ahuja@cavium.com CC: ipsec@lists.tislabs.com Subject: Re: length of IV in ESP_NULL cipher References: <0ac801c3d640$98c6eb10$b110a8c0@Tarun> X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Scott" == Scott Fluhrer writes: Scott> On Thu, 8 Jan 2004, Tarun Ahuja wrote: >> Which essentially means the length of the IV should be 0 but >> FreeSWAN uses a length of 4bytes IV (equal to blocksize) for NULL >> cipher. Scott> Well, either FreeSWAN is broke (at least in this respect) or Scott> you are mistaken about the operation of the FreeSWAN code. Agreed. I'm pretty sure I had our (Xedia) implementation talking to FreeSWAN some years ago, so my suspicion is that the implementation is actually correct. Are you looking at the packet length when you made this observation? Remember that ESP_NULL DOES require padding (to multiples of four) because that's the minimum requirement in ESP independent of cipher. I think I have seen implementations (at least back in 1999 or so) that got this wrong. paul From owner-ipsec@lists.tislabs.com Fri Jan 9 10:51:52 2004 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 i09Ippib066623; Fri, 9 Jan 2004 10:51:52 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18622 Fri, 9 Jan 2004 13:07:04 -0500 (EST) Message-ID: <003201c3d6dc$54c5bc60$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Francis Dupont" Cc: References: <200401090927.i099RNSj037727@givry.rennes.enst-bretagne.fr> Subject: Re: IKEv1 and multiple SAs ? Date: Fri, 9 Jan 2004 10:13:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis, > In your previous mail you wrote: > > IKEv2 (section 2.8) draft talks about the IKEv1 rekying heuristic where > IKEv1 implementations delete old SAs when a new SA is established for the > same traffic selector. > > => this is about rekeying of IPsec SAs (not what happens with IKE/ISAKMP SAs). > In IKEv1 the replaced IPsec SAs are explicitely deleted, in IKEv2 they are > flushed on timeout, i.e., implicitely deleted. > Thanks for the clarification. I was asking about the old IPsec SAs (not the replaced SAs) which IKEv1 implementations implicitly deleted. Does all IKEv1 implementations do so when a new IPsec SA is setup for the same traffic selectors ? > Do these implementations delete the SA always in these cases > > => IPsec SAs are always deleted when asked or when they have reached their > hard timeout. > That's not what i read from section 2.8 of IKEv2 draft. > or only when they see a INITIAL_CONTACT notify message also ? > > => the INITIAL_CONTACT is very different: it is sent by a peer which > believes it has no SA, i.e., already existing SAs are from a previous > session and the peer has lost any state about it. > This means, only when i see a INITIAL_CONTACT, i can clean up all old IKE SAs and IPsec SAs. Correct ? Is that what the existing implementations do ? > Any information would be appreciated. > > => RFC 2407 4.6.3.3 for INITIAL_CONTACT > draft-ietf-ipsec-ikev2-11.txt pages 64-65 > (different because the IKEv2 spec is about previous IKE SAs) This is a bit confusing. Why would you keep the IPsec SAs around in this case ? The sender by sending INITIAL_CONTACT says that this is the only IKE SA. This implies that he has no previous IKE SAs or IPsec SAs which means the receiver can delete all of them. Why is it specific to IKE SAs ? -mohan > isakmp_inf.c:info_recv_initialcontact() > (with this cryptic comment: > /* > * delete all phase2 sa relatived to the destination address. > * Don't delete Phase 1 handlers on INITIAL-CONTACT, and don't ignore > * an INITIAL-CONTACT if we have contacted the peer. This matches the > * Sun IKE behavior, and makes rekeying work much better when the peer > * restarts. > */) > > Regards > > Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Fri Jan 9 12:52:59 2004 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 i09Kquib072945; Fri, 9 Jan 2004 12:52:58 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19402 Fri, 9 Jan 2004 15:09:17 -0500 (EST) Message-ID: <005401c3d6ed$f0d7bed0$b110a8c0@Tarun> From: "Tarun Ahuja" To: "Paul Koning" Cc: References: <0ac801c3d640$98c6eb10$b110a8c0@Tarun> <16382.50245.682335.168125@gargle.gargle.HOWL> Subject: Re: length of IV in ESP_NULL cipher Date: Fri, 9 Jan 2004 12:19:50 -0800 Organization: Cavium Networks Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 09 Jan 2004 20:17:00.0198 (UTC) FILETIME=[89ADFC60:01C3D6ED] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The padding is at the end of the packet (before authentication data) but the IV after the ESP header and I am definitely seeing 4 extra bytes after the ESP header. Actually FreeSWAN doesnot have inbuilt support for NULL cipher but there is an unofficial patch available for adding NULL cipher support. I believe, the patch developers are aware of the problem because, in the beta for the next release, the IV length has been changed to 0 but the version I am using, the IV length is 4 for NULL cipher. Looks like the developer used IV length to be equal to the number of padding bytes. As for Xedia talking to freeswan, I don't know, if you are talking about communication using NULL cipher because, because the problem seems related only to NULL cipher while other ciphers (3DES, AES at least) seem to work fine. Tarun ----- Original Message ----- From: "Paul Koning" To: Cc: Sent: Friday, January 09, 2004 7:09 AM Subject: Re: length of IV in ESP_NULL cipher > >>>>> "Scott" == Scott Fluhrer writes: > > Scott> On Thu, 8 Jan 2004, Tarun Ahuja wrote: > > >> Which essentially means the length of the IV should be 0 but > >> FreeSWAN uses a length of 4bytes IV (equal to blocksize) for NULL > >> cipher. > > Scott> Well, either FreeSWAN is broke (at least in this respect) or > Scott> you are mistaken about the operation of the FreeSWAN code. > > Agreed. I'm pretty sure I had our (Xedia) implementation talking to > FreeSWAN some years ago, so my suspicion is that the implementation is > actually correct. > > Are you looking at the packet length when you made this observation? > Remember that ESP_NULL DOES require padding (to multiples of four) > because that's the minimum requirement in ESP independent of cipher. > I think I have seen implementations (at least back in 1999 or so) that > got this wrong. > > paul > From owner-ipsec@lists.tislabs.com Fri Jan 9 15:22:31 2004 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 i09NMVib081767; Fri, 9 Jan 2004 15:22:31 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20457 Fri, 9 Jan 2004 17:41:05 -0500 (EST) To: Paul Hoffman / VPNC Cc: "Bepsy Paul" , Subject: Re: Open source IPsec References: From: Wes Hardaker Organization: Sparta Date: Fri, 09 Jan 2004 14:51:42 -0800 In-Reply-To: (Paul Hoffman's message of "Tue, 6 Jan 2004 18:28:33 -0800") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> On Tue, 6 Jan 2004 18:28:33 -0800, Paul Hoffman / VPNC said: >> I am looking for an open-source implementation of IKE & IPSEC which is >> available for download. Can anyone point out any useful link for downloading >> such a source code? your help will be highly appreciated. Paul> Here are three well-known packages that contain open-source IPsec and IKE: Paul> Paul> Paul> Additionally: net-policy.sourceforge.net which is a expanded version of the NIST reference release for linux (ported to Linux 2.4 from NIST's original 2.2 code). -- Wes Hardaker Sparta From owner-ipsec@lists.tislabs.com Sat Jan 10 04:46:05 2004 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 i0ACk4ib093773; Sat, 10 Jan 2004 04:46:05 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA24915 Sat, 10 Jan 2004 06:59:52 -0500 (EST) Message-Id: <200401101210.i0ACAkSj043848@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Mohan Parthasarathy" cc: ipsec@lists.tislabs.com Subject: Re: IKEv1 and multiple SAs ? In-reply-to: Your message of Fri, 09 Jan 2004 10:13:49 PST. <003201c3d6dc$54c5bc60$c91167c0@adithya> Date: Sat, 10 Jan 2004 13:10:46 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > => this is about rekeying of IPsec SAs (not what happens with IKE/ISAKMP SAs). > In IKEv1 the replaced IPsec SAs are explicitely deleted, in IKEv2 they are > flushed on timeout, i.e., implicitely deleted. => note that I was wrong: in IKEv2 one should delete the replaced SA too. The IKEv2 spec is not very clear, for instance it implicitely uses the terms delete and close for ending a SA. I believe that "delete" implies sending a delete payload. Thanks for the clarification. I was asking about the old IPsec SAs (not the replaced SAs) which IKEv1 implementations implicitly deleted. Does all IKEv1 implementations do so when a new IPsec SA is setup for the same traffic selectors ? => I believe you refer to: "the IKEv1 rekeying heuristic of deleting SAs on the basis of duplicate traffic selectors" (BTW where this is specified?). Racoon doesn't do this: in racoon only the initiator rekeys (something which doesn't work in IKEv2 because the lifetimes are no more negociated). This is not explained in section 2.8 but the rekey collision can be detected because a REKEY_SA notification is in the CREATE_CHILD_SA. As this message is copied in the list, I'd like this is explained in the next IKEv2 spec or rationale/tutorial. > Do these implementations delete the SA always in these cases? > > => IPsec SAs are always deleted when asked or when they have reached their > hard timeout. That's not what i read from section 2.8 of IKEv2 draft. => An IPsec SA has two lifetimes, a soft one (when it is reached, the SA enters the DYING state and a PF_KEY SADB_EXPIRE is sent to IKE) and a hard one (when it is reached, the SA enters the DEAD state. is no more usable and will be garbaged collected), this is managed by the kernel itself (in KAME the SADB is scaned every second). > => the INITIAL_CONTACT is very different: it is sent by a peer which > believes it has no SA, i.e., already existing SAs are from a previous > session and the peer has lost any state about it. > This means, only when i see a INITIAL_CONTACT, i can clean up all old IKE SAs and IPsec SAs. Correct ? => yes. BTW racoon only deletes IPsec SAs matching source and destination. Is that what the existing implementations do ? => IMHO yes when they don't implement some kind of dead peer detection. > => RFC 2407 4.6.3.3 for INITIAL_CONTACT > draft-ietf-ipsec-ikev2-11.txt pages 64-65 > (different because the IKEv2 spec is about previous IKE SAs) This is a bit confusing. Why would you keep the IPsec SAs around in this case ? => in IKEv2 when an IKE SA is closed all the IPsec SAs it manages are closed too. So the effect is the same but in a cleaner way (the fact in IKEv2 the IKE SA is used to manage the IPsec SAs (in place of to be used only to establish and delete some of them) is one of its major improvements). The sender by sending INITIAL_CONTACT says that this is the only IKE SA. This implies that he has no previous IKE SAs or IPsec SAs which means the receiver can delete all of them. Why is it specific to IKE SAs ? Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Sun Jan 11 12:48:34 2004 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 i0BKmYib068203; Sun, 11 Jan 2004 12:48:34 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04304 Sun, 11 Jan 2004 14:58:27 -0500 (EST) Message-Id: <200401092127.QAA16833@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ikev2-iana-01.txt Date: Fri, 09 Jan 2004 16:27:49 -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 : Initial IANA registry contents Author(s) : M. Richardson Filename : draft-ietf-ipsec-ikev2-iana-01.txt Pages : 23 Date : 2004-1-9 This is a non-standards track document that tells IANA how to populate the initial IKEv2 registries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-iana-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ikev2-iana-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-iana-01.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: <2004-1-9164708.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-iana-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-iana-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-9164708.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Jan 12 09:29:28 2004 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 i0CHTRib096315; Mon, 12 Jan 2004 09:29:27 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10919 Mon, 12 Jan 2004 11:37:19 -0500 (EST) Message-ID: <4002CFD0.4060008@nortelnetworks.com> Date: Mon, 12 Jan 2004 11:48:16 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Why is the length of transform ID 2 octets in IKEv2? References: <200401072101.QAA01462@ietf.org> In-Reply-To: <200401072101.QAA01462@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, The length of the transform ID is 2 octets in IKEv2 (was 2 octets in 00, changed to 1 octet in 01, and back to 2 octets in 08 and stayed that way) whereas it is 1 octet in 2408. I am curious about the reasoning behind the change(s). Do we really need 2 octets for this field? regards, Lakshminath Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the IP Security Protocol Working Group of the IETF. > > Title : Internet Key Exchange (IKEv2) Protocol > Author(s) : C. Kaufman > Filename : draft-ietf-ipsec-ikev2-12.txt > Pages : 102 > Date : 2004-1-7 > >This document describes version 2 of the Internet Key Exchange (IKE) >protocol. IKE is a component of IPsec used for performing mutual >authentication and establishing and maintaining security >associations. >This version of the IKE specification combines the contents of what >were previously separate documents, including ISAKMP (RFC 2408), IKE >(RFC 2409), the Internet DOI (RFC 2407), NAT Traversal, Legacy >authentication, and remote address acquisition. >Version 2 of IKE does not interoperate with version 1, but it has >enough of the header format in common that both versions can >unambiguously run over the same UDP port. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-12.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-ipsec-ikev2-12.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-ipsec-ikev2-12.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. > > > From owner-ipsec@lists.tislabs.com Mon Jan 12 10:32:50 2004 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 i0CIWnib098673; Mon, 12 Jan 2004 10:32:49 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA11348 Mon, 12 Jan 2004 12:43:23 -0500 (EST) Message-ID: <003a01c3d935$1e433180$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Francis Dupont" Cc: References: <200401101210.i0ACAkSj043848@givry.rennes.enst-bretagne.fr> Subject: Re: IKEv1 and multiple SAs ? Date: Mon, 12 Jan 2004 09:54:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > In your previous mail you wrote: > > > => this is about rekeying of IPsec SAs (not what happens with IKE/ISAKMP > SAs). > > In IKEv1 the replaced IPsec SAs are explicitely deleted, in IKEv2 they are > > flushed on timeout, i.e., implicitely deleted. > > => note that I was wrong: in IKEv2 one should delete the replaced SA too. > The IKEv2 spec is not very clear, for instance it implicitely uses the > terms delete and close for ending a SA. I believe that "delete" implies > sending a delete payload. > > Thanks for the clarification. I was asking about the old IPsec SAs (not the > replaced SAs) > which IKEv1 implementations implicitly deleted. Does all IKEv1 > implementations do so when > a new IPsec SA is setup for the same traffic selectors ? > > => I believe you refer to: "the IKEv1 rekeying heuristic of deleting > SAs on the basis of duplicate traffic selectors" (BTW where this is > specified?). Racoon doesn't do this: in racoon only the initiator > rekeys (something which doesn't work in IKEv2 because the lifetimes > are no more negociated). > This is not explained in section 2.8 but the rekey collision can be > detected because a REKEY_SA notification is in the CREATE_CHILD_SA. > As this message is copied in the list, I'd like this is explained > in the next IKEv2 spec or rationale/tutorial. > Right. If REKEY_SA is explained in section 2.8 which explains about rekeying, it would really clarify this case. Only if REKEY_SA is included, the old IPsec SAs SHOULD be deleted. Otherwise, the old IPsec SA should be left around till it expires. -mohan From owner-ipsec@lists.tislabs.com Mon Jan 12 16:49:19 2004 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 i0D0nIib018267; Mon, 12 Jan 2004 16:49:18 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA13583 Mon, 12 Jan 2004 19:03:22 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16387.14413.826253.631634@fireball.acr.fi> Date: Tue, 13 Jan 2004 02:14:05 +0200 From: Tero Kivinen To: "Dondeti, Lakshminath" Cc: ipsec@lists.tislabs.com Subject: Why is the length of transform ID 2 octets in IKEv2? In-Reply-To: <4002CFD0.4060008@nortelnetworks.com> References: <200401072101.QAA01462@ietf.org> <4002CFD0.4060008@nortelnetworks.com> X-Mailer: VM 7.17 under Emacs 21.3.1 Organization: Helsinki University of Technology X-Edit-Time: 13 min X-Total-Time: 15 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dondeti, Lakshminath writes: > The length of the transform ID is 2 octets in IKEv2 (was 2 octets in > 00, changed to 1 octet in 01, and back to 2 octets in 08 and stayed that > way) whereas it is 1 octet in 2408. I am curious about the reasoning > behind the change(s). Do we really need 2 octets for this field? The rfc2408 transform id only contained parts of the things we currently store in the transform id (i.e crypto algorithm). Some of the data stored now in the transform id used to be in the transform attributes, where they were 16 or 32 bit values (for example the Diffie-Hellman group, authentication algorithm etc). We did have space there, and there is also some space needed for private use values. I think there might be more semi-permanent and semi-documented private use values for the Diffie-Hellman groups, as the current document says that the support for defining private Diffie-Hellman groups is SHOULD, and there are organizations requiring them. As the group parameters are no longer exchanged inside the IKE, the requirements for the internal documentation for the private groups used is much higher, and organizations propably tries to keep the numbering separate (i.e people do not take the first private use number, but instead take random value and start using groups from that point). On the other hand to be able to use the private use numbers, the management interface should also allow adding vendor ID payloads to identify the private use number space used. I.e the organization defining that number 12314 is their first private group, should also be able to add vendor ID specified by them to identify that group (i.e the managment facility which allows specification of Diffie-Hellman parameters should also include the vendor ID associated to the group. -- kivinen@iki.fi From owner-ipsec@lists.tislabs.com Tue Jan 13 10:21:33 2004 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 i0DILXib056460; Tue, 13 Jan 2004 10:21:33 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19278 Tue, 13 Jan 2004 12:32:30 -0500 (EST) Message-Id: <5.2.0.9.2.20040113124242.03142610@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 13 Jan 2004 12:43:29 -0500 To: "Theodore Ts'o" , byfraser@cisco.com From: Russ Housley Subject: Re: Charlie has submitted a new version of draft-ietf-ipsec-ikev2 Cc: ipsec@lists.tislabs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have no problem with two documents, but it needs to be done very soon. It is best for the IESG to ballot the two documents together. Russ At 12:38 PM 1/13/2004 -0500, Theodore Ts'o wrote: >[ This note should have been sent last week, but for some reason it > apparently never made it out of my sent mail queue. My > apologies... -- Ted ] > >Hi Russ, > >Charlie has submitted a new version of the ikev2-bis document: > > draft-ietf-ipsec-ikev2-12.txt > >This draft contains fixes to various nits and errors that were raised >after the wg last call (including the ones which you had found during >your initial review of the ikev2-11 I-D after we had forwarded it to >you). We believe that none of the changes are controversial, and so >the document should be ready for IETF-wide last call. > >One change that in the document dependency structure which is present >in the -12 document is that the IANA considerations section has been >moved to a separate document which Michael Richardson has been >developing. > >Do you have an opinion about whether the IANA considerations should be >kept in a separate document, which would make it easier for the IANA >to review (and which truly isn't really necessary for implementors to >see), or whether it should be combined into one document (which is >already 102 pages and over 250k long)? It seemed to us that it might >make more sense for the IANA considerations to be in a separate >informational RFC, but there are certainly arguments to do things >either way. Do you believe the IESG and the IANA would have a strong >preference to do things one way or the other? > >Many thanks!! > > - Ted From owner-ipsec@lists.tislabs.com Tue Jan 13 10:24:27 2004 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 i0DIORib056689; Tue, 13 Jan 2004 10:24:27 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19285 Tue, 13 Jan 2004 12:33:34 -0500 (EST) To: Russ Housley , byfraser@cisco.com cc: ipsec@lists.tislabs.com Subject: Charlie has submitted a new version of draft-ietf-ipsec-ikev2 From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Tue, 13 Jan 2004 12:38:32 -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 [ This note should have been sent last week, but for some reason it apparently never made it out of my sent mail queue. My apologies... -- Ted ] Hi Russ, Charlie has submitted a new version of the ikev2-bis document: draft-ietf-ipsec-ikev2-12.txt This draft contains fixes to various nits and errors that were raised after the wg last call (including the ones which you had found during your initial review of the ikev2-11 I-D after we had forwarded it to you). We believe that none of the changes are controversial, and so the document should be ready for IETF-wide last call. One change that in the document dependency structure which is present in the -12 document is that the IANA considerations section has been moved to a separate document which Michael Richardson has been developing. Do you have an opinion about whether the IANA considerations should be kept in a separate document, which would make it easier for the IANA to review (and which truly isn't really necessary for implementors to see), or whether it should be combined into one document (which is already 102 pages and over 250k long)? It seemed to us that it might make more sense for the IANA considerations to be in a separate informational RFC, but there are certainly arguments to do things either way. Do you believe the IESG and the IANA would have a strong preference to do things one way or the other? Many thanks!! - Ted From owner-ipsec@lists.tislabs.com Tue Jan 13 10:52:18 2004 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 i0DIqHib058001; Tue, 13 Jan 2004 10:52:17 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19520 Tue, 13 Jan 2004 13:06:22 -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: Tue, 13 Jan 2004 10:16:39 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: New version of Don's ESP and AH algorithms document Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. The Internet Draft processor is being very slow again, so I have posted a temporary version of the ESP and AH algorithms document at . That file will disappear when the draft is posted in the official Internet Draft repository. On a somewhat-related note, VPNC keeps a categorized list of Internet Draft and RFCs relating to VPNs at . The Internet Drafts in that list are automatically updated when higher-numbered drafts appear. This list is not updated for the temporary drafts such as the one above are posted: it tracks the official repository. If you have suggestions for the list, please let me know. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jan 13 11:25:50 2004 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 i0DJPnib060470; Tue, 13 Jan 2004 11:25:50 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19771 Tue, 13 Jan 2004 13:40:15 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 13 Jan 2004 10:51:11 -0800 To: "Theodore Ts'o" , Russ Housley , byfraser@cisco.com From: Paul Hoffman / VPNC Subject: Re: Charlie has submitted a new version of draft-ietf-ipsec-ikev2 Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:38 PM -0500 1/13/04, Theodore Ts'o wrote: >One change that in the document dependency structure which is present >in the -12 document is that the IANA considerations section has been >moved to a separate document which Michael Richardson has been >developing. > >Do you have an opinion about whether the IANA considerations should be >kept in a separate document, which would make it easier for the IANA >to review (and which truly isn't really necessary for implementors to >see), or whether it should be combined into one document (which is >already 102 pages and over 250k long)? It seemed to us that it might >make more sense for the IANA considerations to be in a separate >informational RFC, but there are certainly arguments to do things >either way. Why do you want the IANA Considerations document to be an RFC at all? It is meant as *one-time* advice to IANA about what to do when the IKEv2 document becomes a Proposed Standard. Michael's document should remain an Internet Draft until IANA needs it, and it should then disappear after IANA uses it. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jan 13 12:03:26 2004 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 i0DK3Pib062135; Tue, 13 Jan 2004 12:03:26 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20174 Tue, 13 Jan 2004 14:21:02 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16388.18353.362889.658207@fireball.acr.fi> Date: Tue, 13 Jan 2004 21:32:01 +0200 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: charliek@microsoft.com Subject: draft-ietf-ipsec-ikev2-12.txt reference section X-Mailer: VM 7.17 under Emacs 21.3.1 Organization: Helsinki University of Technology X-Edit-Time: 5 min X-Total-Time: 4 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think the UDP encapsulation draft (draft-ietf-ipsec-udp-encaps-07.txt) reference should be normative not informative. The implementators need to read and implement the encapsulation specified there to implement the NAT traversal. On the other hand it should have informative reference to the draft-ietf-ipsec-nat-reqts-06.txt which describes the NAT traversal requirements and background (and perhaps a reference to there in the beginning of the section 2.23). -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Tue Jan 13 12:40:07 2004 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 i0DKe6ib063485; Tue, 13 Jan 2004 12:40:06 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20487 Tue, 13 Jan 2004 14:58:38 -0500 (EST) Date: Tue, 13 Jan 2004 22:10:50 +0200 (IST) From: Hugo Krawczyk To: "Theodore Ts'o" cc: Russ Housley , , Charlie Kaufman , IPsec WG Subject: Keing the prf In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There is one issue that was subject of discussion in the last weeks and I believe requires a better resolution. I refer to the problem that ikev2 (including -12) defines two uses of the prf function (in sections 2.15 and 2.16) where the prf is keyed with SK_a. This is problematic since SK_a is defined as a key to the "integrity algorithm" which may be different than the prf. Indeed the integrity algorithm and prf have different transform types (#3 and #2) respectively, and then are negotiated independetly (in particular they may use different algorihms). Why is this a problem? First, because the two transforms may require keys of different lengths, in particular SK_a may be too short to key the prf. Second, it is a wrong cryptographic practice to use the same key with two different algorithms. This may or may not translate into actual attacks, but it certainly spoils the otherwise sound design of the protocol. It will also invite "attacks" from future formal analysts (beyond the operational issues referred to in the first item). I believe that the problem is best solved by deriving an additional pair of keys from SKEYSEED (call them SK_pi and SK_pr) for keying the prf in the above two cases. It is certainly easy to specify and to implement (and easier than to justify why this wasn't done). Specifically add the pair SK_pi, SK_pr to the key derivation formula in 2.14. Change prf(SK_ar,IDr') to prf(SK_pr,IDr') and prf(SK_ai,IDr') to prf(SK_pi,IDr') in section 2.15. Change "SK_ai and SK_ar" in the next to last paragraph of section 2.16 with "SK_pi and SK_pr" I suggest that this be solved before the official last call (otherwise you can see this as a comment provided in the last call phase). Hugo From owner-ipsec@lists.tislabs.com Tue Jan 13 13:23:18 2004 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 i0DLNHib065669; Tue, 13 Jan 2004 13:23:17 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20944 Tue, 13 Jan 2004 15:42:00 -0500 (EST) To: ipsec@lists.tislabs.com Subject: Re: Charlie has submitted a new version of draft-ietf-ipsec-ikev2 In-reply-to: Your message of "Tue, 13 Jan 2004 10:51:11 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 13 Jan 2004 15:42:58 -0500 Message-ID: <18186.1074026578@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "VPNC" == VPNC writes: VPNC> Why do you want the IANA Considerations document to be an RFC at VPNC> all? It is meant as *one-time* advice to IANA about what to do when VPNC> the IKEv2 document becomes a Proposed Standard. Michael's document VPNC> should remain an Internet Draft until IANA needs it, and it should VPNC> then disappear after IANA uses it. And it was in this spirit that I wrote the document. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Tue Jan 13 15:46:10 2004 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 i0DNk9ib071478; Tue, 13 Jan 2004 15:46:09 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA22098 Tue, 13 Jan 2004 18:05:04 -0500 (EST) Message-Id: <5.2.0.9.0.20040113144759.045cc418@10.1.5.10> X-Sender: vamsi@10.1.5.10 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 13 Jan 2004 15:13:59 -0800 To: ipsec@lists.tislabs.com From: vamsi Subject: Initial Contact Message processing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, We found one problem during inter operability testing and I thought I will inform to the list for feedback. It seems that some implementations, while processing IC message, delete all IPSEC and IKE SAs that correspond to source IP address of the IC message. This works well, in most of the scenarios, but fails to work when there are more than one Security Gateway or Clients behind a NAT gateway. For instance, take this example: Security Client 1 ----------NAT Gateway-------Internet--------SG-----LAN Security Client 2 At one time, both clients have tunnels established with SG (acting as remote access server and only Clients initiate phase1 exchange) and SG will see both the tunnels from NAT Gateway IP address. If Client 1 gets restarted, it sends IC message to the SG. SG, upon receipt, deletes tunnels established by Client 1 and also it deletes the tunnels, that are created by Client 2. DOI (RFC2407) states that, upon receipt of IC message, the implementations might delete tunnels associated with the sending system. It is observed that, identification of 'sending system' is being done based on source IP address of the IC message in some implementations. I feel that, it should be based on 'Phase1 ID' (FQDN, USER FQDN, USER DN etc..) and/or with source IP address. Some clarification on IC message processing in DOI document, might be helpful. Thanks Vamsi From owner-ipsec@lists.tislabs.com Tue Jan 13 20:20:06 2004 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 i0E4K5ib084418; Tue, 13 Jan 2004 20:20:05 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA23907 Tue, 13 Jan 2004 22:38:08 -0500 (EST) Date: Tue, 13 Jan 2004 22:49:07 -0500 From: Thor Lancelot Simon To: ipsec@lists.tislabs.com Subject: Re: Initial Contact Message processing Message-ID: <20040114034907.GA29766@panix.com> Reply-To: tls@rek.tjls.com References: <5.2.0.9.0.20040113144759.045cc418@10.1.5.10> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.0.20040113144759.045cc418@10.1.5.10> User-Agent: Mutt/1.4.1i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Jan 13, 2004 at 03:13:59PM -0800, vamsi wrote: > > Hi, > We found one problem during inter operability testing and I thought > I will inform to the list for feedback. > > It seems that some implementations, while processing IC message, > delete all IPSEC and IKE SAs that correspond to source IP address of > the IC message. > > This works well, in most of the scenarios, but fails to work when there > are more than one Security Gateway or Clients behind a NAT gateway. > For instance, take this example: This is a pretty dubious way to use IKE. That aside for the moment, it seems to me to be only one of a number of reasons why implementations should track the _port_ they receive the initial message of a conversation from, not just the source IP address. From owner-ipsec@lists.tislabs.com Tue Jan 13 20:20:53 2004 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 i0E4Kqib084447; Tue, 13 Jan 2004 20:20:52 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA23892 Tue, 13 Jan 2004 22:34:36 -0500 (EST) Message-Id: <5.1.0.14.0.20040114092228.00a98f58@172.16.1.10> X-Sender: suram@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 14 Jan 2004 09:25:27 +0530 To: ipsec@lists.tislabs.com From: Suram Chandra Sekhar Subject: DPD Inter operability testing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, Are there any open/free implementations OR sites of VPN implementation where I can inter-operate my DPD implementation. I would be grateful if I can get some information on Vendors that support DPD. Awaiting for your valuable response.. Regards Suram From owner-ipsec@lists.tislabs.com Wed Jan 14 02:20:19 2004 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 i0EAKIib074529; Wed, 14 Jan 2004 02:20:18 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA26253 Wed, 14 Jan 2004 04:40:33 -0500 (EST) Date: Wed, 14 Jan 2004 10:51:34 +0100 From: =?iso-8859-2?Q?Pawe=B3?= Krawczyk To: Suram Chandra Sekhar Cc: ipsec@lists.tislabs.com Subject: Re: DPD Inter operability testing Message-ID: <20040114095134.GA14700@aba.krakow.pl> References: <5.1.0.14.0.20040114092228.00a98f58@172.16.1.10> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5.1.0.14.0.20040114092228.00a98f58@172.16.1.10> User-Agent: Mutt/1.3.28i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Jan 14, 2004 at 09:25:27AM +0530, Suram Chandra Sekhar wrote: > Are there any open/free implementations OR sites of VPN implementation > where I can inter-operate my DPD implementation. > I would be grateful if I can get some information on Vendors that support > DPD. There's DPD implementation in http://www.openswan.org/ It has been tested with Cisco several months ago. -- Pawe³ Krawczyk, Kraków, Poland http://echelon.pl/kravietz/ ABA Kraków: http://www.aba.krakow.pl/ horses: http://kabardians.com/ crypto: http://ipsec.pl/ From owner-ipsec@lists.tislabs.com Wed Jan 14 03:38:55 2004 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 i0EBcsib079488; Wed, 14 Jan 2004 03:38:55 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA26641 Wed, 14 Jan 2004 05:59:15 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16389.9111.10031.817363@fireball.acr.fi> Date: Wed, 14 Jan 2004 13:10:15 +0200 From: Tero Kivinen To: tls@rek.tjls.com Cc: ipsec@lists.tislabs.com Subject: Re: Initial Contact Message processing In-Reply-To: <20040114034907.GA29766@panix.com> References: <5.2.0.9.0.20040113144759.045cc418@10.1.5.10> <20040114034907.GA29766@panix.com> X-Mailer: VM 7.17 under Emacs 21.3.1 Organization: Helsinki University of Technology X-Edit-Time: 5 min X-Total-Time: 4 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thor Lancelot Simon writes: > On Tue, Jan 13, 2004 at 03:13:59PM -0800, vamsi wrote: > > > > Hi, > > We found one problem during inter operability testing and I thought > > I will inform to the list for feedback. > > > > It seems that some implementations, while processing IC message, > > delete all IPSEC and IKE SAs that correspond to source IP address of > > the IC message. > > > > This works well, in most of the scenarios, but fails to work when there > > are more than one Security Gateway or Clients behind a NAT gateway. > > For instance, take this example: If you are using IPsec through NAT you should be using NAT Traversal as defined in the draft-ietf-ipsec-nat-t-ike-07.txt document. It states that: ---------------------------------------------------------------------- 6. Initial contact notifications The source IP and port address of the INITIAL-CONTACT notification for the host behind NAT are not meaningful, so the IP and port numbers MUST NOT be used for the determine which IKE/IPsec SAs to remove. The ID payload sent from the other SHOULD be used instead. I.e when INITIAL-CONTACT notification is received from the other end, the receiving end SHOULD remove all the SAs associated with the same ID payload. ---------------------------------------------------------------------- > This is a pretty dubious way to use IKE. That aside for the moment, > it seems to me to be only one of a number of reasons why implementations > should track the _port_ they receive the initial message of a conversation > from, not just the source IP address. This does not work. You MUST use identities for tracking the SAs from the same identity. If the host behind NAT is rebooted, there is possibility that the NAT will allocate new IP and port for the host when it connects again. Now the SGW will see connection coming with new IP and new port, and the INITIAL-CONTACT will not clear the old state away at all, meaning that it can still try to send the traffic to old SAs (== black hole). -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Wed Jan 14 08:55:48 2004 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 i0EGtmib016355; Wed, 14 Jan 2004 08:55:48 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28575 Wed, 14 Jan 2004 11:15:20 -0500 (EST) Message-Id: <200401132051.PAA12287@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-esp-ah-algorithms-01.txt Date: Tue, 13 Jan 2004 15:51:46 -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 : Cryptographic Algorithm Implementation Requirements For ESP And AH Author(s) : D. Eastlake 3rd Filename : draft-ietf-ipsec-esp-ah-algorithms-01.txt Pages : 10 Date : 2004-1-13 The IPSEC series of protocols makes use of various cryptographic algorithms in order to provide security services. The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPSEC Security Association (SA). To ensure interoperability between disparate implementations it is necessary to specify a set of mandatory to implement algorithms to ensure at least one algorithm that all implementations will have available. This document defines the current set of mandatory to implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-ah-algorithms-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-ah-algorithms-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-esp-ah-algorithms-01.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: <2004-1-13160040.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-ah-algorithms-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-ah-algorithms-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-13160040.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Jan 14 09:29:37 2004 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 i0EHTbib017917; Wed, 14 Jan 2004 09:29:37 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28763 Wed, 14 Jan 2004 11:51:23 -0500 (EST) Subject: Re: Initial Contact Message processing To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: David Wierbowski Date: Wed, 14 Jan 2004 12:02:21 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 6.0.2CF2 HFB2 IGS HF12C|January 9, 2004) at 01/14/2004 12:02:22 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> This is a pretty dubious way to use IKE. That aside for the moment, >> it seems to me to be only one of a number of reasons why implementations >> should track the _port_ they receive the initial message of a conversation >> from, not just the source IP address. > > This does not work. You MUST use identities for tracking the SAs from > the same identity. If the host behind NAT is rebooted, there is > possibility that the NAT will allocate new IP and port for the host > when it connects again. Now the SGW will see connection coming with > new IP and new port, and the INITIAL-CONTACT will not clear the old > state away at all, meaning that it can still try to send the traffic > to old SAs (== black hole). Are you saying that an identity may use IPSec from one device only? It seems to me that I may want to establish a phase 1 SA with you from two different work stations at the same time. Are you saying that I would need 2 phase 1 IDs to do that? Is it a generally accepted limitation of IPSec that identities are tied to a particular device? This would have to be true in order to process an INITIAL-CONTACT notification based on IDs only. From owner-ipsec@lists.tislabs.com Wed Jan 14 11:38:15 2004 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 i0EJcEib022862; Wed, 14 Jan 2004 11:38:14 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29532 Wed, 14 Jan 2004 13:57:43 -0500 (EST) Message-Id: <5.2.0.9.0.20040114110336.045bdc68@10.1.5.10> X-Sender: vamsi@10.1.5.10 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 14 Jan 2004 11:06:26 -0800 To: Tero Kivinen , tls@rek.tjls.com From: vamsi Subject: Re: Initial Contact Message processing Cc: ipsec@lists.tislabs.com In-Reply-To: <16389.9111.10031.817363@fireball.acr.fi> References: <20040114034907.GA29766@panix.com> <5.2.0.9.0.20040113144759.045cc418@10.1.5.10> <20040114034907.GA29766@panix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Thank you for pointing out the text and draft number. This text clearly indicates the solution, that is inter-operable and I am comfortable with this text. Thanks again Vamsi CTO office Intoto Inc. www.intoto.com At 01:10 PM 1/14/2004 +0200, Tero Kivinen wrote: >Thor Lancelot Simon writes: > > On Tue, Jan 13, 2004 at 03:13:59PM -0800, vamsi wrote: > > > > > > Hi, > > > We found one problem during inter operability testing and I thought > > > I will inform to the list for feedback. > > > > > > It seems that some implementations, while processing IC message, > > > delete all IPSEC and IKE SAs that correspond to source IP address of > > > the IC message. > > > > > > This works well, in most of the scenarios, but fails to work when > there > > > are more than one Security Gateway or Clients behind a NAT gateway. > > > For instance, take this example: > >If you are using IPsec through NAT you should be using NAT Traversal >as defined in the draft-ietf-ipsec-nat-t-ike-07.txt document. It >states that: >---------------------------------------------------------------------- >6. Initial contact notifications > >The source IP and port address of the INITIAL-CONTACT notification for >the host behind NAT are not meaningful, so the IP and port numbers >MUST NOT be used for the determine which IKE/IPsec SAs to remove. The >ID payload sent from the other SHOULD be used instead. I.e when >INITIAL-CONTACT notification is received from the other end, the >receiving end SHOULD remove all the SAs associated with the same ID >payload. >---------------------------------------------------------------------- > > > This is a pretty dubious way to use IKE. That aside for the moment, > > it seems to me to be only one of a number of reasons why implementations > > should track the _port_ they receive the initial message of a conversation > > from, not just the source IP address. > >This does not work. You MUST use identities for tracking the SAs from >the same identity. If the host behind NAT is rebooted, there is >possibility that the NAT will allocate new IP and port for the host >when it connects again. Now the SGW will see connection coming with >new IP and new port, and the INITIAL-CONTACT will not clear the old >state away at all, meaning that it can still try to send the traffic >to old SAs (== black hole). >-- >kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Wed Jan 14 13:44:37 2004 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 i0ELiaib028088; Wed, 14 Jan 2004 13:44:36 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00195 Wed, 14 Jan 2004 16:04:50 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 14 Jan 2004 16:12:26 -0500 To: David Wierbowski From: Stephen Kent Subject: Re: Initial Contact Message processing 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:02 -0500 1/14/04, David Wierbowski wrote: > >> This is a pretty dubious way to use IKE. That aside for the moment, >>> it seems to me to be only one of a number of reasons why implementations >>> should track the _port_ they receive the initial message of a >conversation >>> from, not just the source IP address. >> >> This does not work. You MUST use identities for tracking the SAs from >> the same identity. If the host behind NAT is rebooted, there is >> possibility that the NAT will allocate new IP and port for the host >> when it connects again. Now the SGW will see connection coming with >> new IP and new port, and the INITIAL-CONTACT will not clear the old >> state away at all, meaning that it can still try to send the traffic >> to old SAs (== black hole). > >Are you saying that an identity may use IPSec from one device only? >It seems to me that I may want to establish a phase 1 SA with you from >two different work stations at the same time. Are you saying that I >would need 2 phase 1 IDs to do that? Is it a generally accepted limitation >of IPSec that identities are tied to a particular device? This would have >to be true in order to process an INITIAL-CONTACT notification based on IDs >only. In general one would not expect the same entity to be present at multiple addresses at the same time, although I agree that there are circumstances where this might legitimately happen. However, the observation about the inadequacy of relying on addresses and ports to identify a peer in all circumstances is still true. So, if one wants to allow the same identified entity to connect to the same destination from multiple sources simultaneously, there needs to be an instance-specific form of identification that IKE can use to distinguish among the multiple instances of the same entity, for housekeeping purposes. Steve From owner-ipsec@lists.tislabs.com Wed Jan 14 19:51:52 2004 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 i0F3ppib044752; Wed, 14 Jan 2004 19:51:51 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA02203 Wed, 14 Jan 2004 22:10:18 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16390.1836.832224.368241@fireball.acr.fi> Date: Thu, 15 Jan 2004 05:21:16 +0200 From: Tero Kivinen To: David Wierbowski Cc: ipsec@lists.tislabs.com Subject: Re: Initial Contact Message processing In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 Organization: Helsinki University of Technology X-Edit-Time: 7 min X-Total-Time: 7 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David Wierbowski writes: > Are you saying that an identity may use IPSec from one device only? USer can use IPsec from multiple devices, but if you want to have working solution going through NATs each identity should only be tied to one device. This normally is the case, your private key is only stored in exactly one machine, and it is tied to one certificate having one identity. If you have another device you use to connect to the same VPN you should have separate private key and identity for that (for example FQDN). In some cases you might want to use only one identity and you want to clear out old identities, for example in cases where you use securID card or similar and you have forgotten to log out from the office workstation, and you then log in with same card from your home. All of this depends on the configuration and policy defined in the VPN gateway. > It seems to me that I may want to establish a phase 1 SA with you from > two different work stations at the same time. There is nothing preventing you to configure your systems to allow that. > Are you saying that I would need 2 phase 1 IDs to do that? Yes, if you want to use NAT traversal or IKEv2 and you want to send INITIAL_CONTACT notifications. > Is it a generally accepted limitation of IPSec that identities are > tied to a particular device? Normally identities are tied either to the device or to the user. Everything again depends on the policy. > This would have to be true in order to process an INITIAL-CONTACT > notification based on IDs only. In NAT-T draft and also in the IKEv2 the INITIAL-CONTACT is only processed based on the authenticated identities only: from the draft-ietf-ipsec-ikev2-12.txt: ---------------------------------------------------------------------- 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). -- kivinen@iki.fi From owner-ipsec@lists.tislabs.com Wed Jan 14 22:36:36 2004 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 i0F6aZib062601; Wed, 14 Jan 2004 22:36:36 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA03200 Thu, 15 Jan 2004 00:57:32 -0500 (EST) Date: Thu, 15 Jan 2004 01:08:35 -0500 From: Thor Lancelot Simon To: ipsec@lists.tislabs.com Subject: Re: Initial Contact Message processing Message-ID: <20040115060835.GA26600@panix.com> Reply-To: tls@rek.tjls.com References: <16390.1836.832224.368241@fireball.acr.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16390.1836.832224.368241@fireball.acr.fi> User-Agent: Mutt/1.4.1i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Jan 15, 2004 at 05:21:16AM +0200, Tero Kivinen wrote: > David Wierbowski writes: > > Are you saying that an identity may use IPSec from one device only? > > USer can use IPsec from multiple devices, but if you want to have > working solution going through NATs each identity should only be tied > to one device. This normally is the case, your private key is only > stored in exactly one machine, and it is tied to one certificate > having one identity. If you have another device you use to connect to > the same VPN you should have separate private key and identity for > that (for example FQDN). It seems to me that implementations could easily allow the use of the identity,address,port tuple instead of just "identity" or "address,port" (the latter being a bug). This seems more flexible and, to be honest, I don't see any downside to it at all. Do you? Requiring a different identity for each device used by a given user is likely to cause severe problems with X.500 identies, considering how certificates are usually allocated to users. I worked on one implementation (IKEv1 without Initial Contact, FWIW) where this would have been an utter disaster for some of our largest customers. Thor From owner-ipsec@lists.tislabs.com Thu Jan 15 05:19:09 2004 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 i0FDJ8ib043608; Thu, 15 Jan 2004 05:19:09 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA05314 Thu, 15 Jan 2004 07:39:10 -0500 (EST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16390.35968.776961.795764@fireball.acr.fi> Date: Thu, 15 Jan 2004 14:50:08 +0200 From: Tero Kivinen To: tls@rek.tjls.com Cc: ipsec@lists.tislabs.com Subject: Re: Initial Contact Message processing In-Reply-To: <20040115060835.GA26600@panix.com> References: <16390.1836.832224.368241@fireball.acr.fi> <20040115060835.GA26600@panix.com> X-Mailer: VM 7.17 under Emacs 21.3.1 Organization: Helsinki University of Technology X-Edit-Time: 7 min X-Total-Time: 6 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thor Lancelot Simon writes: > On Thu, Jan 15, 2004 at 05:21:16AM +0200, Tero Kivinen wrote: > > David Wierbowski writes: > > > Are you saying that an identity may use IPSec from one device only? > > > > USer can use IPsec from multiple devices, but if you want to have > > working solution going through NATs each identity should only be tied > > to one device. This normally is the case, your private key is only > > stored in exactly one machine, and it is tied to one certificate > > having one identity. If you have another device you use to connect to > > the same VPN you should have separate private key and identity for > > that (for example FQDN). > > It seems to me that implementations could easily allow the use of > the identity,address,port tuple instead of just "identity" or > "address,port" (the latter being a bug). This seems more flexible > and, to be honest, I don't see any downside to it at all. Do you? Yes. In that case it does not work if the other end is behind NAT (i.e the host is rebooted, and it gets new address or port after reboot, so the state is not cleared up). It also does not clean up state if the user simply closes machine and then moves another place and restarts it there (new IP). The state is left running in those cases. Anyways this is again somewhat policy matter, and depends on the configuration and setup. > Requiring a different identity for each device used by a given user > is likely to cause severe problems with X.500 identies, considering > how certificates are usually allocated to users. I do not see any problems there. It is actually much harder to share the same private key in multiple machines than to create separate private key and certificate for each device (implementations allowing pkcs10 based certficiate enrollment or similar, might not allow any standard way to get private key out to another machine). > I worked on one implementation (IKEv1 without Initial Contact, FWIW) > where this would have been an utter disaster for some of our largest > customers. I do not see any problem for your implementation then to be configured to use only IP/port or IP/port/ID if you do not have NATs or mobile users there. The use of INITIAL_CONTACT in the IKEv2 is much smaller anyways, as the dead peer detection will detect the disappearing remote hosts, so INITIAL_CONTACT only causes that happen little bit sooner. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Thu Jan 15 07:37:45 2004 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 i0FFbiib052001; Thu, 15 Jan 2004 07:37:45 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06336 Thu, 15 Jan 2004 10:02:05 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16390.44519.75000.931769@gargle.gargle.HOWL> Date: Thu, 15 Jan 2004 10:12:39 -0500 From: Paul Koning To: tls@rek.tjls.com Cc: ipsec@lists.tislabs.com Subject: Re: Initial Contact Message processing References: <16390.1836.832224.368241@fireball.acr.fi> <20040115060835.GA26600@panix.com> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Thor" == Thor Lancelot Simon writes: Thor> On Thu, Jan 15, 2004 at 05:21:16AM +0200, Tero Kivinen wrote: >> David Wierbowski writes: > Are you saying that an identity may use >> IPSec from one device only? >> >> USer can use IPsec from multiple devices, but if you want to have >> working solution going through NATs each identity should only be >> tied to one device. This normally is the case, your private key is >> only stored in exactly one machine, and it is tied to one >> certificate having one identity. If you have another device you >> use to connect to the same VPN you should have separate private >> key and identity for that (for example FQDN). Thor> It seems to me that implementations could easily allow the use Thor> of the identity,address,port tuple instead of just "identity" Thor> or "address,port" (the latter being a bug). This seems more Thor> flexible and, to be honest, I don't see any downside to it at Thor> all. Do you? Thor> Requiring a different identity for each device used by a given Thor> user is likely to cause severe problems with X.500 identies, Thor> considering how certificates are usually allocated to users. I Thor> worked on one implementation (IKEv1 without Initial Contact, Thor> FWIW) where this would have been an utter disaster for some of Thor> our largest customers. Agreed. Since a "device" can have multiple NICs, it can have multiple addresses. So if "address" is used as part of the tuple that distinguishes devices, how are multi-NIC devices handled? paul From owner-ipsec@lists.tislabs.com Thu Jan 15 08:25:20 2004 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 i0FGPKib055546; Thu, 15 Jan 2004 08:25:20 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06672 Thu, 15 Jan 2004 10:49:39 -0500 (EST) Subject: Re: Initial Contact Message processing To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: David Wierbowski Date: Thu, 15 Jan 2004 11:00:11 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 6.0.2CF2 HFB2 IGS HF12C|January 9, 2004) at 01/15/2004 11:00:12 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thor>> It seems to me that implementations could easily allow the use Thor>> of the identity,address,port tuple instead of just "identity" Thor>> or "address,port" (the latter being a bug). This seems more Thor>> flexible and, to be honest, I don't see any downside to it at Thor>> all. Do you? Thor>> Requiring a different identity for each device used by a given Thor>> user is likely to cause severe problems with X.500 identies, Thor>> considering how certificates are usually allocated to users. I Thor>> worked on one implementation (IKEv1 without Initial Contact, Thor>> FWIW) where this would have been an utter disaster for some of Thor>> our largest customers. Paul> Agreed. Paul> Since a "device" can have multiple NICs, it can have multiple Paul> addresses. So if "address" is used as part of the tuple that Paul> distinguishes devices, how are multi-NIC devices handled? Not sure this is the best answer, but on the implementation that I work on we would require multiple phase 1 SAs with that device. One for every every NIC ( IP address) owned by the device from which a phase 2 negotiation would be started on. Based on this thread we might be better off allowing all NICs to utilize the same SA. From owner-ipsec@lists.tislabs.com Thu Jan 15 13:13:02 2004 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 i0FLCxib069841; Thu, 15 Jan 2004 13:13:02 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA08498 Thu, 15 Jan 2004 15:24:59 -0500 (EST) Message-Id: <5.2.0.9.0.20040115113601.08bfa1c8@10.1.5.10> X-Sender: vamsi@10.1.5.10 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 15 Jan 2004 12:27:13 -0800 To: ipsec@lists.tislabs.com From: vamsi Subject: Old discussion - subject - Me tarzan and me jane Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I went through messages posted on above subject, but did not find any conclusion on that. IPSEC implementations, today, compare ID data in received ID payload with the ID information in Peer certificate and if no certificate ID matches with the ID in ID payload, the transaction is declined. There was some discussion in Mar/Apr 2003 time frame, about making this as local matter, but it is creating inter operability problems. I see somebody indicating that it is not possible to extract the ID from certificate and that is why check should be made local matter. I hope this can't be justification and if that is so, then impersonation is possible. Implementations, at minimum, must ensure that one of IDs in certificate match (full or partial) with the ID configured locally in IKE policy. I see one post indicating that, the sender may not know the ID that needs to be used while sending the ID in ID payload, as certificate may be having multiple IDs in it. This may be true, but in my view, any of the IDs can be sent in ID payload. Receiver of ID payload can ensure that, the received ID is one of the IDs in the certificate. In my view, we should mandate - Sender of ID payload MUST send any one of the IDs in his/her certificate. This ID should be one that is used by the receiver to identify for giving appropriate privileges. - Receiver of ID payload MUST ensure that -- Received ID is one of IDs in the peer certificate -- Received ID matches (full or partial) with locally configured 'Accepted Remote IDs'. Thanks Vamsi CTO Office www.intoto.com From owner-ipsec@lists.tislabs.com Thu Jan 15 14:16:21 2004 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 i0FMGLib073695; Thu, 15 Jan 2004 14:16:21 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08802 Thu, 15 Jan 2004 16:36:57 -0500 (EST) From: chris stillson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16391.2371.833481.654023@gargle.gargle.HOWL> Date: Thu, 15 Jan 2004 13:42:27 -0800 To: ipsec@lists.tislabs.com Subject: comment on draft-ietf-ipsec-udp-encaps-07.txt X-Mailer: VM 7.07 under 21.1 (patch 3) "Acadia" XEmacs Lucid Reply-To: chris.stillson@sun.com X-Face: ;>?o+t66!z`OvpX.6T'j.4l4Gi+L*?8ZnU3L[G/^R,ELl3.Stln=12L+t|hsa*<{/D<{OS( ybD%5