From owner-ipsec@lists.tislabs.com Thu Apr 1 02:13:55 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31ADsSU074932; Thu, 1 Apr 2004 02:13:55 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA04838 Thu, 1 Apr 2004 04:23:16 -0500 (EST) Message-ID: <1AB3D30B989BF141BBD5C70057B2EF7C0476A777@eestqnt105.es.eu.ericsson.se> X-Sybari-Trust: 10702854 272a6e05 c9bf4b46 00000139 From: "David Mariblanca (ML/EEM)" To: "'Tschofenig Hannes'" , "'ipsec@lists.tislabs.com'" Subject: RE: clarification on IKEv2 with EAP Date: Thu, 1 Apr 2004 11:33:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 01 Apr 2004 09:34:59.0888 (UTC) FILETIME=[9A126300:01C417CC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id EAA04830 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi again, I would like to raise other questions: - When generating the AUTH, one input is the "Key Pad for IKEv2", which is supposed to be used in password based authentications, correct ? What happens when the user authentication is not based in passwords ? In that case, can this string be omitted as input to the prf, or can be assigned a fixed value instead ? - If the EAP method being used already provides a message authentication mechanism, does the AUTH have to be computed anyway ? Or only in the cases where the EAP message is not protected by itself, the AUTH has to be used ? Thanks for your time, but I foresee I may come back again with more questions... Cheers, David. -----Original Message----- From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] Sent: miércoles, 31 de marzo de 2004 14:07 To: David Mariblanca (ML/EEM); 'ipsec@lists.tislabs.com' Subject: RE: clarification on IKEv2 with EAP hi david, the AUTH payload in message 4 (from the responder to the initiator) is not based on the keying material of an eap method authentication and key exchange run. hence, it most likely uses public key based authentication. ciao hannes > -----Original Message----- > From: David Mariblanca (ML/EEM) [mailto:david.mariblanca@ericsson.com] > Sent: Wednesday, March 31, 2004 12:37 PM > To: 'ipsec@lists.tislabs.com' > Subject: clarification on IKEv2 with EAP > > > > Hi, > I am reading the IKEv2 i-d and I have a question in chapter > 2.16, about the usage of EAP methods over IKEv2. > The sequence diagram with the process is the following > (copied from the paper): > > Initiator Responder > ----------- ----------- > HDR, SAi1, KEi, Ni --> > > <-- HDR, SAr1, KEr, Nr, [CERTREQ] > > HDR, SK {IDi, [CERTREQ,] [IDr,] > SAi2, TSi, TSr} --> > > <-- HDR, SK {IDr, [CERT,] AUTH, > EAP } > > HDR, SK {EAP, AUTH} --> > > <-- HDR, SK {EAP, AUTH, > SAr2, TSi, TSr } > > > As written in the paper, the initiator omits the AUTH payload > in message 3 when it wants to use EAP. Later on, it is > written that when the whole EAP message is finished, the > resultant shared secret (if exists) is used to generate the > AUTH in messages 5 and 6. My question is: what about AUTH in > message 4 ? How is it generated ? > > Thanks and best regards, > David. > > From owner-ipsec@lists.tislabs.com Thu Apr 1 02:54:55 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31Assgq079280; Thu, 1 Apr 2004 02:54:54 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA13614 Thu, 1 Apr 2004 05:18:21 -0500 (EST) Message-ID: <1AB3D30B989BF141BBD5C70057B2EF7C0476A779@eestqnt105.es.eu.ericsson.se> X-Sybari-Trust: 3301a08d 2c4885b5 c2dda0f6 00000138 From: "David Mariblanca (ML/EEM)" To: "'Tschofenig Hannes'" , "'ipsec@lists.tislabs.com'" Subject: RE: clarification on IKEv2 with EAP Date: Thu, 1 Apr 2004 12:29:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 01 Apr 2004 10:30:55.0952 (UTC) FILETIME=[6A711D00:01C417D4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id FAA13588 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, and thanks for the quick reply. Yes, I was talking about the AUTH payloads generated after the EAP exchange. I hadn't realize there was already a version 13, I was still using version 12. Anyway, the new one does not make things completely clear to me yet. I will give my interpretation of chapter 16 and please confirm if it is correct. - The EAP payloads are sent in the IKEv2 messages without AUTH payloads. The AUTH payloads are sent only in the last two IKEv2 messages, and they correspond to the last two EAP messages, that is, AUTH in message 7 to EAP payload in message 5, and AUTH in message 8 to EAP payload in message 6 - Since the AUTH payloads correspond to the two last messages and they are only sent in the two last IKEv2 messages, if the EAP messages exchanged are more than showed in the diagram, the rest of the EAP messages before the last two ones are not authenticated with AUTH payloads, even in the EAP method had obtained previously the key material needed to generate the AUTH (and hence it could be possible to protect previous EAP messages). Is this correct ? BR, David. -----Original Message----- From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] Sent: jueves, 01 de abril de 2004 12:07 To: David Mariblanca (ML/EEM); 'ipsec@lists.tislabs.com' Subject: RE: clarification on IKEv2 with EAP hi david, > Hi again, > I would like to raise other questions: > - When generating the AUTH, one input is the "Key Pad for > IKEv2", which is supposed to be used in password based > authentications, correct ? with eap authentication in ikev2 there are three AUTH payloads. the AUTH payload in message 4 from the responder to the initiator is based on the chosen IKEv2 authentication mechanism. i guess you are not talking about this AUTH payload. for the AUTH payloads which are sent after the EAP protocol exchange finished you use the key derived by the eap method. you can find a more detailed description in section 2.16 of . > What happens when the user > authentication is not based in passwords ? from this perspective, key derivation is independent of the credentials (symmetric or asymmetric) used for authentication was based. In that case, can > this string be omitted as input to the prf, or can be > assigned a fixed value instead ? > - If the EAP method being used already provides a message > authentication mechanism, does the AUTH have to be computed > anyway ? even if the EAP method provides mutual authentication and key derivation (and many other security properties) you still have to exchange the AUTH payloads between the IKEv2 peer to prevent a man-in-the-middle attack. for more details please take a look at: [EAPMITM] Asokan, N., Nierni, V., and Nyberg, K., "Man-in-the-Middle in Tunneled Authentication Protocols", http://eprint.iacr.org/2002/163, November 2002. > Or only in the cases where the EAP message is not > protected by itself, the AUTH has to be used ? the fact that some eap methods protect some of their payloads is independent of this issue. > > Thanks for your time, but I foresee I may come back again > with more questions... > Cheers, > David. ciao hannes > > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: miércoles, 31 de marzo de 2004 14:07 > To: David Mariblanca (ML/EEM); 'ipsec@lists.tislabs.com' > Subject: RE: clarification on IKEv2 with EAP > > > hi david, > > the AUTH payload in message 4 (from the responder to the > initiator) is not > based on the keying material of an eap method authentication and key > exchange run. hence, it most likely uses public key based > authentication. > > ciao > hannes > > > > -----Original Message----- > > From: David Mariblanca (ML/EEM) [mailto:david.mariblanca@ericsson.com] > Sent: Wednesday, March 31, 2004 12:37 PM > To: 'ipsec@lists.tislabs.com' > Subject: clarification on IKEv2 with EAP > > > > Hi, > I am reading the IKEv2 i-d and I have a question in chapter > 2.16, about the usage of EAP methods over IKEv2. > The sequence diagram with the process is the following > (copied from the paper): > > Initiator Responder > ----------- ----------- > HDR, SAi1, KEi, Ni --> > > <-- HDR, SAr1, KEr, Nr, [CERTREQ] > > HDR, SK {IDi, [CERTREQ,] [IDr,] > SAi2, TSi, TSr} --> > > <-- HDR, SK {IDr, [CERT,] AUTH, > EAP } > > HDR, SK {EAP, AUTH} --> > > <-- HDR, SK {EAP, AUTH, > SAr2, TSi, TSr } > > > As written in the paper, the initiator omits the AUTH payload > in message 3 when it wants to use EAP. Later on, it is > written that when the whole EAP message is finished, the > resultant shared secret (if exists) is used to generate the > AUTH in messages 5 and 6. My question is: what about AUTH in > message 4 ? How is it generated ? > > Thanks and best regards, > David. > > From owner-ipsec@lists.tislabs.com Thu Apr 1 03:41:24 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31BfNE1083974; Thu, 1 Apr 2004 03:41:24 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA23211 Thu, 1 Apr 2004 05:59:04 -0500 (EST) From: Pasi.Eronen@nokia.com X-Scanned: Thu, 1 Apr 2004 14:09:10 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: clarification on IKEv2 with EAP Date: Thu, 1 Apr 2004 14:08:58 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61223B5@esebe023.ntc.nokia.com> Thread-Topic: clarification on IKEv2 with EAP Thread-Index: AcQX00yd5eiqI727SMOd0J65nynfQwABQ4/g To: , X-OriginalArrivalTime: 01 Apr 2004 11:09:01.0241 (UTC) FILETIME=[BC948A90:01C417D9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id FAA23136 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, The "Key Pad for IKEv2" part is always included, even if the shared secret is not actually a password entered by the user. AUTH payloads are also always included (the EAP message authentication protects only EAP messages; the AUTH part is needed to authenticate the IKEv2 exchange). Best regards, Pasi > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of ext David > Mariblanca > (ML/EEM) > Sent: Thursday, April 01, 2004 12:34 PM > To: 'Tschofenig Hannes'; 'ipsec@lists.tislabs.com' > Subject: RE: clarification on IKEv2 with EAP > > > > > Hi again, > I would like to raise other questions: > - When generating the AUTH, one input is the "Key Pad for > IKEv2", which is supposed to be used in password based > authentications, correct ? What happens when the user > authentication is not based in passwords ? In that case, can > this string be omitted as input to the prf, or can be > assigned a fixed value instead ? > - If the EAP method being used already provides a message > authentication mechanism, does the AUTH have to be computed > anyway ? Or only in the cases where the EAP message is not > protected by itself, the AUTH has to be used ? > > Thanks for your time, but I foresee I may come back again > with more questions... > Cheers, > David. > > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: miércoles, 31 de marzo de 2004 14:07 > To: David Mariblanca (ML/EEM); 'ipsec@lists.tislabs.com' > Subject: RE: clarification on IKEv2 with EAP > > > hi david, > > the AUTH payload in message 4 (from the responder to the > initiator) is not > based on the keying material of an eap method authentication and key > exchange run. hence, it most likely uses public key based > authentication. > > ciao > hannes > > > > -----Original Message----- > > From: David Mariblanca (ML/EEM) > [mailto:david.mariblanca@ericsson.com] > > Sent: Wednesday, March 31, 2004 12:37 PM > > To: 'ipsec@lists.tislabs.com' > > Subject: clarification on IKEv2 with EAP > > > > > > > > Hi, > > I am reading the IKEv2 i-d and I have a question in chapter > > 2.16, about the usage of EAP methods over IKEv2. > > The sequence diagram with the process is the following > > (copied from the paper): > > > > Initiator Responder > > ----------- ----------- > > HDR, SAi1, KEi, Ni --> > > > > <-- HDR, SAr1, KEr, > Nr, [CERTREQ] > > > > HDR, SK {IDi, [CERTREQ,] [IDr,] > > SAi2, TSi, TSr} --> > > > > <-- HDR, SK {IDr, [CERT,] AUTH, > > EAP } > > > > HDR, SK {EAP, AUTH} --> > > > > <-- HDR, SK {EAP, AUTH, > > SAr2, TSi, TSr } > > > > > > As written in the paper, the initiator omits the AUTH payload > > in message 3 when it wants to use EAP. Later on, it is > > written that when the whole EAP message is finished, the > > resultant shared secret (if exists) is used to generate the > > AUTH in messages 5 and 6. My question is: what about AUTH in > > message 4 ? How is it generated ? > > > > Thanks and best regards, > > David. > > > > > From owner-ipsec@lists.tislabs.com Thu Apr 1 03:41:41 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31BfeuG084013; Thu, 1 Apr 2004 03:41:40 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA24376 Thu, 1 Apr 2004 06:07:17 -0500 (EST) From: Pasi.Eronen@nokia.com X-Scanned: Thu, 1 Apr 2004 14:19:07 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: clarification on IKEv2 with EAP Date: Thu, 1 Apr 2004 14:18:35 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61223B6@esebe023.ntc.nokia.com> Thread-Topic: clarification on IKEv2 with EAP Thread-Index: AcQX2PIkeuU6hdrCThSTI8wIb33EOgAANmPg To: , X-OriginalArrivalTime: 01 Apr 2004 11:18:36.0784 (UTC) FILETIME=[13A16F00:01C417DB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id GAA24357 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David Mariblanca wrote: > I will give my interpretation of chapter 16 and please confirm > if it is correct. > - The EAP payloads are sent in the IKEv2 messages without > AUTH payloads. The AUTH payloads are sent only in the last > two IKEv2 messages, and they correspond to the last two EAP > messages, that is, AUTH in message 7 to EAP payload in > message 5, and AUTH in message 8 to EAP payload in message 6 No, AUTH payloads do not authenticate the EAP messages, they authenticate the IKEv2 SA (basically information from the first two IKEv2 messages; first paragraph of Section 2.15 explains exactly what is included in the ""). (All EAP messages are also MAC'd with SK_ar/SK_ai, but this is not related to AUTH payloads; the integrity protection is included in the "SK{...}" notation). Best regards, Pasi From owner-ipsec@lists.tislabs.com Thu Apr 1 05:08:59 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31D8wlW092065; Thu, 1 Apr 2004 05:08:59 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA06148 Thu, 1 Apr 2004 07:27:48 -0500 (EST) Message-ID: <1AB3D30B989BF141BBD5C70057B2EF7C0476A77B@eestqnt105.es.eu.ericsson.se> X-Sybari-Trust: 1623d8bd 2c4885b5 c2dda0f6 00000138 From: "David Mariblanca (ML/EEM)" To: "'Pasi.Eronen@nokia.com'" , ipsec@lists.tislabs.com Subject: RE: clarification on IKEv2 with EAP Date: Thu, 1 Apr 2004 14:38:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 01 Apr 2004 12:39:48.0861 (UTC) FILETIME=[6B9D62D0:01C417E6] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ok, I see. I did not remember the EAP messages were already integrity protected and encrypted with Sk_a and Sk_e. Then the AUTH payloads protect the IKE_INIT messages, the ones which were not sent protected since there was not key material yet to do it, correct ? -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: jueves, 01 de abril de 2004 13:19 To: David Mariblanca (ML/EEM); ipsec@lists.tislabs.com Subject: RE: clarification on IKEv2 with EAP David Mariblanca wrote: > I will give my interpretation of chapter 16 and please confirm > if it is correct. > - The EAP payloads are sent in the IKEv2 messages without > AUTH payloads. The AUTH payloads are sent only in the last > two IKEv2 messages, and they correspond to the last two EAP > messages, that is, AUTH in message 7 to EAP payload in > message 5, and AUTH in message 8 to EAP payload in message 6 No, AUTH payloads do not authenticate the EAP messages, they authenticate the IKEv2 SA (basically information from the first two IKEv2 messages; first paragraph of Section 2.15 explains exactly what is included in the ""). (All EAP messages are also MAC'd with SK_ar/SK_ai, but this is not related to AUTH payloads; the integrity protection is included in the "SK{...}" notation). Best regards, Pasi From owner-ipsec@lists.tislabs.com Thu Apr 1 06:02:37 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31E2bNr096542; Thu, 1 Apr 2004 06:02:37 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA12719 Thu, 1 Apr 2004 08:24:12 -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: <16492.6896.588750.18184@fireball.acr.fi> Date: Thu, 1 Apr 2004 16:36:48 +0300 From: Tero Kivinen To: Stephen Kent Cc: "Mohan Parthasarathy" , Subject: Re: 2nd try In-Reply-To: References: <16480.15529.482315.278735@fireball.acr.fi> <016c01c416c3$eb1d8270$861167c0@adithya> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 11 min X-Total-Time: 96 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > We would like to have at least one, mandatory way for two IPsec peers > to carry fragments via SAs, when port-specific SAs are employed, > hence we need at least one approach that is a MUST. The third > recommendation would satisfy the requirement, but the reassembly > process may be a hardship for very high speed implementations. That's I think we should select the most secure protocol (i.e. case #3) as MUST, and allow #2 protocol for high-speed implementations as MAY. This way we would always have one MUST to implement version which allows secure transport of fragments over port selector SAs, and the requirements would be same for the IPv4 and IPv6. > why I suggested this option as a MAY. The reason for making the > second recommendation the MUST, for IPv4, is because it satisfies the > requirement, and does not seem likely to impose performance > penalties. It is only a MAY/SHOULD for IPv6 because there are > security problems for v6 when dealing with fragments w/o reassembly, > as noted in the analysis. So for IPv6 there is no MUST to implement protocol at all? > >If the implementation takes the conservative approach of keeping it > >simple and secure > >(Vs performance), isn't MUST a bit too strong ? > > Reassembly or reassmebly-like state tracking is not simple, although It is not that complicated either. Full reassembly code in the netbsd kernel is about 200 lines (not counting code for general queue macros etc), our partial and full reassembly code is about 1000 lines (it does quite a lot more than only partial reassembly). > if properly implemented it is secure for both IPv4 and v6. That is > its major benefit, in my view. Which is the reason I would like it to be MUST, or at least SHOULD, and the case #2 to be MAY. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Thu Apr 1 07:35:03 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31FZ2VM003296; Thu, 1 Apr 2004 07:35:02 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20363 Thu, 1 Apr 2004 09:46:47 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16492.11809.549000.161412@gargle.gargle.HOWL> Date: Thu, 1 Apr 2004 09:58:41 -0500 From: Paul Koning To: kivinen@iki.fi Cc: kent@bbn.com, mohanp@sbcglobal.net, ipsec@lists.tislabs.com Subject: Re: 2nd try References: <16480.15529.482315.278735@fireball.acr.fi> <016c01c416c3$eb1d8270$861167c0@adithya> <16492.6896.588750.18184@fireball.acr.fi> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Tero" == Tero Kivinen writes: >> Reassembly or reassmebly-like state tracking is not simple, >> although Tero> It is not that complicated either. Full reassembly code in the Tero> netbsd kernel is about 200 lines (not counting code for general Tero> queue macros etc), our partial and full reassembly code is Tero> about 1000 lines (it does quite a lot more than only partial Tero> reassembly). Reassembly isn't all that hard in software, although it gets more complicated if you really care about performance when there are a large number of simultaneous streams. But reassembly in hardware is quite another matter. While I'm no great fan of option #2, I feel that requiring it is a better choice than requiring reassembly (option #3). paul From owner-ipsec@lists.tislabs.com Thu Apr 1 07:59:27 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31FxQxm005718; Thu, 1 Apr 2004 07:59:26 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA23567 Thu, 1 Apr 2004 10:17:29 -0500 (EST) From: "Bora Akyol" To: "'Stephen Kent'" , Subject: RE: 2nd try Date: Thu, 1 Apr 2004 07:28:10 -0800 Message-ID: <001f01c417fd$f0f79a60$020a0a0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, This looks good, one question about the fragment SA(s): If we have several "parallel" SAs to support different levels of QoS (for the main SAs), do we need to have the same amount of fragment SAs as the main ones? Thanks Bora > Conclusions > > There is no simple, uniform way to handle fragments in all contexts. > Different approaches work better in different contexts. Thus I > suggest we require support for two approaches, and offer a third, and > allow a user or administrator to choose from among these based on > topology constraints and security requirements. Hence the following > proposed text: > > 1. All implementations MUST support tunnel mode SAs that pass traffic > without regard to port field values. If the SA will carry traffic for > specified protocols, the two selector sets MUST be used to specify > the port fields for the SA: ANY and OPAQUE. An SA defined in this > fashion will carry all traffic for the indicated source/destination > addresses and specified protocol(s). If the SA will carry traffic > without regard to a specific protocol value (i.e., ANY is specified), > then the port field values MUST be set to ANY as well. > > 2. All implementations MUST support tunnel mode SAs that will carry > only non-initial fragments, separate from non-fragmented packets and > initial fragments. The OPAQUE value will be used to specify port > field selectors for an SA to carry non-initial fragments. Specific > port selector values will be used to define SAs to carry initial > fragments and non-fragmented packets. This approach can be used if a > user or administrator wants to create one or more tunnel mode SAs > between the same source/destination addresses that discriminate based > on port fields. These SAs MUST have non-trivial protocol selector > values, otherwise approach #1 above can be used. Receivers MUST > perform a minimum offset check on IPv4 (non-initial) fragments to > protect against overlapping fragment attacks when SAs of this type > are employed. Because such checks cannot be performed on IPv6 > non-initial fragments, users and administrators are advised that > carriage of such fragments may be dangerous, and implementers may > choose to NOT support such SAs for IPv6 traffic. Also, because a SA > of this sort will carry ALL non-initial fragments that match a > specified source/destination address pair and protocol value, users > and administrators are advised to protect such traffic using ESP > (with integrity) and the "strongest" integrity and encryption > algorithms available at both peers. (Determination of the "strongest" > algorithms requires imposing a total ordering of the available > algorithms, a local determination at the discretion of the initiator > of the SA.) > > 3. An implementation MAY choose to support some form of stateful > fragment checking for a tunnel mode SA with non-trivial port field > values (not ANY or OPAQUE). Implementations that will transmit > non-initial fragments on a tunnel mode SA that makes use of > non-trivial port selectors MUST notify a peer via an IKE payload > (TBD). The peer MUST reject this proposal if it will not accept > non-initial fragments in this context. If an implementation does not > successfully negotiate transmission of non-initial fragments for such > an SA, it MUST NOT send such fragments over the SA. This standard > does not specify how peers will deal with such fragments, e.g., via > reassembly or other means, at either sender or receiver. However, a > receiver MUST drop non-initial fragments that arrive on an SA with > non-trivial port selector values unless this feature has been > negotiated. Dropping such packets is an auditable event. Note that in > configurations where fragments of a packet might be sent or received > via different security gateways or BITW implementations, stateful > strategies for tracking fragments may fail. > From owner-ipsec@lists.tislabs.com Thu Apr 1 08:42:32 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31GgW6P009074; Thu, 1 Apr 2004 08:42:32 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28181 Thu, 1 Apr 2004 11:01:06 -0500 (EST) Message-ID: <1AB3D30B989BF141BBD5C70057B2EF7C0476A78A@eestqnt105.es.eu.ericsson.se> X-Sybari-Trust: 25f0d223 272a6e05 71032c23 00000139 From: "David Mariblanca (ML/EEM)" To: "'Tschofenig Hannes'" , "'Pasi.Eronen@nokia.com'" , ipsec@lists.tislabs.com Subject: RE: clarification on IKEv2 with EAP Date: Thu, 1 Apr 2004 18:12:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 01 Apr 2004 16:13:43.0726 (UTC) FILETIME=[4DCA5CE0:01C41804] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, well, I am not specially worried about that, but rather to implement extra protections when it's not needed. The EAP methods I am now thinking about are EAP SIM and EAP AKA, which already provide some protection mechanisms. If IKEv2, on top of that, gives integrity and encryption to the EAP messages, maybe we will spend unnecessary resources when using EAP SIM/AKA over IKEv2, if we consider that either IKEv2 or EAP SIM/AKA levels of protection are secure enough. But I guess other EAP methods do not provide the same level of protection and that's why IKEv2 has to be designed in order to not depend on EAP implementations. In the other hand, after reading your paper (the one you are writing with Pasi) I see very reasonable your proposal to omit AUTH in message 4: if IKEv2 says that in messages 7 and 8 the AUTH payloads will protect messages 1 and 2 (respectively), why to send AUTH in message 4 ? Does message 2 need to be authenticated twice ? Cheers, David. -----Original Message----- From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] Sent: jueves, 01 de abril de 2004 17:31 To: David Mariblanca (ML/EEM); 'Pasi.Eronen@nokia.com'; ipsec@lists.tislabs.com Subject: RE: clarification on IKEv2 with EAP hi david, i am only curious: why do you worry about the protection of eap messages? ciao hannes > Ok, I see. I did not remember the EAP messages were already > integrity protected and encrypted with Sk_a and Sk_e. Then > the AUTH payloads protect the IKE_INIT messages, the ones > which were not sent protected since there was not key > material yet to do it, correct ? > > > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: jueves, 01 de abril de 2004 13:19 > To: David Mariblanca (ML/EEM); ipsec@lists.tislabs.com > Subject: RE: clarification on IKEv2 with EAP > > > > David Mariblanca wrote: > > > I will give my interpretation of chapter 16 and please confirm > > if it is correct. > > - The EAP payloads are sent in the IKEv2 messages without > > AUTH payloads. The AUTH payloads are sent only in the last > > two IKEv2 messages, and they correspond to the last two EAP > > messages, that is, AUTH in message 7 to EAP payload in > > message 5, and AUTH in message 8 to EAP payload in message 6 > > No, AUTH payloads do not authenticate the EAP messages, they > authenticate the IKEv2 SA (basically information from the > first two IKEv2 messages; first paragraph of Section 2.15 > explains exactly what is included in the ""). > > (All EAP messages are also MAC'd with SK_ar/SK_ai, but this is > not related to AUTH payloads; the integrity protection is > included in the "SK{...}" notation). > > Best regards, > Pasi > From owner-ipsec@lists.tislabs.com Thu Apr 1 08:46:07 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31Gk6Ee009275; Thu, 1 Apr 2004 08:46:06 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27854 Thu, 1 Apr 2004 10:58:53 -0500 (EST) Message-Id: <200404011608.i31G81Ld004082@rs9.luxsci.com> From: "William Dixon" To: "'Tero Kivinen'" , "'David Wierbowski'" Cc: Subject: RE: IDci and IDcr payloads with NAT Traversal Date: Thu, 1 Apr 2004 11:07:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <16489.13822.640061.177557@fireball.acr.fi> X-Lux-Comment: LuxSci remailer message ID code - 1080835681-180917.199575543 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero, I agree with your proposed change as long as the peers detect they are behind NAT. But as you may both know, this is a general interop issue with IKEv1 regardless of NATs because so many options are allowed as ID types, the ID payload being an optional payload anyway, and we don't have en efficient, standardized way to determine what ID type an initiator must use with a given responder. The reality then is that the vendor's decision about their policy system controls what IDs they can reasonably accept and thus who interops with who, with hacks based on vendor ID recognition and some internal decisions to handle the rest. I would hope IKEv2 provides clarity to improve the situation. I don't think it's reasonable that vendors have to build policy systems such that all ID types are supported in policy, and must be configured to ensure interop. I'm not sure if there is a way to get a policy system that initiates using FQDN names to interop safely with one that responds only with IPv4_ADDR. If everyone supports everything, sure all this can be manually configured... Certainly it's impractical for my own client as initiator to be manually configured differently to talk to any destination I may go to in the Internet. So we should probably also specify how to handle policy transition from address-dependent policy to names. Cheers, Wm > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Tero Kivinen > Sent: Tuesday, March 30, 2004 3:55 AM > To: David Wierbowski > Cc: ipsec@lists.tislabs.com > Subject: Re: IDci and IDcr payloads with NAT Traversal > > David Wierbowski writes: > > Perhaps I'm reading too much into your answer, but there > seems to be > > some inconsistencies with IDci and IDcr when NAT Traversal is used. > > Let's consider a simpler example: > > > > > > HOST A ----> A's NAT ----> B's NAT ----> HOST B > > 10.1.1.1 10.2.2.2 > > Note, as there is two NAT's there the initiastor MUST have > specific configuration about the situation. I.e. it will have > configuration saying if I want to reach host B (ip = > 10.2.2.2) create NAT-T connection using the B's NAt address > of y.y.y.y. > > > Where: > > - The private address for HOST A is 10.1.1.1 > > - HOST A's NAT translates 10.1.1.1. to x.x.x.x > > > > - The private address for HOST B is 10.2.2.2 > > - B's NAT translates 10.2.2.2 to y.y.y.y (where y.y.y.y > > is static). > > > > There are two cases: > > 1) HOST A is trying create a phase 2 SA with HOST B > > to protect ALL traffic between HOST A and HOST B. > > > > 2) HOST A is trying create a phase 2 SA with HOST B > > to protect TCP traffic between HOST A and HOST B. > > > > In case 1 there is no need to exchange IDci and IDcr. They can be > > assumed to be the IP addresses of the IKE peers without any implied > > constraints on port or protocol. > > Yes, for the transport mode. For the tunnel mode that really > does not work, as both ends must agree on the IDs otherwise > they will drop the packet during the tunnel exit checks. Lets > assume tunnel mode for now, so both ends MUST send ID payloads. > > > To me this would imply that both > > HOST A and HOST B have a different view of IDci and IDcr. > > - HOST A would think the IP address for IDci is 10.1.1.1 > > and for IDcr is y.y.y.y. > > No, the HOST A will know from the configuration that it > wanted to create SA with 10.2.2.2, and that was simply > reached by sending packets to y.y.y.y, thus it will have IDci > 10.1.1.1 and IDcr 10.2.2.2. > It will also notice that it must send IDci and IDcr as they > do not match the IP-addresses. > > > - HOST B would think the IP address for IDci is x.x.x.x > > and for IDcr is 10.2.2.2 > > As HOST A will send the IDs the HOST B will know that the > other end is 10.1.1.1, and not use implicit IP. > > > In case 2 ID payloads must be exchanged (since traffic is > constrained > > to TCP traffic). Based on your previous answer I'm > thinking you would > > expect both HOST A and HOST B to view IDci as 10.1.1.1 and IDcr as > > 10.2.2.2. > > Yes. > > > Based on what the IDs would be if no ID payloads were sent I would > > expect that the IDs exchanged in case 2 should be the same > as the IDs > > implied in case 1. This seems far more natural to me as it > does not > > require HOST A to know HOST B's private address before the > negotiation > > starts > > How does the implementation on HOST A start? The HOST A needs > to have some configuration which initiates the connection. In > normal case it is the packet send to the HOST B ip-address, > which means that HOST A needs to know the HOST B's ip-address > so it can send that packet, and after trig create the SA with > correct host. > > > and it does not require HOST B to > > know HOST A's private address before the negotiation starts. I > > HOST B does not need to know the private address of A, as it > can see it from the ID payloads. > > > will admit that in the gateway case (my original case) that > it seems > > as if knowledge of private addresses must be shared. > > It is the same with this case as long as the tunnel mode is used. > > > I think that the "Negotiation of NAT-Traversal in IKE" > drafts needs to > > include conventions for setting IDci and IDcr. Perhaps > IDci and IDcr > > should always be exchanged when NAT is detected? > > For transport mode, you simply ignore the IP-addresses, and > you can put anything you like there (or even use fqdn as IDci > and IDcr, so you do not need to care about the IP-addresses). > > For tunnel mode you put the internal IP-addresses, because > that is how the tunnel exit policy is negotiated. > > > My concern is that without establishing a convention for > dealing with > > IDci and IDcr that we open ourselves up to possible > interoperability > > issues. > > We talked about the IDci and IDcr earlier, but we really > couldn't agree anything else than it depends on the scenario, > and almost everything can be used. Some wanted to use FQDNs, > some wanted to say we simply ignore all IP-numbers in tunnel > mode, and some say we leave them out completely. > > I would have liked to add following text: > > "If negotiation is using transport mode, then received > IP-addresses in the IDci and IDcr MUST be ignored, i.e. only > port and protocol numbers are used. If negotiation is using > tunnel mode, then IDci and IDcr MUST have IP-address used > inside the tunnel i.e. IP-addresses used in the inner IP-header." > -- > kivinen@safenet-inc.com > > From owner-ipsec@lists.tislabs.com Thu Apr 1 08:55:57 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31Gtv1q010051; Thu, 1 Apr 2004 08:55:57 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA01368 Thu, 1 Apr 2004 11:17:58 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <001f01c417fd$f0f79a60$020a0a0a@amer.cisco.com> References: <001f01c417fd$f0f79a60$020a0a0a@amer.cisco.com> Date: Thu, 1 Apr 2004 11:02:46 -0500 To: "Bora Akyol" From: Stephen Kent Subject: RE: 2nd try Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:28 AM -0800 4/1/04, Bora Akyol wrote: >Hi Steve, > >This looks good, one question about the fragment SA(s): > >If we have several "parallel" SAs to support different levels >of QoS (for the main SAs), do we need to have the same amount >of fragment SAs as the main ones? > >Thanks > >Bora Good question. In general, for approach #2, one needs only a single SA between two implementations to carry all non-initial fragments between them. But, if you chose to have multiple SAs between two implementations, for QoS differentiation, then you might want multiple SAs to carry non-initial fragments, one for each supported QoS class. Since support for QoS via distinct SAs is a local matter, not mandated by 2401/2401bis, this too should be a local choice. Steve From owner-ipsec@lists.tislabs.com Thu Apr 1 09:04:06 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31H45Tm010634; Thu, 1 Apr 2004 09:04:06 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA01350 Thu, 1 Apr 2004 11:17:52 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16492.6896.588750.18184@fireball.acr.fi> References: <16480.15529.482315.278735@fireball.acr.fi> <016c01c416c3$eb1d8270$861167c0@adithya> <16492.6896.588750.18184@fireball.acr.fi> Date: Thu, 1 Apr 2004 11:19:56 -0500 To: Tero Kivinen From: Stephen Kent Subject: Re: 2nd try Cc: "Mohan Parthasarathy" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:36 PM +0300 4/1/04, Tero Kivinen wrote: >Stephen Kent writes: >> We would like to have at least one, mandatory way for two IPsec peers >> to carry fragments via SAs, when port-specific SAs are employed, >> hence we need at least one approach that is a MUST. The third >> recommendation would satisfy the requirement, but the reassembly >> process may be a hardship for very high speed implementations. That's > >I think we should select the most secure protocol (i.e. case #3) as >MUST, and allow #2 protocol for high-speed implementations as MAY. #2 and #3 are equally secure in terms of IPv4. But, as you note below, #2 does not accommodate IPv6 securely. So, only in that sense is there a difference. >This way we would always have one MUST to implement version which >allows secure transport of fragments over port selector SAs, and the >requirements would be same for the IPv4 and IPv6. > >> why I suggested this option as a MAY. The reason for making the >> second recommendation the MUST, for IPv4, is because it satisfies the >> requirement, and does not seem likely to impose performance >> penalties. It is only a MAY/SHOULD for IPv6 because there are >> security problems for v6 when dealing with fragments w/o reassembly, >> as noted in the analysis. > >So for IPv6 there is no MUST to implement protocol at all? yes. I admit that this is not ideal, but you are correct that this would be the result if we made #2 a MUST and #3 a MAY. > > >If the implementation takes the conservative approach of keeping it >> >simple and secure >> >(Vs performance), isn't MUST a bit too strong ? >> >> Reassembly or reassmebly-like state tracking is not simple, although > >It is not that complicated either. Full reassembly code in the netbsd >kernel is about 200 lines (not counting code for general queue macros >etc), our partial and full reassembly code is about 1000 lines (it >does quite a lot more than only partial reassembly). As Paul noted, it is a lot more difficult in hardware, especially at very high speeds. My experience in designing such devices convinces me of that fact, as much as your experience in developing software has convinced you that it is not too complex in that context. (BTW, was this software for an end systems or an SG?) > >> if properly implemented it is secure for both IPv4 and v6. That is >> its major benefit, in my view. > >Which is the reason I would like it to be MUST, or at least SHOULD, >and the case #2 to be MAY. How about a compromise? We could make #2 a MAY and #3 a SHOULD. A SHOULD is almost a MUST, with a loophole as noted below (from RFC 2119): SHOULD This word, or the adjective "RECOMMENDED", means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. This would allow a hardware implementation to not support #3, if doing so would adversely impact overall performance. Steve From owner-ipsec@lists.tislabs.com Thu Apr 1 09:06:00 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31H607H010763; Thu, 1 Apr 2004 09:06:00 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA02156 Thu, 1 Apr 2004 11:23:17 -0500 (EST) Message-Id: <5.2.0.9.0.20040401112945.0205b9d8@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 01 Apr 2004 11:36:09 -0500 To: Paul Koning , kivinen@iki.fi From: Mark Duffy Subject: Re: 2nd try Cc: kent@bbn.com, mohanp@sbcglobal.net, ipsec@lists.tislabs.com In-Reply-To: <16492.11809.549000.161412@gargle.gargle.HOWL> References: <16480.15529.482315.278735@fireball.acr.fi> <016c01c416c3$eb1d8270$861167c0@adithya> <16492.6896.588750.18184@fireball.acr.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:58 AM 4/1/2004 -0500, Paul Koning wrote: > >>>>> "Tero" == Tero Kivinen writes: > > >> Reassembly or reassmebly-like state tracking is not simple, > >> although > > Tero> It is not that complicated either. Full reassembly code in the > Tero> netbsd kernel is about 200 lines (not counting code for general > Tero> queue macros etc), our partial and full reassembly code is > Tero> about 1000 lines (it does quite a lot more than only partial > Tero> reassembly). > >Reassembly isn't all that hard in software, although it gets more >complicated if you really care about performance when there are a >large number of simultaneous streams. But reassembly in hardware is >quite another matter. > >While I'm no great fan of option #2, I feel that requiring it is a >better choice than requiring reassembly (option #3). > > paul Not only is it complex to do in hardware, it also can demand a tremendous amount of buffering in high speed implementations. Between the buffering issue, and the possible need to handle fragments as a software exception to the hardware "fast path", this also opens a DOS opportunity against the security gateway. I believe that option #2 should be the required one and #3 optional. --Mark From owner-ipsec@lists.tislabs.com Thu Apr 1 14:17:43 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31MHg9K033976; Thu, 1 Apr 2004 14:17:42 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16900 Thu, 1 Apr 2004 16:32:22 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Thu, 1 Apr 2004 16:52:12 -0500 To: ipsec@lists.tislabs.com From: Karen Seo Subject: mail list blocked Cc: skent@bbn.com, clynn@bbn.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, In case you've been waiting for a reply from BBN... Since mid-Friday (3/26), we haven't received any mail that was addressed ONLY to the IPsec mailing list. We just found out that lists.tislabs.com has been added to the Open Relay database, and BBN's mailers block mail from hosts in that database. So if you sent mail to a BBNer and didn't specifically address it to him/her, it wouldn't have gotten through. The tislabs folks are working on fixing the problem, but it could be many hours before ORDB.ORG removes them from their database. Karen From owner-ipsec@lists.tislabs.com Thu Apr 1 14:37:19 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31MbJXA034951; Thu, 1 Apr 2004 14:37:19 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20196 Thu, 1 Apr 2004 17:00:18 -0500 (EST) Message-Id: <200404012208.i31M806t008846@rs9.luxsci.com> From: "William Dixon" To: "'Angelos D. Keromytis'" , , "'Stephen Kent'" Subject: RE: Issue 83 will be withdrawn Date: Thu, 1 Apr 2004 17:06:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In-Reply-To: <200403301717.i2UHHhCI024980@coredump.cs.columbia.edu> X-Lux-Comment: LuxSci remailer message ID code - 1080857280-2067400.01338129 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This concerns me greatly. It was originally a "MUST FIX". Steve, can we have an explanation of why this was withdrawn and what mechanisms should be used instead ? I don't see solutions in Issue 91 to compensate. What was the TCP/IP or IPsec deployment purpose of those ICMP codes ? Thanks, Wm Reference: Issue 83: Description =========== Should there be a defined ICMP response to be used (when dropping an inbound packet that was not protected by IPsec) to indicate to the sender that IPsec was required by the receiver who dropped the packet? Proposed approach ================= Add text saying something along the lines of... "If an IPsec system receives an inbound (unprotected) packet for which the matching SPD entry requires IPsec protection, it MUST drop the packet. It SHOULD also be capable of generating and sending an ICMP message to indicate to the sender that the receiver dropped the packet. The reason SHOULD be recorded in the audit log. IPv4 Type = 3 (destination unreachable) Code = 13 (Communication Administratively Prohibited) IPv6 Type = 1 (destination unreachable) Code = 1 (Communication with destination administratively prohibited Note that an attacker could send packets with a spoofed source address, W.X.Y.Z, to an IPsec entity causing it to send ICMP messages to W.X.Y.Z. This creates an opportunity to use an IPsec receiver in a DoS attack. To address this, the implementation SHOULD provide management controls to allow an administrator to configure an IPsec implementation to send or not send the above ICMP message, or to rate limit the transmission of such ICMP responses. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Angelos > D. Keromytis > Sent: Tuesday, March 30, 2004 12:18 PM > To: ipsec@lists.tislabs.com > Subject: Issue 83 will be withdrawn > > > https://roundup.machshav.com/ipsec/issue83 > > Issue 83 will be withdrawn and marked closed, unless someone > disagrees by next Tuesday. > -Angelos > > From owner-ipsec@lists.tislabs.com Thu Apr 1 15:09:03 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i31N93rn037154; Thu, 1 Apr 2004 15:09:03 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22513 Thu, 1 Apr 2004 17:29:23 -0500 (EST) X-BrightmailFiltered: true From: "Bora Akyol" To: "'Stephen Kent'" Cc: Subject: RE: 2nd try Date: Thu, 1 Apr 2004 14:42:03 -0800 Message-ID: <002a01c4183a$8d97eb90$422745ab@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: x-mimeole: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks Would you mind adding a single sentence to this effect to the text when the fragment text is rolled in to make it consistent with the main SA treatment. Bora > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Stephen Kent > Sent: Thursday, April 01, 2004 8:03 AM > To: Bora Akyol > Cc: ipsec@lists.tislabs.com > Subject: RE: 2nd try > > > At 7:28 AM -0800 4/1/04, Bora Akyol wrote: > >Hi Steve, > > > >This looks good, one question about the fragment SA(s): > > > >If we have several "parallel" SAs to support different levels > >of QoS (for the main SAs), do we need to have the same amount > >of fragment SAs as the main ones? > > > >Thanks > > > >Bora > > Good question. In general, for approach #2, one needs only a single > SA between two implementations to carry all non-initial fragments > between them. But, if you chose to have multiple SAs between two > implementations, for QoS differentiation, then you might want > multiple SAs to carry non-initial fragments, one for each supported > QoS class. Since support for QoS via distinct SAs is a local matter, > not mandated by 2401/2401bis, this too should be a local choice. > > Steve > From owner-ipsec@lists.tislabs.com Thu Apr 1 16:27:08 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i320R7UG042319; Thu, 1 Apr 2004 16:27:07 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA03641 Thu, 1 Apr 2004 18:46:29 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <002a01c4183a$8d97eb90$422745ab@amer.cisco.com> References: <002a01c4183a$8d97eb90$422745ab@amer.cisco.com> Date: Thu, 1 Apr 2004 18:45:14 -0500 To: "Bora Akyol" From: Stephen Kent Subject: RE: 2nd try Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:42 PM -0800 4/1/04, Bora Akyol wrote: >Thanks > >Would you mind adding a single sentence to this effect >to the text when the fragment text is rolled in to make it >consistent with the main SA treatment. > >Bora > Sure. We can add a sentence noting this. Steve From owner-ipsec@lists.tislabs.com Thu Apr 1 18:16:59 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i322GwfF050679; Thu, 1 Apr 2004 18:16:59 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA14268 Thu, 1 Apr 2004 20:30:32 -0500 (EST) Message-Id: <200404020138.i321c1qd015360@rs9.luxsci.com> From: "William Dixon" To: Subject: RE: clarification on IKEv2 with EAP Date: Thu, 1 Apr 2004 20:37:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Lux-Comment: LuxSci remailer message ID code - 1080869881-509878.798428205 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Resend to the list. My apologies if this appears twice. Mail I sent hours later has appeared already on the list and this didn't. > -----Original Message----- > From: William Dixon [mailto:ietf-wd@v6security.com] > Sent: Thursday, April 01, 2004 2:54 PM > To: 'David Mariblanca (ML/EEM)'; 'Tschofenig Hannes'; > 'Pasi.Eronen@nokia.com'; 'ipsec@lists.tislabs.com' > Subject: RE: clarification on IKEv2 with EAP > > David, is your situation also one where the path of EAP > payloads originates and terminates on the same hosts that > IKEv2 ISAKMP SA does ? I'd think that many uses of EAP will > end up decapsulating it out of IKEv2 on the VPN gateway & > carrying it through Radius to the authentication server - in > which case EAP's protections are needed for its entire path. > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of David > Mariblanca > > (ML/EEM) > > Sent: Thursday, April 01, 2004 11:13 AM > > To: 'Tschofenig Hannes'; 'Pasi.Eronen@nokia.com'; > > ipsec@lists.tislabs.com > > Subject: RE: clarification on IKEv2 with EAP > > > > > > Hi, > > well, I am not specially worried about that, but rather to > implement > > extra protections when it's not needed. The EAP methods I am now > > thinking about are EAP SIM and EAP AKA, which already provide some > > protection mechanisms. If IKEv2, on top of that, gives > integrity and > > encryption to the EAP messages, maybe we will spend unnecessary > > resources when using EAP SIM/AKA over IKEv2, if we consider that > > either > > IKEv2 or EAP SIM/AKA levels of protection are secure enough. > > But I guess other EAP methods do not provide the same level of > > protection and that's why IKEv2 has to be designed in order to not > > depend on EAP implementations. > > > > In the other hand, after reading your paper (the one you > are writing > > with Pasi) I see very reasonable your proposal to omit AUTH > in message > > 4: if IKEv2 says that in messages 7 and > > 8 the AUTH payloads will protect messages 1 and 2 > (respectively), why > > to send AUTH in message 4 ? Does message > > 2 need to be authenticated twice ? > > > > Cheers, > > David. > > > > -----Original Message----- > > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > > Sent: jueves, 01 de abril de 2004 17:31 > > To: David Mariblanca (ML/EEM); 'Pasi.Eronen@nokia.com'; > > ipsec@lists.tislabs.com > > Subject: RE: clarification on IKEv2 with EAP > > > > > > hi david, > > > > i am only curious: > > why do you worry about the protection of eap messages? > > > > ciao > > hannes > > > > > > > Ok, I see. I did not remember the EAP messages were already > > integrity > > > protected and encrypted with Sk_a and Sk_e. Then the AUTH > payloads > > > protect the IKE_INIT messages, the ones which were not sent > > protected > > > since there was not key material yet to do it, correct ? > > > > > > > > > -----Original Message----- > > > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > > > Sent: jueves, 01 de abril de 2004 13:19 > > > To: David Mariblanca (ML/EEM); ipsec@lists.tislabs.com > > > Subject: RE: clarification on IKEv2 with EAP > > > > > > > > > > > > David Mariblanca wrote: > > > > > > > I will give my interpretation of chapter 16 and please > confirm if > > > > it is correct. > > > > - The EAP payloads are sent in the IKEv2 messages without AUTH > > > > payloads. The AUTH payloads are sent only in the last two IKEv2 > > > > messages, and they correspond to the last two EAP > messages, that > > > > is, AUTH in message 7 to EAP payload in message 5, and AUTH in > > > > message 8 to EAP payload in message 6 > > > > > > No, AUTH payloads do not authenticate the EAP messages, they > > > authenticate the IKEv2 SA (basically information from the > first two > > > IKEv2 messages; first paragraph of Section 2.15 explains exactly > > > what is included in the ""). > > > > > > (All EAP messages are also MAC'd with SK_ar/SK_ai, but > this is not > > > related to AUTH payloads; the integrity protection is included in > > > the "SK{...}" notation). > > > > > > Best regards, > > > Pasi > > > > > > > From owner-ipsec@lists.tislabs.com Thu Apr 1 19:11:10 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i323BAdw054335; Thu, 1 Apr 2004 19:11:10 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA19311 Thu, 1 Apr 2004 21:25:26 -0500 (EST) Message-Id: <200404020232.i322W2a6024643@rs9.luxsci.com> From: "William Dixon" To: Subject: ikev2-13 security consideration for knowing which credential to expect Date: Thu, 1 Apr 2004 21:31:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Lux-Comment: LuxSci remailer message ID code - 1080873122-1087460.61942153 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Since this security "vulnerability" has widely affected IKEv1 implementations, IKEv2 should provide a solution or at least a security consideration that provides guidance. Regarding this observation: http://www.securityfocus.org/bid/9208/info/ "The vulnerability lies in the fact that some implementations fail to thoroughly verify the authenticity of client/server certificates. Allegedly, affected implementations will verify only the Certificate Authority, not the specific certificate owner. As a result, by impersonating a server or client and sending another host a specially formatted certificate with a trusted CA, an attacker may be capable of using this attack to carry out man-in-the-middle attacks against a session carried out between a legitimate client and server." I believe they mean "trusted main-in-the-middle" attack, where the attacker has a certificate which is trusted somewhere under the CA or CA root, but is not in fact the expected machine/user certificate which the IKE initiation or response should be using for the peers expected to be negotiating. Generally - the responder is faced with a difficult situation of verifying in some automated way that the initiator should be using a particular public/private key pair or perhaps certificate credential (if cert contents matter to authorizations). Likewise, the initiator is faced with a decision of what specific key or credential/identity to expect from the responder. With additional infrastructure, (the communication to which must be equally secure as the properties which IKE seeks to achieve in using this credential), this might be possible. But I don't see an easy way to solve the problem, say for a server that may be contacted by any client in the Internet. Comments ? Thanks, Wm V6 Security, Inc. http://www.v6security.com -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQGzQZXeaysMUl8VcEQJkowCePsdSyWTyrZkBkDvl2OmlKosYTPoAnRc4 zgaE1nqxrnH5b1jJ/4MUfrf1 =KY/P -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Apr 1 20:38:24 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i324cO73060436; Thu, 1 Apr 2004 20:38:24 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA08603 Thu, 1 Apr 2004 15:01:02 -0500 (EST) Message-Id: <200404011954.i31Js1Oi003121@rs9.luxsci.com> From: "William Dixon" To: "'David Mariblanca \(ML/EEM\)'" , "'Tschofenig Hannes'" , , Subject: RE: clarification on IKEv2 with EAP Date: Thu, 1 Apr 2004 14:53:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In-Reply-To: <1AB3D30B989BF141BBD5C70057B2EF7C0476A78A@eestqnt105.es.eu.ericsson.se> X-Lux-Comment: LuxSci remailer message ID code - 1080849241-3749956.08408241 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David, is your situation also one where the path of EAP payloads originates and terminates on the same hosts that IKEv2 ISAKMP SA does ? I'd think that many uses of EAP will end up decapsulating it out of IKEv2 on the VPN gateway & carrying it through Radius to the authentication server - in which case EAP's protections are needed for its entire path. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of David > Mariblanca (ML/EEM) > Sent: Thursday, April 01, 2004 11:13 AM > To: 'Tschofenig Hannes'; 'Pasi.Eronen@nokia.com'; > ipsec@lists.tislabs.com > Subject: RE: clarification on IKEv2 with EAP > > > Hi, > well, I am not specially worried about that, but rather to > implement extra protections when it's not needed. The EAP > methods I am now thinking about are EAP SIM and EAP AKA, > which already provide some protection mechanisms. If IKEv2, > on top of that, gives integrity and encryption to the EAP > messages, maybe we will spend unnecessary resources when > using EAP SIM/AKA over IKEv2, if we consider that either > IKEv2 or EAP SIM/AKA levels of protection are secure enough. > But I guess other EAP methods do not provide the same level > of protection and that's why IKEv2 has to be designed in > order to not depend on EAP implementations. > > In the other hand, after reading your paper (the one you are > writing with Pasi) I see very reasonable your proposal to > omit AUTH in message 4: if IKEv2 says that in messages 7 and > 8 the AUTH payloads will protect messages 1 and 2 > (respectively), why to send AUTH in message 4 ? Does message > 2 need to be authenticated twice ? > > Cheers, > David. > > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: jueves, 01 de abril de 2004 17:31 > To: David Mariblanca (ML/EEM); 'Pasi.Eronen@nokia.com'; > ipsec@lists.tislabs.com > Subject: RE: clarification on IKEv2 with EAP > > > hi david, > > i am only curious: > why do you worry about the protection of eap messages? > > ciao > hannes > > > > Ok, I see. I did not remember the EAP messages were already > integrity > > protected and encrypted with Sk_a and Sk_e. Then the AUTH payloads > > protect the IKE_INIT messages, the ones which were not sent > protected > > since there was not key material yet to do it, correct ? > > > > > > -----Original Message----- > > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > > Sent: jueves, 01 de abril de 2004 13:19 > > To: David Mariblanca (ML/EEM); ipsec@lists.tislabs.com > > Subject: RE: clarification on IKEv2 with EAP > > > > > > > > David Mariblanca wrote: > > > > > I will give my interpretation of chapter 16 and please confirm > > > if it is correct. > > > - The EAP payloads are sent in the IKEv2 messages without > > > AUTH payloads. The AUTH payloads are sent only in the last > > > two IKEv2 messages, and they correspond to the last two EAP > > > messages, that is, AUTH in message 7 to EAP payload in > > > message 5, and AUTH in message 8 to EAP payload in message 6 > > > > No, AUTH payloads do not authenticate the EAP messages, they > > authenticate the IKEv2 SA (basically information from the > > first two IKEv2 messages; first paragraph of Section 2.15 > > explains exactly what is included in the ""). > > > > (All EAP messages are also MAC'd with SK_ar/SK_ai, but this is > > not related to AUTH payloads; the integrity protection is > > included in the "SK{...}" notation). > > > > Best regards, > > Pasi > > > > From owner-ipsec@lists.tislabs.com Thu Apr 1 20:43:00 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i324gx8C060757; Thu, 1 Apr 2004 20:43:00 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA00928 Thu, 1 Apr 2004 23:04:02 -0500 (EST) Message-Id: <200404020412.i324C2rf008934@rs9.luxsci.com> From: "William Dixon" To: Subject: ikev2-13 section 1.1.2 end-to-end diagram says "tunnel" add reference to RFC 1958, 2775, etc Date: Thu, 1 Apr 2004 23:11:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Lux-Comment: LuxSci remailer message ID code - 1080879122-8271018.26918976 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 While end-to-end tunnel mode is certainly still allowed, this diagram is inconsistent with the section heading. It should say "IPsec tunnel mode or IPsec transport mode", not just "IPsec tunnel". Yes, I clearly see the text explains. But you probably wouldn't believe the confusion in the customer base who don't get "transport mode", and if they don't see it in the picture, they think and say and then can't stop saying "tunnel" even if they mean transport. Further, I'd like to see consistency with terminology and a reference that this protocol in this scenario enabling the end-to-end security vision for the Internet discussed in IAB informational RFCs 1958 and 2775 (ftp://ftp.rfc-editor.org/in-notes/rfc2775.txt). Current text: 1.1.2 Endpoint to Endpoint Transport +-+-+-+-+-+ +-+-+-+-+-+ ! ! IPsec ! ! !Protected! Tunnel !Protected! !Endpoint !<---------------------------------------->!Endpoint ! ! ! ! ! +-+-+-+-+-+ +-+-+-+-+-+ Figure 2: Endpoint to Endpoint In this scenario, both endpoints of the IP connection implement IPsec. These endpoints may implement application layer access controls based on the authenticated identities of the participants. Transport mode will commonly be used with no inner IP header. If there is an inner IP header, the inner addresses will be the same as the outer addresses. A single pair of addresses will be negotiated for packets to be protected by this SA. Suggested replacement text: 1.1.2 Endpoint to Endpoint Transport +-+-+-+-+-+ +-+-+-+-+-+ ! ! IPsec transport ! ! !Protected! or tunnel mode SA !Protected! !Endpoint !<---------------------------------------->!Endpoint ! ! ! ! ! +-+-+-+-+-+ +-+-+-+-+-+ Figure 2: Endpoint to Endpoint In this scenario, both endpoints of the IP connection implement IPsec, as required of hosts in [RFC 2401]. Transport mode will commonly be used with no inner IP header. If there is an inner IP header, the inner addresses will be the same as the outer addresses. A single pair of addresses will be negotiated for packets to be protected by this SA. These endpoints may implement application layer access controls based on the IPsec authenticated identities of the participants. This scenario enables the end-to-end security that has been a guiding principle for the Internet since [RFC 1958], [RFC2 775], and a method of limiting the inherent problems with complexity in networks noted by [RFC 3439]. While this scenario may not be fully applicable to the IPv4 Internet, it has been deployed with successfully in specific scenarios within intranets using IKEv1. It should be more broadly enabled during the transition to IPv6 and with the adoption of IKEv2. Adding references: [RFC 1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996. [RFC 2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000. [RFC 3439] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines and Philosophy", RFC 3429, December 2002. Thanks, Wm V6 Security, Inc. http://www.v6security.com -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQGzn/3eaysMUl8VcEQKobgCg7CU4DmNccm/Veq/UGWEt83Xsct0AoLZL CenvU1BvhbN10Mrd/7uP+CRP =HlIu -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Apr 1 21:49:52 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i325np9V065117; Thu, 1 Apr 2004 21:49:51 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA09144 Fri, 2 Apr 2004 00:05:43 -0500 (EST) Message-ID: <49977.217.132.134.217.1080886563.squirrel@sslvpn.checkpoint.com> Date: Fri, 2 Apr 2004 06:16:03 -0000 (UTC) Subject: Question about reauthentication From: "Yoav Nir" To: ipsec@lists.tislabs.com Reply-To: ynir@checkpoint.com User-Agent: WebMail Portal/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all. With some IKE scenarios, especially with remote access, people have a need for the IKE peer to authenticate periodically. This is meant to prevent a case where the user left his computer (or, say, his seat in the Internet cafe) and now anybody can use the open VPN tunnel. We want the user to enter their credentials again. In IKEv1 we would just require the user to run Phase1 again, expiring the IKE SA every 1-2 hours. What would be the proper way in IKEv2? One solution would be to require the whole initial exchange again. This is consistent with the IKEv1 solution, but it unnecessarity ties re-keying with re-authentication. It is also not the proper way to re-key in IKEv2. Another solution would be to have the client do a stand-alone AUTH exchange. This does not generate keys, and is shorter. The problem is what do we sign in this AUTH exchange? Is it message 2 of the original INITIAL exchange? Do we need to keep in indefinitely? It is feasible, but slightly weird. Any other ideas? From owner-ipsec@lists.tislabs.com Thu Apr 1 22:49:43 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i326ng0e089635; Thu, 1 Apr 2004 22:49:42 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA15413 Fri, 2 Apr 2004 01:09:28 -0500 (EST) Message-Id: <200404020620.i326K2Lm028879@rs9.luxsci.com> From: "William Dixon" To: Subject: ikev2-13 CERTREQ processing still needs work Date: Fri, 2 Apr 2004 01:19:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Lux-Comment: LuxSci remailer message ID code - 1080886802-7954335.86621718 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There are two problems described in this mail: 1. security problem. The current text wording "MUST" allows a malicious responder to "bleed" certs from the initiator by including many CERTREQ payloads or different CERTREQ payloads. This should not be allowed. 2. operational problem or rather an IKE interop problem with properly deployed PKIs. The current text "MUST" does not support successful negotiation under a variety of PKI trust topologies and policy systems, namely those involving cross-certification, and where certificate types are needed to authorize or will successfully chain only for specific purposes. I think the intent though is to support cases where authentication can succeed if possible. Current Text: "If a certificate exists which satisfies the criteria specified in the Certificate Request Payload, the certificate MUST be sent back to the certificate requestor. If no certificates exist then the Certificate Request Payload is ignored. This is not an error condition of the protocol. There may be cases where there is a preferred CA, but an alternate might be acceptable (perhaps after prompting a human operator)." Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] 1. Security: Clearly the initiator is disadvantaged by the current MUST which requires it to provide any cert the unauthenticated responder requests. The initiator's local policy governing the initiation, if specified, should be considered authoritative for what certs can be provided, not the CERTREQ. For example, why should a web search site be able to get my bank certificate ? 2. Operationally, requesting the right thing (what to accept) and selecting the right thing (what to offer) are independent decisions and necessarily complicated because PKI is complicated. They are independent because PKI trust may be deployed to succeed in one direction (I trust you) and fail in the other (you don't trust me), or to be broad in one direction (I trust many) and narrow in the other (I only trust a few). In fact, the CERTREQ payload definition itself needs to be changed to allow it to be more specific in what it can request. Why should you fail a negotiation when there exist certs that you could have selected if you only knew to look for those types ? If we ignore this issue, vendors will both have problems with RFC compliant interop (or solve it with vendor ID enabled behaviors), and limit the compatible PKI topologies and cert types useful for IKEv2. My experience says that customers will not re-architect their PKIs just to accommodate a short-sighted specification of cert processing in IKE. Their PKIs are already used for many other purposes. Vendors will have to make the changes in their IKE products to accommodate full and proper PKIX PKI deployments at their customers, as well as probably deal with inappropriately deployed PKIs. But we can't do much about the latter. This current text below is a recipe for more cert interop nightmares for vendors who want to support the new cert types: "values other than certificates are defined in a "Certificate" payload and requests for those values can be present in a Certificate Request Payload. The syntax of the Certificate Request payload in such cases is not defined in this document" Assuming there were really good reasons to include those cert types, let's not make it any harder to use them. Proposed text, fixing security and operation problems above: "If an end-entity certificate exists which satisfies the criteria specified in the CERTREQ, a certificate or certificate chain SHOULD be sent back to the certificate requestor if: - - the recipient of the CRP is configured to use certificate authentication, and - - the recipient is allowed to send a CERT payload, and - - the recipient has matching CA trust policy governing the current negotiation, and - - has at least one time-wise and usage appropriate end-entity certificate chaining to a CA provided in the CERTREQ. Certificate revocation checking must be considered during the chaining process used to select a certificate. Note that even if two peers are configured to use two different CAs, cross-certification relationships should be supported by appropriate selection logic. The intent is not to prevent communication through the strict adherence of selection of a certificate based on CERTREQ, when an alternate certificate could be selected by the sender which would still enable the recipient to successfully validate and trust it through trust conveyed by cross-certification, CTLs or other out-of-band configured means. Thus the processing of a CERTREQ CA name should be seen as a suggestion for a certificate to select, not a mandated one. If no certificates exist then the CERTREQ is ignored. This is not an error condition of the protocol. There may be cases where there is a preferred CA sent in the CERTREQ, but an alternate might be acceptable (perhaps after prompting a human operator)." More generally, the Security Considerations section needs to address what the malicious initiator can discover about the responder. Likewise, what a malicious responder can discover about the initiator. The specification of how to construct a CERTREQ for each of the supported cert types needs to be done. I'll save space here and not do it. As a detailed reference, see the implemented behavior of Windows Server 2003 certificate selection and acceptance logic found in section "General certificate authentication considerations" in Chapter 6 Deploying IPsec of the Windows Server 2003 Deployment Kit: http://www.microsoft.com/downloads/details.aspx?FamilyID=d91065ee-e618 - -4810-a036-de633f79872e cheers, Wm V6 Security, Inc. http://www.v6security.com This message is provided "AS IS" without any warranty express or implied as to it's accuracy or fitness for a particular purpose. -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQG0F1XeaysMUl8VcEQJIHQCg0WJeiMD8bJlGXEJXV+u66wGKEy4AnArA KWIGYi772QaSu6AObGRUsUl9 =jhBh -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Apr 2 01:11:07 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i329B6Ff038491; Fri, 2 Apr 2004 01:11:07 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA29009 Fri, 2 Apr 2004 03:29:17 -0500 (EST) Message-ID: <1AB3D30B989BF141BBD5C70057B2EF7C0476A78D@eestqnt105.es.eu.ericsson.se> X-Sybari-Trust: 9771f496 2c4885b5 7a61c793 00000138 From: "David Mariblanca (ML/EEM)" To: "'William Dixon'" , "'Tschofenig Hannes'" , Pasi.Eronen@nokia.com, ipsec@lists.tislabs.com Subject: RE: clarification on IKEv2 with EAP Date: Fri, 2 Apr 2004 10:40:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 02 Apr 2004 08:41:43.0794 (UTC) FILETIME=[5376E520:01C4188E] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk No, it is the common situation you point out, the EAP messages terminate in a different host that the IKEv2 ones (although they are originated in the same host). But the EAP messages, as these EAP methods have own protection mechanisms, will be protected in the entire path anyway. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of William Dixon Sent: jueves, 01 de abril de 2004 21:54 To: David Mariblanca (ML/EEM); 'Tschofenig Hannes'; Pasi.Eronen@nokia.com; ipsec@lists.tislabs.com Subject: RE: clarification on IKEv2 with EAP David, is your situation also one where the path of EAP payloads originates and terminates on the same hosts that IKEv2 ISAKMP SA does ? I'd think that many uses of EAP will end up decapsulating it out of IKEv2 on the VPN gateway & carrying it through Radius to the authentication server - in which case EAP's protections are needed for its entire path. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of David > Mariblanca (ML/EEM) > Sent: Thursday, April 01, 2004 11:13 AM > To: 'Tschofenig Hannes'; 'Pasi.Eronen@nokia.com'; > ipsec@lists.tislabs.com > Subject: RE: clarification on IKEv2 with EAP > > > Hi, > well, I am not specially worried about that, but rather to > implement extra protections when it's not needed. The EAP > methods I am now thinking about are EAP SIM and EAP AKA, > which already provide some protection mechanisms. If IKEv2, > on top of that, gives integrity and encryption to the EAP > messages, maybe we will spend unnecessary resources when > using EAP SIM/AKA over IKEv2, if we consider that either > IKEv2 or EAP SIM/AKA levels of protection are secure enough. > But I guess other EAP methods do not provide the same level > of protection and that's why IKEv2 has to be designed in > order to not depend on EAP implementations. > > In the other hand, after reading your paper (the one you are > writing with Pasi) I see very reasonable your proposal to > omit AUTH in message 4: if IKEv2 says that in messages 7 and > 8 the AUTH payloads will protect messages 1 and 2 > (respectively), why to send AUTH in message 4 ? Does message > 2 need to be authenticated twice ? > > Cheers, > David. > > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: jueves, 01 de abril de 2004 17:31 > To: David Mariblanca (ML/EEM); 'Pasi.Eronen@nokia.com'; > ipsec@lists.tislabs.com > Subject: RE: clarification on IKEv2 with EAP > > > hi david, > > i am only curious: > why do you worry about the protection of eap messages? > > ciao > hannes > > > > Ok, I see. I did not remember the EAP messages were already > integrity > > protected and encrypted with Sk_a and Sk_e. Then the AUTH payloads > > protect the IKE_INIT messages, the ones which were not sent > protected > > since there was not key material yet to do it, correct ? > > > > > > -----Original Message----- > > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > > Sent: jueves, 01 de abril de 2004 13:19 > > To: David Mariblanca (ML/EEM); ipsec@lists.tislabs.com > > Subject: RE: clarification on IKEv2 with EAP > > > > > > > > David Mariblanca wrote: > > > > > I will give my interpretation of chapter 16 and please confirm > > > if it is correct. > > > - The EAP payloads are sent in the IKEv2 messages without > > > AUTH payloads. The AUTH payloads are sent only in the last > > > two IKEv2 messages, and they correspond to the last two EAP > > > messages, that is, AUTH in message 7 to EAP payload in > > > message 5, and AUTH in message 8 to EAP payload in message 6 > > > > No, AUTH payloads do not authenticate the EAP messages, they > > authenticate the IKEv2 SA (basically information from the > > first two IKEv2 messages; first paragraph of Section 2.15 > > explains exactly what is included in the ""). > > > > (All EAP messages are also MAC'd with SK_ar/SK_ai, but this is > > not related to AUTH payloads; the integrity protection is > > included in the "SK{...}" notation). > > > > Best regards, > > Pasi > > > > From owner-ipsec@lists.tislabs.com Fri Apr 2 01:20:39 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i329Kcgm042163; Fri, 2 Apr 2004 01:20:38 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA29900 Fri, 2 Apr 2004 03:42:41 -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: <16493.10872.196792.111195@fireball.acr.fi> Date: Fri, 2 Apr 2004 11:55:20 +0300 From: Tero Kivinen To: Stephen Kent Cc: "Mohan Parthasarathy" , Subject: Re: 2nd try In-Reply-To: References: <16480.15529.482315.278735@fireball.acr.fi> <016c01c416c3$eb1d8270$861167c0@adithya> <16492.6896.588750.18184@fireball.acr.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 19 min X-Total-Time: 18 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > >I think we should select the most secure protocol (i.e. case #3) as > >MUST, and allow #2 protocol for high-speed implementations as MAY. > #2 and #3 are equally secure in terms of IPv4. No they aren't equally secure. If the policy is "allow only SMTP traffic go through", then using #2 will still allow any fragments go through. I do think two setups are equally secure if the other setup allows packets which should not go through to go through. It does not matter, that the final recipient will then throw those packets away later, the packets did go through the VPN link. The difference in the secrity might not be that big, but it is there. It for example offers very good covert channel through the vpn, and after seen "IP over DNS", I think it does not take a long when someone creates "IP over non-first fragments" protocol to get around the restrictions in the VPN. Or someone creates peer-to-peer program that runs on non-first fragments only just to get it working also through VPNs which only allow SMTP traffic or similar. > As Paul noted, it is a lot more difficult in hardware, especially at > very high speeds. My experience in designing such devices convinces I am not hardware person, so I cannot really comment on that, but seeing what else they are currently doing on the hardware I do think it is actually very easy to do on the hardware too (compared to the other things they do there). One easy solution is to put the ARM core or similar processor inside the hardware, add do it partly on software. > me of that fact, as much as your experience in developing software > has convinced you that it is not too complex in that context. (BTW, > was this software for an end systems or an SG?) Our code is used for all possible cases, i.e. both in end system and SGW, regardless whether the IPsec is inside the IP-stack (BITS), or below it, or on the media level (BITW). It can also do full reassembly on the systems where we get fragmented packets from the IP-stack and we need to stuff them to transport mode SA etc. > How about a compromise? We could make #2 a MAY and #3 a SHOULD. A > SHOULD is almost a MUST, with a loophole as noted below (from RFC > 2119): That would be accectable for me. > This would allow a hardware implementation to not support #3, if > doing so would adversely impact overall performance. Ok. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Fri Apr 2 02:02:39 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32A2caI058288; Fri, 2 Apr 2004 02:02:38 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA03645 Fri, 2 Apr 2004 04:24:37 -0500 (EST) Message-ID: <1AB3D30B989BF141BBD5C70057B2EF7C0476A78F@eestqnt105.es.eu.ericsson.se> X-Sybari-Trust: bd35aea7 2c4885b5 7a61c793 00000138 From: "David Mariblanca (ML/EEM)" To: "'Pasi.Eronen@nokia.com'" , ipsec@lists.tislabs.com Subject: RE: clarification on IKEv2 with EAP Date: Fri, 2 Apr 2004 11:33:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 02 Apr 2004 09:35:01.0793 (UTC) FILETIME=[C59ED110:01C41895] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id EAA03640 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Good, thanks. Then how is the key pad obtained, if there is no user interaction (no password or string entered) ? Can it be a predefined string in the initiator and in the responder ? -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: jueves, 01 de abril de 2004 13:09 To: David Mariblanca (ML/EEM); ipsec@lists.tislabs.com Subject: RE: clarification on IKEv2 with EAP Hi, The "Key Pad for IKEv2" part is always included, even if the shared secret is not actually a password entered by the user. AUTH payloads are also always included (the EAP message authentication protects only EAP messages; the AUTH part is needed to authenticate the IKEv2 exchange). Best regards, Pasi > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of ext David > Mariblanca > (ML/EEM) > Sent: Thursday, April 01, 2004 12:34 PM > To: 'Tschofenig Hannes'; 'ipsec@lists.tislabs.com' > Subject: RE: clarification on IKEv2 with EAP > > > > > Hi again, > I would like to raise other questions: > - When generating the AUTH, one input is the "Key Pad for > IKEv2", which is supposed to be used in password based > authentications, correct ? What happens when the user > authentication is not based in passwords ? In that case, can > this string be omitted as input to the prf, or can be > assigned a fixed value instead ? > - If the EAP method being used already provides a message > authentication mechanism, does the AUTH have to be computed > anyway ? Or only in the cases where the EAP message is not > protected by itself, the AUTH has to be used ? > > Thanks for your time, but I foresee I may come back again > with more questions... > Cheers, > David. > > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: miércoles, 31 de marzo de 2004 14:07 > To: David Mariblanca (ML/EEM); 'ipsec@lists.tislabs.com' > Subject: RE: clarification on IKEv2 with EAP > > > hi david, > > the AUTH payload in message 4 (from the responder to the > initiator) is not > based on the keying material of an eap method authentication and key > exchange run. hence, it most likely uses public key based > authentication. > > ciao > hannes > > > > -----Original Message----- > > From: David Mariblanca (ML/EEM) > [mailto:david.mariblanca@ericsson.com] > > Sent: Wednesday, March 31, 2004 12:37 PM > > To: 'ipsec@lists.tislabs.com' > > Subject: clarification on IKEv2 with EAP > > > > > > > > Hi, > > I am reading the IKEv2 i-d and I have a question in chapter > > 2.16, about the usage of EAP methods over IKEv2. > > The sequence diagram with the process is the following > > (copied from the paper): > > > > Initiator Responder > > ----------- ----------- > > HDR, SAi1, KEi, Ni --> > > > > <-- HDR, SAr1, KEr, > Nr, [CERTREQ] > > > > HDR, SK {IDi, [CERTREQ,] [IDr,] > > SAi2, TSi, TSr} --> > > > > <-- HDR, SK {IDr, [CERT,] AUTH, > > EAP } > > > > HDR, SK {EAP, AUTH} --> > > > > <-- HDR, SK {EAP, AUTH, > > SAr2, TSi, TSr } > > > > > > As written in the paper, the initiator omits the AUTH payload > > in message 3 when it wants to use EAP. Later on, it is > > written that when the whole EAP message is finished, the > > resultant shared secret (if exists) is used to generate the > > AUTH in messages 5 and 6. My question is: what about AUTH in > > message 4 ? How is it generated ? > > > > Thanks and best regards, > > David. > > > > > From owner-ipsec@lists.tislabs.com Fri Apr 2 02:30:16 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32AUF46062264; Fri, 2 Apr 2004 02:30:15 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA06231 Fri, 2 Apr 2004 04:50:44 -0500 (EST) From: Pasi.Eronen@nokia.com X-Scanned: Fri, 2 Apr 2004 13:04:34 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: clarification on IKEv2 with EAP Date: Fri, 2 Apr 2004 13:01:20 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C3A19@esebe023.ntc.nokia.com> Thread-Topic: clarification on IKEv2 with EAP Thread-Index: AcQYltXItKTpM5TASDCFsrsvWYlHZQAAbZjA To: , X-OriginalArrivalTime: 02 Apr 2004 10:01:21.0227 (UTC) FILETIME=[730951B0:01C41899] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id EAA06224 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David Mariblanca wrote: > > Good, thanks. > Then how is the key pad obtained, if there is no user > interaction (no password or string entered) ? Can it be a > predefined string in the initiator and in the responder ? The key pad is always a predefined string (17 bytes, 0x4b (K) 0x65 (e) 0x79 (y) 0x20 (space) and so on). The user-entered string (if any) is the shared secret. Best regards, Pasi From owner-ipsec@lists.tislabs.com Fri Apr 2 05:16:24 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32DGNAq074118; Fri, 2 Apr 2004 05:16:23 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA22205 Fri, 2 Apr 2004 07:32:38 -0500 (EST) Message-ID: <1AB3D30B989BF141BBD5C70057B2EF7C0476A790@eestqnt105.es.eu.ericsson.se> X-Sybari-Trust: 33bce65b 2c4885b5 7a61c793 00000138 From: "David Mariblanca (ML/EEM)" To: "'Pasi.Eronen@nokia.com'" , ipsec@lists.tislabs.com Subject: RE: clarification on IKEv2 with EAP Date: Fri, 2 Apr 2004 14:44:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 02 Apr 2004 12:45:27.0227 (UTC) FILETIME=[5FB5B0B0:01C418B0] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I hadn't understood that was the string itself. Actually I thought the opposite, the shared secret could be something predefined in the initiator and responder, and the key pad something changeable. Thank you. The clarifications you are providing me are very useful. -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: viernes, 02 de abril de 2004 12:01 To: David Mariblanca (ML/EEM); ipsec@lists.tislabs.com Subject: RE: clarification on IKEv2 with EAP David Mariblanca wrote: > > Good, thanks. > Then how is the key pad obtained, if there is no user > interaction (no password or string entered) ? Can it be a > predefined string in the initiator and in the responder ? The key pad is always a predefined string (17 bytes, 0x4b (K) 0x65 (e) 0x79 (y) 0x20 (space) and so on). The user-entered string (if any) is the shared secret. Best regards, Pasi From owner-ipsec@lists.tislabs.com Fri Apr 2 06:51:14 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32EpDT2080768; Fri, 2 Apr 2004 06:51:13 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00772 Fri, 2 Apr 2004 09:05:34 -0500 (EST) Message-ID: <406D7546.9040800@kolumbus.fi> Date: Fri, 02 Apr 2004 17:14:30 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Cc: Tero Kivinen , Charlie Kaufman , Yoav Nir , Pasi Eronen , Hannes Tschofenig , Joe Salowey , Yoshihiro Ohba Subject: Re: EAP Roundtrips (was: Temporary version of the new IKEv2 draft) References: <16482.57692.830072.313565@fireball.acr.fi> In-Reply-To: <16482.57692.830072.313565@fireball.acr.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This e-mail tries to summarize the discussions we had on the EAP WG mailing list and (mostly) privately between the some of the EAP state machine and methods folks. Yoshihiro, Pasi, Joe, Hannes -- feel free to add or correct as appropriate. The question was whether one roundtrip should be eliminated from IKEv2, by making it possible (but optional) to send an AUTH payload from the client as soon as the client has generated a key from EAP, and not wait until EAP Success packet has been received from the gateway. No strong opinions were presented, but the consensus we seem to have arrived at is that its simpler and better to spend the extra roundtrip than to add a protocol variation, a change of EAP state machine draft, and possibly some EAP method and API implementation changes for systems that want to take advantage of this. The following points were brought up: o Yoshihiro analyzed the potential impacts of the EAP state machine change for 802.11 wireless LANs which also use EAP. It was found that the change would NOT have an impact in 802.11, i.e., from that point of view the change is possible. o EAP in general is able to survive the loss of the EAP Success message (which is not retransmitted). o OTOH, there is a need to define "when key is available" precisely. Some EAP methods might have a key available before the endpoints have authenticated each other, for instance. EAP base specification sets requirements for EAP methods, but it does not talk about what methods definitions should say about the matter. Many methods have already been defined; this might lead to different interpretations in different implementations. o Joe brought up the possibility of EAP methods where the client does not know whether the server is yet finished; if the client would send an AUTH payload when its done the server might still have to perform roundtrips. This would have to be taken in account in the IKEv2 spec. o Number of roundtrips is a concern for many people. But Tero's and Charlie's worry about protocol variants is also a concern, as is the need to ensure that the early key availability suits the particular EAP method. --Jari From owner-ipsec@lists.tislabs.com Fri Apr 2 07:28:58 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32FSv1F083015; Fri, 2 Apr 2004 07:28:57 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04570 Fri, 2 Apr 2004 09:52:11 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16493.10872.196792.111195@fireball.acr.fi> References: <16480.15529.482315.278735@fireball.acr.fi> <016c01c416c3$eb1d8270$861167c0@adithya> <16492.6896.588750.18184@fireball.acr.fi> <16493.10872.196792.111195@fireball.acr.fi> Date: Fri, 2 Apr 2004 09:55:07 -0500 To: Tero Kivinen From: Stephen Kent Subject: Re: 2nd try Cc: "Mohan Parthasarathy" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero, I was responding to your message point by point, disagreeing in several cases, but let's skip to the end: > > How about a compromise? We could make #2 a MAY and #3 a SHOULD. A >> SHOULD is almost a MUST, with a loophole as noted below (from RFC >> 2119): > >That would be accectable for me. > >> This would allow a hardware implementation to not support #3, if >> doing so would adversely impact overall performance. > >Ok. Well, since we agree on a solution, let's not argue about the rationale :-) Steve From owner-ipsec@lists.tislabs.com Fri Apr 2 07:54:29 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32FsSMV084125; Fri, 2 Apr 2004 07:54:28 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05933 Fri, 2 Apr 2004 10:11:06 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16493.34161.585000.324624@gargle.gargle.HOWL> Date: Fri, 2 Apr 2004 10:23:29 -0500 From: Paul Koning To: kivinen@iki.fi Cc: kent@bbn.com, mohanp@sbcglobal.net, ipsec@lists.tislabs.com Subject: Re: 2nd try References: <16480.15529.482315.278735@fireball.acr.fi> <016c01c416c3$eb1d8270$861167c0@adithya> <16492.6896.588750.18184@fireball.acr.fi> <16493.10872.196792.111195@fireball.acr.fi> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Tero" == Tero Kivinen writes: >> As Paul noted, it is a lot more difficult in hardware, especially >> at very high speeds. My experience in designing such devices >> convinces Tero> I am not hardware person, so I cannot really comment on that, Tero> but seeing what else they are currently doing on the hardware I Tero> do think it is actually very easy to do on the hardware too Tero> (compared to the other things they do there). One easy solution Tero> is to put the ARM core or similar processor inside the Tero> hardware, add do it partly on software. You're missing the point. The issue isn't just logic complexity, but logic complexity is still a concern. It's true that current hardware does a lot of stuff, and the incremental logic complexity may not be all that large. Then again, in software, fixing a bug takes a few minutes. In hardware, it takes at least a few weeks and possibly several months, not to mention as much as several hundred thousand dollars. Because of this, hardware designers are MUCH more concerned about extraneous complexity than software designers are. (Arguably, software designers could benefit from adopting some of that attitude -- the software products would be more reliable if that were done. But that's a different subject...) The other issues are things like buffering requirements, state storage requirements, additional bandwidth demand on various buses, the need to implement timeout mechanisms, etc. If you need to keep more state, you have to store that somewhere. You may find yourself forced to switch from on-chip state storage to off-chip storage. That's a very expensive change, because low latency off-chip storage access is hard to do -- especially as SRAM is becoming more and more rare. You may find that you need more bus bandwidth on various data paths. If those are memory data paths to external memory, you may have to use more expensive memory than before, or wider memory. Putting a CPU core in the hardware isn't a solution. For one thing, that's a software solution. If the performance requirement is high enough, a software solution doesn't do the job. Putting software on-chip doesn't change that very much. The other issue is that hooking a software engine into a state machine (hardwired logic) fastpath is a very nontrivial exercise. It's already non-trivial to do things like divert IKE traffic to on-chip CPUs -- but that's far easier than putting IPsec fast path processing partly in software. paul From owner-ipsec@lists.tislabs.com Fri Apr 2 10:03:43 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32I3gDw092855; Fri, 2 Apr 2004 10:03:42 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i32GhT713726 for ipsec-outgoing; Fri, 2 Apr 2004 11:43:29 -0500 (EST) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5B182BAC-84C6-11D8-B166-000393101764@tislabs.com> Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com, skent@bbn.com, clynn@bbn.com, Russ Mundy From: John Kelley Subject: Re: mail list blocked Date: Fri, 2 Apr 2004 11:54:07 -0500 To: Karen Seo X-Mailer: Apple Mail (2.612) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk An update... the mail server on lists.tislabs.com has been upgraded and manual testing done here has confirmed that the esoteric form of open relay that was reported to ORDB has been fixed. Now, we just await ORDB to test and remove this server from their database. Reading their test submission page closer, this can take up to 72 hours. -John On Apr 1, 2004, at 4:52 PM, Karen Seo wrote: > Hello, > > In case you've been waiting for a reply from BBN... Since mid-Friday > (3/26), we haven't received any mail that was addressed ONLY to the > IPsec mailing list. We just found out that lists.tislabs.com has been > added to the Open Relay database, and BBN's mailers block mail from > hosts in that database. So if you sent mail to a BBNer and didn't > specifically address it to him/her, it wouldn't have gotten through. > The tislabs folks are working on fixing the problem, but it could be > many hours before ORDB.ORG removes them from their database. > > Karen > > -- John Kelley Development Engineer Sparta, Inc. Columbia, MD 410.872.1515 x219 410.872.8079 FAX From owner-ipsec@lists.tislabs.com Fri Apr 2 10:17:35 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32IHYRJ094438; Fri, 2 Apr 2004 10:17:35 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i32GxoU14929 for ipsec-outgoing; Fri, 2 Apr 2004 11:59:50 -0500 (EST) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200404012208.i31M806t008846@rs9.luxsci.com> References: <200404012208.i31M806t008846@rs9.luxsci.com> Date: Fri, 2 Apr 2004 12:11:50 -0500 To: "William Dixon" From: Stephen Kent Subject: RE: Issue 83 will be withdrawn 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 5:06 PM -0500 4/1/04, William Dixon wrote: >This concerns me greatly. It was originally a "MUST FIX". Steve, can we have >an explanation of why this was withdrawn and what mechanisms should be used >instead ? I don't see solutions in Issue 91 to compensate. There was extensive discussion of this issue, mostly involving Tero and me, in February. The concerns I cited were that - this would impose a significant burden on a receiver who would now have to check to determine if a packet that was dropped would have been OK f the packet were received on an SA. note that, as stated, the check would have to be conducted even if there was an explicit SPD entry calling for the packet to be dropped. one wants an efficient means of discarding inbound packets that are not IPsec and not to be bypassed, and this makes such processing hard (or at least harder). Tero suggested that one might add another SPD field to allow an admin to decide whether sending an ICMP was appropriate, when a packet matched an SPD-I drop entry, but no detailed proposal for doing this was developed. - it also adds complexity, because one should offer rate limiting for responses, e.g., to prevent an attacker from using this feature to cause a receiver to send ICMP traffic to sites because the source address of the packet that triggers the ICMP was spoofed. Tero and I disagreed over the tradeoff re the added complexity vs. the benefit that accrues for debugging when one site is sending traffic to another, in the clear, due to SPD mismatches, something that the sending of an ICMP might help detect. I think it fair to say that this issue hinges on a value judgement, i.e., is the benefit of alerting a peer to this reason for discarding the peer's unprotected traffic worth the added complexity required to prevent this feature from creating performance problems and DoS problems. >What was the TCP/IP or IPsec deployment purpose of those ICMP codes ? These code already exist; they are not new. they are appropriate responses, in general, to alert a sender to the fact that traffic is being discarded due to security restrictions. the issue was whether we should send such messages under these circumstances. Steve From owner-ipsec@lists.tislabs.com Fri Apr 2 12:45:33 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32KjVGa007477; Fri, 2 Apr 2004 12:45:33 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i32JZlj01369 for ipsec-outgoing; Fri, 2 Apr 2004 14:35:47 -0500 (EST) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Message-Id: <200404021944.i32Ji1xA027106@rs9.luxsci.com> From: "William Dixon" To: "'Stephen Kent'" Cc: Subject: RE: Issue 83 will be withdrawn Date: Fri, 2 Apr 2004 14:42:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: X-Lux-Comment: LuxSci remailer message ID code - 1080935041-8383989.78399757 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If these codes are already defined, how were hosts envisioned to handle the notification that traffic was being dropped for security reasons ? Certainly sending hosts pay attention to the receipt of ICMP dest/port unreachables. > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Friday, April 02, 2004 12:12 PM > To: William Dixon > Cc: ipsec@lists.tislabs.com > Subject: RE: Issue 83 will be withdrawn > > At 5:06 PM -0500 4/1/04, William Dixon wrote: > >This concerns me greatly. It was originally a "MUST FIX". > Steve, can we > >have an explanation of why this was withdrawn and what mechanisms > >should be used instead ? I don't see solutions in Issue 91 > to compensate. > > There was extensive discussion of this issue, mostly > involving Tero and me, in February. The concerns I cited were that > > - this would impose a significant burden on a receiver > who would now have to check to determine if a packet that was > dropped would have been OK f the packet were received on an > SA. note that, as stated, the check would have to be > conducted even if there was an explicit SPD entry calling for > the packet to be dropped. one wants an efficient means of > discarding inbound packets that are not IPsec and not to be > bypassed, and this makes such processing hard (or at least > harder). Tero suggested that one might add another SPD field > to allow an admin to decide whether sending an ICMP was > appropriate, when a packet matched an SPD-I drop entry, but > no detailed proposal for doing this was developed. > > - it also adds complexity, because one should offer > rate limiting for responses, e.g., to prevent an attacker > from using this feature to cause a receiver to send ICMP > traffic to sites because the source address of the packet > that triggers the ICMP was spoofed. Tero and I disagreed over > the tradeoff re the added complexity vs. the benefit that > accrues for debugging when one site is sending traffic to > another, in the clear, due to SPD mismatches, something that > the sending of an ICMP might help detect. > > I think it fair to say that this issue hinges on a value > judgement, i.e., is the benefit of alerting a peer to this > reason for discarding the peer's unprotected traffic worth > the added complexity required to prevent this feature from > creating performance problems and DoS problems. > > > >What was the TCP/IP or IPsec deployment purpose of those ICMP codes ? > > These code already exist; they are not new. they are > appropriate responses, in general, to alert a sender to the > fact that traffic is being discarded due to security > restrictions. the issue was whether we should send such > messages under these circumstances. > > Steve > > From owner-ipsec@lists.tislabs.com Fri Apr 2 13:24:13 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i32LOD5V011185; Fri, 2 Apr 2004 13:24:13 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i32KI3o08178 for ipsec-outgoing; Fri, 2 Apr 2004 15:18:03 -0500 (EST) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200404021944.i32Ji1xA027106@rs9.luxsci.com> References: <200404021944.i32Ji1xA027106@rs9.luxsci.com> Date: Fri, 2 Apr 2004 15:29:42 -0500 To: "William Dixon" From: Stephen Kent Subject: RE: Issue 83 will be withdrawn 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 2:42 PM -0500 4/2/04, William Dixon wrote: >If these codes are already defined, how were hosts envisioned to handle the >notification that traffic was being dropped for security reasons ? Certainly >sending hosts pay attention to the receipt of ICMP dest/port unreachables. > Willian, The codes were defined over 20 years ago; I asked Jon Postel for them when I was working on IP layer crypto devices analogous to IPsec security gateways and we wanted to inform a host that packets were dropped because of access controls. we wanted to let the sender know that this was not a temporary transmission problem, and it would not be fixed unless the access controls were fixed. the fact that most hosts don't provide useful feedback to user or apps based on the type and codes is a separate problem. steve From owner-ipsec@lists.tislabs.com Mon Apr 5 10:45:45 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35HjiCD094921; Mon, 5 Apr 2004 10:45:45 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i35GS7m01799 for ipsec-outgoing; Mon, 5 Apr 2004 12:28:07 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Importance: Low Subject: Re: IDci and IDcr payloads with NAT Traversal To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: David Wierbowski Date: Mon, 5 Apr 2004 12:39:45 -0400 X-MIMETrack: Serialize by Router on D01MLL83/01/M/IBM(Build V652_03302004NP|March 30, 2004) at 04/05/2004 12:39:46 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> To me this would imply that both >> HOST A and HOST B have a different view of IDci and >> IDcr. >> - HOST A would think the IP address for IDci is 10.1.1.1 >> and for IDcr is y.y.y.y. > >No, the HOST A will know from the configuration that it wanted to >create SA with 10.2.2.2, and that was simply reached by sending >packets to y.y.y.y, thus it will have IDci 10.1.1.1 and IDcr 10.2.2.2. >It will also notice that it must send IDci and IDcr as they do not >match the IP-addresses. > If IPSec was not in the picture and HOST A wanted to send a packet to HOST B it would send the packet to y.y.y.y and not to 10.2.2.2. I do not see why this should have to change just because IPSec is in the picture. Why should HOST A need to know that he is really sending a packet to 10.2.2.2? There is no reason to require that HOST A should know the network topology behind a NAT sitting in front of HOST B, but that is what you are requiring. >> - HOST B would think the IP address for IDci is x.x.x.x >> and for IDcr is 10.2.2.2 > >As HOST A will send the IDs the HOST B will know that the other end is >10.1.1.1, and not use implicit IP. Without IPSec in this picture HOST A would know his private address and and HOST B's public address. Likewise HOST B would know his private address and HOST A's public address. I don't really see why IPSec should change those configuration requirements. > >> In case 2 ID payloads must be exchanged (since traffic is >> constrained to TCP traffic). Based on your previous answer >> I'm thinking you would expect both HOST A and HOST B to view >> IDci as 10.1.1.1 and IDcr as 10.2.2.2. > >Yes. > >> Based on what the IDs would be if no ID payloads were sent >> I would expect that the IDs exchanged in case 2 should be the >> same as the IDs implied in case 1. This seems far more natural to >> me as it does not require HOST A to know HOST B's private address >> before the negotiation starts > >How does the implementation on HOST A start? The HOST A needs to have >some configuration which initiates the connection. In normal case it >is the packet send to the HOST B ip-address, which means that HOST A >needs to know the HOST B's ip-address so it can send that packet, and >after trig create the SA with correct host. > HOST A would continue to initiate a connection to y.y.y.y, just like he would do if IPSec was not in the picture. The IKE NAT traversal draft allows an IPSec endpoint to learn that it is behind a NAT. When an IPSec endpoint learns that it is behind a NAT it should realize that the destination IP address in the inner header of a UDP encapsulated tunnel mode packet received may not agree with the IDci and IDcr payloads sent by a peer. >> and it does not require HOST B to >> know HOST A's private address before the negotiation starts. I > >HOST B does not need to know the private address of A, as it can see >it from the ID payloads. > >> will admit that in the gateway case (my original case) that it >> seems as if knowledge of private addresses must be shared. > >It is the same with this case as long as the tunnel mode is used. > >> I think that the "Negotiation of NAT-Traversal in IKE" drafts >> needs to include conventions for setting IDci and IDcr. Perhaps >> IDci and IDcr should always be exchanged when NAT is detected? > >For transport mode, you simply ignore the IP-addresses, and you can >put anything you like there (or even use fqdn as IDci and IDcr, so you >do not need to care about the IP-addresses). > >For tunnel mode you put the internal IP-addresses, because that is how >the tunnel exit policy is negotiated. > >> My concern is that without establishing a convention for >> dealing with IDci and IDcr that we open ourselves up to >> possible interoperability issues. > >We talked about the IDci and IDcr earlier, but we really couldn't >agree anything else than it depends on the scenario, and almost >everything can be used. Some wanted to use FQDNs, some wanted to say >we simply ignore all IP-numbers in tunnel mode, and some say we leave >them out completely. > >I would have liked to add following text: > >"If negotiation is using transport mode, then received IP-addresses in >the IDci and IDcr MUST be ignored, i.e. only port and protocol numbers >are used. If negotiation is using tunnel mode, then IDci and IDcr MUST >have IP-address used inside the tunnel i.e. IP-addresses used in the >inner IP-header." I do not think such a statement is useful. I believe we disagree on what the IP addresses in the inner header would contain. I do not think that HOST A should need to know about 10.2.2.2 so I would expect the destination address in the inner header of an IP packet sent from HOST A to HOST B would contain y.y.y.y and you would expect it to contain 10.2.2.2. Dave Wierbowski z/OS Comm Server Developer From owner-ipsec@lists.tislabs.com Mon Apr 5 15:36:03 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i35Ma2gl013870; Mon, 5 Apr 2004 15:36:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i35L7gs11125 for ipsec-outgoing; Mon, 5 Apr 2004 17:07:42 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Subject: Outbound SA Bundle processing From: suren Reply-To: suren@intotoinc.com To: ipsec@lists.tislabs.com Content-Type: text/plain Organization: Intoto, Inc. Message-Id: <1081199470.1273.49.camel@suren> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 05 Apr 2004 14:11:10 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have two queries regarding SA Bundle processing. 1) If we have two SAs in an outbound SA Bundle as below, 1st SA : ESP in tunnel mode. 2nd SA : AH in tunnel mode. What should be the correct format of the packet that is produced after applying these two SAs? i) [IP1][AH][ESP][Original_IP] Or ii) [IP2][AH][IP1][ESP][Original_IP] 2) If we have more than two SAs in an outbound SA Bundle as below, 1st SA : ESP in tunnel mode, with DES 2nd SA : ESP in tunnel mode, with 3DES 3rd SA : ESP in tunnel mode, with AES 4th SA : AH in tunnel mode. What should be the correct format of the packet that is produced after applying these two SAs? Thanks suren From owner-ipsec@lists.tislabs.com Mon Apr 5 21:49:27 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i364nQam039455; Mon, 5 Apr 2004 21:49:27 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i363c7F06414 for ipsec-outgoing; Mon, 5 Apr 2004 23:38:07 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f X-MessageWall-Score: 0 (roc.co.in) Message-ID: <407228F6.3090204@roc.co.in> Date: Tue, 06 Apr 2004 09:20:14 +0530 From: Ravi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: suren@intotoinc.com CC: ipsec@lists.tislabs.com Subject: Re: Outbound SA Bundle processing References: <1081199470.1273.49.camel@suren> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Suren, 1. We have interoperated with your solution and your solution supports second option ie [IP2][AH][IP1][ESP][Original IP packet including header]. I see some emails in very old days supporting this packet format. 2. In regards to your second question, I never encountered this myself so far. There are two possibilities: A. [OuterIP Header][AH][ESP][ESP][ESP][Original IP Packet] B. [OuterIP1][AH][OuterIP2][ESP][OuterIP3][ESP][OuterIP4][ESP][Original IP Pkt] Option A seems to be better option. Regards Ravi suren wrote: >Hi, > >I have two queries regarding SA Bundle processing. > >1) If we have two SAs in an outbound SA Bundle as below, > > 1st SA : ESP in tunnel mode. > 2nd SA : AH in tunnel mode. > > What should be the correct format of the packet that is > produced after applying these two SAs? > > i) [IP1][AH][ESP][Original_IP] > > Or > > ii) [IP2][AH][IP1][ESP][Original_IP] > > > >2) If we have more than two SAs in an outbound SA Bundle as below, > > 1st SA : ESP in tunnel mode, with DES > 2nd SA : ESP in tunnel mode, with 3DES > 3rd SA : ESP in tunnel mode, with AES > 4th SA : AH in tunnel mode. > > What should be the correct format of the packet that is > produced after applying these two SAs? > > >Thanks >suren > > > > > > From owner-ipsec@lists.tislabs.com Tue Apr 6 11:01:36 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36I1Zxo067841; Tue, 6 Apr 2004 11:01:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i36GHUm04195 for ipsec-outgoing; Tue, 6 Apr 2004 12:17:30 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Date: Tue, 6 Apr 2004 12:27:58 -0400 From: "Theodore Ts'o" To: Stephen Kent Cc: Tero Kivinen , Mohan Parthasarathy , ipsec@lists.tislabs.com Subject: CONSENSUS TEST: Fragmentation handling Message-ID: <20040406162758.GA10072@thunk.org> References: <16480.15529.482315.278735@fireball.acr.fi> <016c01c416c3$eb1d8270$861167c0@adithya> <16492.6896.588750.18184@fireball.acr.fi> <16493.10872.196792.111195@fireball.acr.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, Apr 02, 2004 at 09:55:07AM -0500, Stephen Kent wrote: > > > How about a compromise? We could make #2 a MAY and #3 a SHOULD. A > >> SHOULD is almost a MUST, with a loophole as noted below (from RFC > >> 2119): > > > >That would be accectable for me. > > > >> This would allow a hardware implementation to not support #3, if > >> doing so would adversely impact overall performance. > > > > Well, since we agree on a solution, let's not argue about the rationale :-) OK, do we have have consensus on the following text? (Taken from Steve's message of March 22nd, with #2 changed to MAY and #3 changed to SHOULD). Please respond by Friday.... - Ted 1. All implementations MUST support tunnel mode SAs that pass traffic without regard to port field values. If the SA will carry traffic for specified protocols, the two selector sets MUST be used to specify the port fields for the SA: ANY and OPAQUE. An SA defined in this fashion will carry all traffic for the indicated source/destination addresses and specified protocol(s). If the SA will carry traffic without regard to a specific protocol value (i.e., ANY is specified), then the port field values MUST be set to ANY as well. 2. All implementations MAY support tunnel mode SAs that will carry only non-initial fragments, separate from non-fragmented packets and initial fragments. The OPAQUE value will be used to specify port field selectors for an SA to carry non-initial fragments. Specific port selector values will be used to define SAs to carry initial fragments and non-fragmented packets. This approach can be used if a user or administrator wants to create one or more tunnel mode SAs between the same source/destination addresses that discriminate based on port fields. These SAs MUST have non-trivial protocol selector values, otherwise approach #1 above can be used. Receivers MUST perform a minimum offset check on IPv4 (non-initial) fragments to protect against overlapping fragment attacks when SAs of this type are employed. Because such checks cannot be performed on IPv6 non-initial fragments, users and administrators are advised that carriage of such fragments may be dangerous, and implementers may choose to NOT support such SAs for IPv6 traffic. Also, because a SA of this sort will carry ALL non-initial fragments that match a specified source/destination address pair and protocol value, users and administrators are advised to protect such traffic using ESP (with integrity) and the "strongest" integrity and encryption algorithms available at both peers. (Determination of the "strongest" algorithms requires imposing a total ordering of the available algorithms, a local determination at the discretion of the initiator of the SA.) 3. An implementation SHOULD support some form of stateful fragment checking for a tunnel mode SA with non-trivial port field values (not ANY or OPAQUE). Implementations that will transmit non-initial fragments on a tunnel mode SA that makes use of non-trivial port selectors MUST notify a peer via an IKE payload (TBD). The peer MUST reject this proposal if it will not accept non-initial fragments in this context. If an implementation does not successfully negotiate transmission of non-initial fragments for such an SA, it MUST NOT send such fragments over the SA. This standard does not specify how peers will deal with such fragments, e.g., via reassembly or other means, at either sender or receiver. However, a receiver MUST drop non-initial fragments that arrive on an SA with non-trivial port selector values unless this feature has been negotiated. Dropping such packets is an auditable event. Note that in configurations where fragments of a packet might be sent or received via different security gateways or BITW implementations, stateful strategies for tracking fragments may fail. From owner-ipsec@lists.tislabs.com Tue Apr 6 11:55:23 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36ItMTU072576; Tue, 6 Apr 2004 11:55:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i36HDW207538 for ipsec-outgoing; Tue, 6 Apr 2004 13:13:32 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <1081199470.1273.49.camel@suren> References: <1081199470.1273.49.camel@suren> Date: Tue, 6 Apr 2004 11:51:00 -0400 To: suren@intotoinc.com From: Stephen Kent Subject: Re: Outbound SA Bundle 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 2:11 PM -0700 4/5/04, suren wrote: >Hi, > >I have two queries regarding SA Bundle processing. > >1) If we have two SAs in an outbound SA Bundle as below, > > 1st SA : ESP in tunnel mode. > 2nd SA : AH in tunnel mode. > > What should be the correct format of the packet that is > produced after applying these two SAs? > > i) [IP1][AH][ESP][Original_IP] > > Or > > ii) [IP2][AH][IP1][ESP][Original_IP] since both are described as tunnel mode, the second format is correct. > >2) If we have more than two SAs in an outbound SA Bundle as below, > > 1st SA : ESP in tunnel mode, with DES > 2nd SA : ESP in tunnel mode, with 3DES > 3rd SA : ESP in tunnel mode, with AES > 4th SA : AH in tunnel mode. > > What should be the correct format of the packet that is > produced after applying these two SAs? note that support for bundles, other than the trivial ones mandated by 2401 use cases, has been problematic and so 2401bis drops the requirement for such support. your example above is easily rendered into an appropriate format, but it seems pretty unrealistic. also, you list 4 SAs in the second example, but then refer to "applying these two SAs?" which suggests an arithmetic mismatch. Steve From owner-ipsec@lists.tislabs.com Tue Apr 6 12:39:13 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36JdDHr075968; Tue, 6 Apr 2004 12:39:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i36IwKN12955 for ipsec-outgoing; Tue, 6 Apr 2004 14:58:20 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Date: Tue, 6 Apr 2004 15:11:12 -0400 From: "Theodore Ts'o" To: William Dixon Cc: "'Stephen Kent'" , ipsec@lists.tislabs.com Subject: Re: Issue 83 will be withdrawn Message-ID: <20040406191112.GE10329@thunk.org> References: <200404021944.i32Ji1xA027106@rs9.luxsci.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404021944.i32Ji1xA027106@rs9.luxsci.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Sender: owner-ipsec@lists.tislabs.com Precedence: bulk William, The discussion (what little there was of it) basically revolved around doing the following: * Making generation of the ICMP messages a "MUST" * Making generation of the ICMP messages a "SHOULD" * Making generation of the ICMP messages a "MAY" * Not talking ICMP messages at all (which is what we did in IKEv1) The concern with "MUST" was that this would be problematic for high-speed IPSEC devices. The concern with "SHOULD" was that from the point of RFP's, SHOULD often turn into "MUST"'s, and this would be painful for some vendor. The argument against "MAY" was that given that the ICMP codes were already defined, there was no value in reprinting them here. When this issue was raised, there was relatively little discussion, which is why we settled on simply dropping issue #83. So I wouldn't necessarily characterize this as a consensus decision, as much as a decision based on Apathy.... Does this satisfy your concerns, or would you like make an argument for one of the other above options? - Ted From owner-ipsec@lists.tislabs.com Tue Apr 6 12:49:33 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36JnXqx076610; Tue, 6 Apr 2004 12:49:33 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i36J44A13334 for ipsec-outgoing; Tue, 6 Apr 2004 15:04:04 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Message-Id: <4.3.2.7.1.20040406120820.02032460@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Apr 2004 12:11:29 -0700 To: Ravi , suren@intotoinc.com From: Ramana Yarlagadda Subject: Re: Outbound SA Bundle processing Cc: ipsec@lists.tislabs.com In-Reply-To: <407228F6.3090204@roc.co.in> References: <1081199470.1273.49.camel@suren> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-100.0 required=10.0 tests=USER_IN_WHITELIST version=2.60 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) X-Scanned-By: MIMEDefang 2.38 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Both the options should work with out any problem. > Hi Suren, > 1. We have interoperated with your solution and your solution > supports > second option ie [IP2][AH][IP1][ESP][Original IP packet > including header]. > I see some emails in very old days supporting this packet format. > 2. In regards to your second question, I never encountered this > myself so far. > There are two possibilities: > A. [OuterIP Header][AH][ESP][ESP][ESP][Original IP Packet] > B. > [OuterIP1][AH][OuterIP2][ESP][OuterIP3][ESP][OuterIP4][ESP][Original IP Pkt] > Option A seems to be better option. The option A is efficient than the option B. -ramana From owner-ipsec@lists.tislabs.com Tue Apr 6 12:56:32 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36JuVEa077209; Tue, 6 Apr 2004 12:56:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i36JKI314166 for ipsec-outgoing; Tue, 6 Apr 2004 15:20:18 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Message-Id: <200404061932.i36JWoSj000333@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Theodore Ts'o" cc: Stephen Kent , Tero Kivinen , Mohan Parthasarathy , ipsec@lists.tislabs.com Subject: Re: CONSENSUS TEST: Fragmentation handling In-reply-to: Your message of Tue, 06 Apr 2004 12:27:58 EDT. <20040406162758.GA10072@thunk.org> Date: Tue, 06 Apr 2004 21:32:50 +0200 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: 3. An implementation SHOULD support some form of stateful fragment checking for a tunnel mode SA with non-trivial port field values (not ANY or OPAQUE). => either the wording is bad or I disagree. What I understand (which can be something else the intented meaning) is that stateful fragment checking is RECOMMENDED and a simple implementation should not just support -1- and only -1-. Regards Francis.Dupont@enst-bretagne.fr PS: I'll strongly object to any thing stronger than a MAY for stateful or reassembly strategy on a SG, not only because it makes SGs very complex but because it is clearly against one of the purpose of IPsec: to provide confidentiality. From owner-ipsec@lists.tislabs.com Tue Apr 6 13:43:52 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36KhqGf080165; Tue, 6 Apr 2004 13:43:52 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i36K0Lt15949 for ipsec-outgoing; Tue, 6 Apr 2004 16:00:21 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f To: ipsec@lists.tislabs.com Subject: Re: CONSENSUS TEST: Fragmentation handling In-Reply-To: Message from "Theodore Ts'o" of "Tue, 06 Apr 2004 12:27:58 EDT." <20040406162758.GA10072@thunk.org> References: <16480.15529.482315.278735@fireball.acr.fi> <016c01c416c3$eb1d8270$861167c0@adithya> <16492.6896.588750.18184@fireball.acr.fi> <16493.10872.196792.111195@fireball.acr.fi> <20040406162758.GA10072@thunk.org> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Tue, 06 Apr 2004 16:11:48 -0400 Message-ID: <1529.1081282308@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Theodore" == Theodore Ts'o writes: Theodore> OK, do we have have consensus on the following text? Theodore> (Taken from Steve's message of March 22nd, with #2 changed Theodore> to MAY and #3 changed to SHOULD). Theodore> Please respond by Friday.... yes. I'm unclear how a responder knows that a non-initial fragment SA is being negotiated in IKE. Is it based only on the OPAQUE value as port-selectors? What about the protocol? Theodore> 3. An implementation SHOULD support some form of stateful Theodore> fragment checking for a tunnel mode SA with non-trivial Theodore> port field values (not ANY or OPAQUE). Implementations Theodore> that will transmit non-initial fragments on a tunnel mode Theodore> SA that makes use of non-trivial port selectors MUST Theodore> notify a peer via an IKE payload (TBD). The peer MUST This seems like a new option to the TSx payload, right? - -- ] 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 iQCVAwUBQHMPA4qHRg3pndX9AQGVXwQAzUWH3X7GODJEBIk30DapDeLzjOZ1U5G0 er0E4gppkvfy6cePBYt0tBPSDFVM1ig0s0Myk9ABcr0GmnMGVGHzmyBU1chh2InW Knp8pdY68F2T82UQQAxNQ8YfaJkeqs6L62AUWpIh28rKAXZYYX2OBxeM8E7lQRWK SBoJElMI9gk= =tHia -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Apr 6 13:45:11 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36KjAfU080240; Tue, 6 Apr 2004 13:45:10 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i36K6XY16372 for ipsec-outgoing; Tue, 6 Apr 2004 16:06:33 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200404061932.i36JWoSj000333@givry.rennes.enst-bretagne.fr> References: <200404061932.i36JWoSj000333@givry.rennes.enst-bretagne.fr> Date: Tue, 6 Apr 2004 16:18:11 -0400 To: Francis Dupont From: Stephen Kent Subject: Re: CONSENSUS TEST: Fragmentation handling Cc: "Theodore Ts'o" , Tero Kivinen , Mohan Parthasarathy , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:32 PM +0200 4/6/04, Francis Dupont wrote: > In your previous mail you wrote: > > 3. An implementation SHOULD support some form of stateful > fragment checking for a tunnel mode SA with non-trivial port field > values (not ANY or OPAQUE). > >=> either the wording is bad or I disagree. What I understand (which >can be something else the intented meaning) is that stateful fragment >checking is RECOMMENDED and a simple implementation should not just >support -1- and only -1-. > >Regards > >Francis.Dupont@enst-bretagne.fr > >PS: I'll strongly object to any thing stronger than a MAY for stateful >or reassembly strategy on a SG, not only because it makes SGs very >complex but because it is clearly against one of the purpose of IPsec: >to provide confidentiality. Francis, I proposed was that the stateful fragment checking be a SHOULD, with the explicit intent that an implementation may choose to not support #3 because of performance considerations. We can mention that exception in the text. Would that address your concerns? Steve From owner-ipsec@lists.tislabs.com Tue Apr 6 13:46:49 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36KkmH1080324; Tue, 6 Apr 2004 13:46:48 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i36K67016332 for ipsec-outgoing; Tue, 6 Apr 2004 16:06:07 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 6 Apr 2004 15:56:01 -0400 To: "Theodore Ts'o" From: Stephen Kent Subject: Re: Disposition of the IKEv2 ID_KEY_ID type 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 2:12 PM -0400 4/6/04, Theodore Ts'o wrote: > > >Is this an outcome that most people on the list could live with? > > - Ted I can live with it. Steve From owner-ipsec@lists.tislabs.com Tue Apr 6 13:47:25 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36KlO19080366; Tue, 6 Apr 2004 13:47:25 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i36K6KN16342 for ipsec-outgoing; Tue, 6 Apr 2004 16:06:20 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <20040406162758.GA10072@thunk.org> References: <16480.15529.482315.278735@fireball.acr.fi> <016c01c416c3$eb1d8270$861167c0@adithya> <16492.6896.588750.18184@fireball.acr.fi> <16493.10872.196792.111195@fireball.acr.fi> <20040406162758.GA10072@thunk.org> Date: Tue, 6 Apr 2004 16:17:28 -0400 To: "Theodore Ts'o" From: Stephen Kent Subject: Re: CONSENSUS TEST: Fragmentation handling Cc: Tero Kivinen , Mohan Parthasarathy , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ted, >1. All implementations MUST support tunnel mode SAs that pass traffic >without regard to port field values. If the SA will carry traffic for >specified protocols, the two selector sets MUST be used to specify >the port fields for the SA: ANY and OPAQUE. An SA defined in this >fashion will carry all traffic for the indicated source/destination >addresses and specified protocol(s). If the SA will carry traffic >without regard to a specific protocol value (i.e., ANY is specified), >then the port field values MUST be set to ANY as well. Mark Duffy convinced me that we should interpret ANY to encompass OPAQUE, as I noted in a message last week. So this part should be reworded to say: 1. All implementations MUST support tunnel mode SAs that pass traffic without regard to port field values. If the SA will carry traffic for specified protocols, the selector set for the SA MUST specify the port fields values as ANY. An SA defined in this fashion will carry all traffic for the indicated source/destination addresses and specified protocol(s). If the SA will carry traffic without regard to a specific protocol value (i.e., ANY is specified for the protocol field), then the port field values MUST be set to ANY as well. Steve From owner-ipsec@lists.tislabs.com Tue Apr 6 14:42:05 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36Lg1FJ083504; Tue, 6 Apr 2004 14:42:05 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i36L6Cv21618 for ipsec-outgoing; Tue, 6 Apr 2004 17:06:12 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Message-Id: <5.2.0.9.0.20040406170241.021ba780@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 06 Apr 2004 17:19:07 -0400 To: "Theodore Ts'o" , Stephen Kent From: Mark Duffy Subject: Re: CONSENSUS TEST: Fragmentation handling Cc: Tero Kivinen , Mohan Parthasarathy , ipsec@lists.tislabs.com In-Reply-To: <20040406162758.GA10072@thunk.org> References: <16480.15529.482315.278735@fireball.acr.fi> <016c01c416c3$eb1d8270$861167c0@adithya> <16492.6896.588750.18184@fireball.acr.fi> <16493.10872.196792.111195@fireball.acr.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:27 PM 4/6/2004 -0400, Theodore Ts'o wrote: >OK, do we have have consensus on the following text? (Taken from >Steve's message of March 22nd, with #2 changed to MAY and #3 changed >to SHOULD). > >Please respond by Friday.... Hi Ted, I had raised several points on this that I believe Steve agreed to and no one else commented on: a) For modes #1 and #2, the document should mention that the same behavior must apply for drop and bypass rules. (I think Steve wanted to put it in another section.) b) For mode #3 the text should be extended to state that if the #3 behavior has been negotiated, the receiver MUST NOT accept non-initial fragments without verifying that they comply with the security policy called for for the overall packet. c) Port selector ANY should include OPAQUE as well as all specific values. I.e. an opaque port number in a packet should match a policy that has the value ANY. Beyond that, I would much rather make both #2 and #3 be MAY and MAY. (Rather than MAY and SHOULD.) --Mark From owner-ipsec@lists.tislabs.com Tue Apr 6 14:47:39 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36LlcvC083838; Tue, 6 Apr 2004 14:47:38 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i36LDvl22204 for ipsec-outgoing; Tue, 6 Apr 2004 17:13:57 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Message-Id: <200404062125.i36LP9Sj000673@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Stephen Kent cc: "Theodore Ts'o" , Tero Kivinen , Mohan Parthasarathy , ipsec@lists.tislabs.com Subject: Re: CONSENSUS TEST: Fragmentation handling In-reply-to: Your message of Tue, 06 Apr 2004 16:18:11 EDT. Date: Tue, 06 Apr 2004 23:25:09 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: I proposed was that the stateful fragment checking be a SHOULD, with the explicit intent that an implementation may choose to not support #3 because of performance considerations. => I can't see why a MAY is not enough. We can mention that exception in the text. Would that address your concerns? => perhaps I don't understand the wording, i.e., the idea is to specify (with a SHOULD) how an implementation which chooses to support #3 should proceed. My concern is that it seems the SHOULD applies to all implementations so an implementation SHOULD NOT choose to not support #3... Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Apr 6 14:50:06 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36Lo6k1084060; Tue, 6 Apr 2004 14:50:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i36LA1u21908 for ipsec-outgoing; Tue, 6 Apr 2004 17:10:01 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Date: Tue, 6 Apr 2004 17:19:29 -0400 From: "Theodore Ts'o" To: Francis Dupont Cc: Stephen Kent , Tero Kivinen , Mohan Parthasarathy , ipsec@lists.tislabs.com Subject: Re: CONSENSUS TEST: Fragmentation handling Message-ID: <20040406211929.GH10329@thunk.org> References: <20040406162758.GA10072@thunk.org> <200404061932.i36JWoSj000333@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404061932.i36JWoSj000333@givry.rennes.enst-bretagne.fr> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Apr 06, 2004 at 09:32:50PM +0200, Francis Dupont wrote: > In your previous mail you wrote: > > 3. An implementation SHOULD support some form of stateful > fragment checking for a tunnel mode SA with non-trivial port field > values (not ANY or OPAQUE). > > => either the wording is bad or I disagree. What I understand (which > can be something else the intented meaning) is that stateful fragment > checking is RECOMMENDED and a simple implementation should not just > support -1- and only -1-. How do you view "RECOMMENDED" as being different from "SHOULD"? > PS: I'll strongly object to any thing stronger than a MAY for stateful > or reassembly strategy on a SG, not only because it makes SGs very > complex but because it is clearly against one of the purpose of IPsec: > to provide confidentiality. You lost me there. How does incoming fragment reassembly violate the goal of confidentiality? - Ted From owner-ipsec@lists.tislabs.com Tue Apr 6 15:30:39 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36MUd5o087492; Tue, 6 Apr 2004 15:30:39 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i36Lt6h24463 for ipsec-outgoing; Tue, 6 Apr 2004 17:55:06 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.2.0.9.0.20040406170241.021ba780@email> References: <16480.15529.482315.278735@fireball.acr.fi> <016c01c416c3$eb1d8270$861167c0@adithya> <16492.6896.588750.18184@fireball.acr.fi> <16493.10872.196792.111195@fireball.acr.fi> <5.2.0.9.0.20040406170241.021ba780@email> Date: Tue, 6 Apr 2004 18:02:44 -0400 To: Mark Duffy From: Stephen Kent Subject: Re: CONSENSUS TEST: Fragmentation handling Cc: "Theodore Ts'o" , Tero Kivinen , Mohan Parthasarathy , 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 5:19 PM -0400 4/6/04, Mark Duffy wrote: >At 12:27 PM 4/6/2004 -0400, Theodore Ts'o wrote: >>OK, do we have have consensus on the following text? (Taken from >>Steve's message of March 22nd, with #2 changed to MAY and #3 changed >>to SHOULD). >> >>Please respond by Friday.... > >Hi Ted, > >I had raised several points on this that I believe Steve agreed to >and no one else commented on: > >a) For modes #1 and #2, the document should mention that the same >behavior must apply for drop and bypass rules. (I think Steve >wanted to put it in another section.) right. >b) For mode #3 the text should be extended to state that if the #3 >behavior has been negotiated, the receiver MUST NOT accept >non-initial fragments without verifying that they comply with the >security policy called for for the overall packet. right again. >c) Port selector ANY should include OPAQUE as well as all specific >values. I.e. an opaque port number in a packet should match a >policy that has the value ANY. I said that in my message to Ted, clarifying #1. > >Beyond that, I would much rather make both #2 and #3 be MAY and MAY. >(Rather than MAY and SHOULD.) See my response to Francis on why we have a SHOULD and a MAY. Steve From owner-ipsec@lists.tislabs.com Tue Apr 6 15:30:59 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36MUxwD087536; Tue, 6 Apr 2004 15:30:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i36Lt2x24452 for ipsec-outgoing; Tue, 6 Apr 2004 17:55:02 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200404062125.i36LP9Sj000673@givry.rennes.enst-bretagne.fr> References: <200404062125.i36LP9Sj000673@givry.rennes.enst-bretagne.fr> Date: Tue, 6 Apr 2004 18:01:10 -0400 To: Francis Dupont From: Stephen Kent Subject: Re: CONSENSUS TEST: Fragmentation handling Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:25 PM +0200 4/6/04, Francis Dupont wrote: > In your previous mail you wrote: > > I proposed was that the stateful fragment checking be a SHOULD, with > the explicit intent that an implementation may choose to not support > #3 because of performance considerations. > >=> I can't see why a MAY is not enough. well, I wanted to have one MUST between #2 and #3. Originally #2 was MUST and #3 was MAY. but Tero argued against the MUST for #2, so I changed #3 to a SHOULD and #2 to MAY, as a compromise. hope that's clear :-) > > We can mention that exception in the text. > Would that address your concerns? > >=> perhaps I don't understand the wording, i.e., the idea is to specify >(with a SHOULD) how an implementation which chooses to support #3 should >proceed. My concern is that it seems the SHOULD applies to all implementations >so an implementation SHOULD NOT choose to not support #3... the SHOULD does apply to all implementations, but a SHOULD means that the implementation SHOULD offer this feature, unless there is a good reason not to. I gave what I considered to be the good reason. Steve From owner-ipsec@lists.tislabs.com Tue Apr 6 15:36:51 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36Mapmx087812; Tue, 6 Apr 2004 15:36:51 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i36Lwns24709 for ipsec-outgoing; Tue, 6 Apr 2004 17:58:49 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <1529.1081282308@marajade.sandelman.ottawa.on.ca> References: <16480.15529.482315.278735@fireball.acr.fi> <016c01c416c3$eb1d8270$861167c0@adithya> <16492.6896.588750.18184@fireball.acr.fi> <16493.10872.196792.111195@fireball.acr.fi> <20040406162758.GA10072@thunk.org> <1529.1081282308@marajade.sandelman.ottawa.on.ca> Date: Tue, 6 Apr 2004 18:05:47 -0400 To: Michael Richardson From: Stephen Kent Subject: Re: CONSENSUS TEST: Fragmentation handling Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:11 PM -0400 4/6/04, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >>>>>> "Theodore" == Theodore Ts'o writes: > Theodore> OK, do we have have consensus on the following text? > Theodore> (Taken from Steve's message of March 22nd, with #2 changed > Theodore> to MAY and #3 changed to SHOULD). > > Theodore> Please respond by Friday.... > > yes. > > I'm unclear how a responder knows that a non-initial fragment SA is >being negotiated in IKE. Is it based only on the OPAQUE value as >port-selectors? What about the protocol? The use of OPAQUE is now restricted to carriage of non-initial fragments, after the change that Mark suggested. so, yes, negotiating an SA with port fields set to OPAQUE indicates that the SA is used to carry non-initial fragments. for IPv4, this is irrespective of the port field selector, which could be specific, or ANY. for v6, it is conceivable that the next protocol would not be identified in the initial fragment, so one would have to set protocol to ANY in that case. > > Theodore> 3. An implementation SHOULD support some form of stateful > Theodore> fragment checking for a tunnel mode SA with non-trivial > Theodore> port field values (not ANY or OPAQUE). Implementations > Theodore> that will transmit non-initial fragments on a tunnel mode > Theodore> SA that makes use of non-trivial port selectors MUST > Theodore> notify a peer via an IKE payload (TBD). The peer MUST > > This seems like a new option to the TSx payload, right? right. From owner-ipsec@lists.tislabs.com Tue Apr 6 15:52:12 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36MqC5D089081; Tue, 6 Apr 2004 15:52:12 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i36MBdm25346 for ipsec-outgoing; Tue, 6 Apr 2004 18:11:39 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Message-Id: <200404062223.i36MNISj000857@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Theodore Ts'o" cc: Stephen Kent , Tero Kivinen , Mohan Parthasarathy , ipsec@lists.tislabs.com Subject: Re: CONSENSUS TEST: Fragmentation handling In-reply-to: Your message of Tue, 06 Apr 2004 17:19:29 EDT. <20040406211929.GH10329@thunk.org> Date: Wed, 07 Apr 2004 00:23:18 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > In your previous mail you wrote: > > 3. An implementation SHOULD support some form of stateful > fragment checking for a tunnel mode SA with non-trivial port field > values (not ANY or OPAQUE). > > => either the wording is bad or I disagree. What I understand (which > can be something else the intented meaning) is that stateful fragment > checking is RECOMMENDED and a simple implementation should not just > support -1- and only -1-. How do you view "RECOMMENDED" as being different from "SHOULD"? => I don't and this is the reason of my concern. > PS: I'll strongly object to any thing stronger than a MAY for stateful > or reassembly strategy on a SG, not only because it makes SGs very > complex but because it is clearly against one of the purpose of IPsec: > to provide confidentiality. You lost me there. How does incoming fragment reassembly violate the goal of confidentiality? => anything which tries to look at inside my packets violates my confidentiality, and I don't like this at all from something which is supposed to protect it. IMHO a router should not look at something which is not in the IP header, or do you argue we should only use IPsec end-to-end? (I am not against the idea but this is a bit drastic). Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Apr 6 16:23:43 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36NNgce090713; Tue, 6 Apr 2004 16:23:42 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i36Mkfb26981 for ipsec-outgoing; Tue, 6 Apr 2004 18:46:41 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Message-Id: <200404062258.i36MwRSj000983@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: CONSENSUS TEST: Fragmentation handling In-reply-to: Your message of Tue, 06 Apr 2004 18:01:10 EDT. Date: Wed, 07 Apr 2004 00:58:27 +0200 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: At 11:25 PM +0200 4/6/04, Francis Dupont wrote: > In your previous mail you wrote: > > I proposed was that the stateful fragment checking be a SHOULD, with > the explicit intent that an implementation may choose to not support > #3 because of performance considerations. > >=> I can't see why a MAY is not enough. well, I wanted to have one MUST between #2 and #3. Originally #2 was MUST and #3 was MAY. but Tero argued against the MUST for #2, so I changed #3 to a SHOULD and #2 to MAY, as a compromise. hope that's clear :-) => now I understand. I am in favor of MAYs for #2 and #3. BTW the #2 makes the wrong assumption that one can always get the upper protocol from an initial fragment (there are counter-examples in IPv6). the SHOULD does apply to all implementations, but a SHOULD means that the implementation SHOULD offer this feature, unless there is a good reason not to. I gave what I considered to be the good reason. => I (can) consider you gave the good reason to give only a MAY to #3. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Apr 6 18:52:05 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i371q5nl015009; Tue, 6 Apr 2004 18:52:05 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i3711M906176 for ipsec-outgoing; Tue, 6 Apr 2004 21:01:22 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Message-Id: <5.2.0.9.0.20040406154936.039aa6c8@10.1.5.10> X-Sender: vamsi@10.1.5.10 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 06 Apr 2004 18:09:25 -0700 To: "Theodore Ts'o" , Stephen Kent From: vamsi Subject: Re: CONSENSUS TEST: Fragmentation handling Cc: Tero Kivinen , Mohan Parthasarathy , ipsec@lists.tislabs.com In-Reply-To: <20040406162758.GA10072@thunk.org> References: <16480.15529.482315.278735@fireball.acr.fi> <016c01c416c3$eb1d8270$861167c0@adithya> <16492.6896.588750.18184@fireball.acr.fi> <16493.10872.196792.111195@fireball.acr.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:27 PM 4/6/2004 -0400, Theodore Ts'o wrote: >On Fri, Apr 02, 2004 at 09:55:07AM -0500, Stephen Kent wrote: > > > > How about a compromise? We could make #2 a MAY and #3 a SHOULD. A > > >> SHOULD is almost a MUST, with a loophole as noted below (from RFC > > >> 2119): > > > > > >That would be accectable for me. > > > > > >> This would allow a hardware implementation to not support #3, if > > >> doing so would adversely impact overall performance. > > > > > > > Well, since we agree on a solution, let's not argue about the rationale :-) > >OK, do we have have consensus on the following text? (Taken from >Steve's message of March 22nd, with #2 changed to MAY and #3 changed >to SHOULD). > >Please respond by Friday.... > > - Ted > > >1. All implementations MUST support tunnel mode SAs that pass traffic >without regard to port field values. If the SA will carry traffic for >specified protocols, the two selector sets MUST be used to specify >the port fields for the SA: ANY and OPAQUE. An SA defined in this >fashion will carry all traffic for the indicated source/destination >addresses and specified protocol(s). If the SA will carry traffic >without regard to a specific protocol value (i.e., ANY is specified), >then the port field values MUST be set to ANY as well. > >2. All implementations MAY support tunnel mode SAs that will carry >only non-initial fragments, separate from non-fragmented packets and >initial fragments. The OPAQUE value will be used to specify port >field selectors for an SA to carry non-initial fragments. Specific >port selector values will be used to define SAs to carry initial >fragments and non-fragmented packets. This approach can be used if a >user or administrator wants to create one or more tunnel mode SAs >between the same source/destination addresses that discriminate based >on port fields. These SAs MUST have non-trivial protocol selector >values, otherwise approach #1 above can be used. Receivers MUST >perform a minimum offset check on IPv4 (non-initial) fragments to >protect against overlapping fragment attacks when SAs of this type >are employed. Because such checks cannot be performed on IPv6 >non-initial fragments, users and administrators are advised that >carriage of such fragments may be dangerous, and implementers may >choose to NOT support such SAs for IPv6 traffic. Also, because a SA >of this sort will carry ALL non-initial fragments that match a >specified source/destination address pair and protocol value, users >and administrators are advised to protect such traffic using ESP >(with integrity) and the "strongest" integrity and encryption >algorithms available at both peers. (Determination of the "strongest" >algorithms requires imposing a total ordering of the available >algorithms, a local determination at the discretion of the initiator >of the SA.) > >3. An implementation SHOULD support some form of stateful >fragment checking for a tunnel mode SA with non-trivial port field >values (not ANY or OPAQUE). Implementations that will transmit >non-initial fragments on a tunnel mode SA that makes use of >non-trivial port selectors MUST notify a peer via an IKE payload >(TBD). The peer MUST reject this proposal if it will not accept >non-initial fragments in this context. If an implementation does not >successfully negotiate transmission of non-initial fragments for such >an SA, it MUST NOT send such fragments over the SA. This standard >does not specify how peers will deal with such fragments, e.g., via >reassembly or other means, at either sender or receiver. However, a >receiver MUST drop non-initial fragments that arrive on an SA with >non-trivial port selector values unless this feature has been >negotiated. Dropping such packets is an auditable event. Note that in >configurations where fragments of a packet might be sent or received >via different security gateways or BITW implementations, stateful >strategies for tracking fragments may fail. It seems fine to me, but I have these comments. 1. Case 3 can be made as 'MAY'. 2. When case 2 is not employed and when communicating security gateways don't agree on, as mentioned in case3, the sender implementations, in my view, MUST not drop the packets and use mechanisms such as 'reassembly'. So, it would be better to indicate this explicitly in the text. Vamsi From owner-ipsec@lists.tislabs.com Tue Apr 6 21:06:21 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3746IXU065870; Tue, 6 Apr 2004 21:06:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i373M5o15826 for ipsec-outgoing; Tue, 6 Apr 2004 23:22:05 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Message-Id: <200404070333.i373XgQU017075@thunk.east.sun.com> From: Bill Sommerfeld To: Francis Dupont cc: "Theodore Ts'o" , Stephen Kent , Tero Kivinen , Mohan Parthasarathy , ipsec@lists.tislabs.com Subject: Re: CONSENSUS TEST: Fragmentation handling In-Reply-To: Your message of "Wed, 07 Apr 2004 00:23:18 +0200." <200404062223.i36MNISj000857@givry.rennes.enst-bretagne.fr> Reply-to: sommerfeld@east.sun.com Date: Tue, 06 Apr 2004 23:33:42 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > => anything which tries to look at inside my packets violates my > confidentiality, and I don't like this at all from something which > is supposed to protect it. IMHO a router should not look at something > which is not in the IP header, or do you argue we should only use > IPsec end-to-end? (I am not against the idea but this is a bit drastic). We're talking about behavior in an IPsec implementation which enforces policy based on port numbers. On the cleartext side, it's *already* looking into the packet well past the ip header.. - Bill From owner-ipsec@lists.tislabs.com Tue Apr 6 21:24:09 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i374O9IP070101; Tue, 6 Apr 2004 21:24:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i373okq17943 for ipsec-outgoing; Tue, 6 Apr 2004 23:50:46 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f X-MessageWall-Score: 0 (roc.co.in) Message-ID: <40737D8E.2020309@roc.co.in> Date: Wed, 07 Apr 2004 09:33:26 +0530 From: Ravi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: SPD Policies - Backward compatibility Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Based on one of the emails, I got an impression that rfc2401-bis is mainly intended for IKEv2. This got me thinking on the compatibility issues. I would assume that, security appliances would be providing both IKEv1/v2 and rfc2401/2401bis implementations. In rfc2401bis and IKEv2, there is provision for providing multiple ranges for source and destination selectors. But, rfc2401/ikev1 does not support this combination. Does this mean that, the administrator configuring security policies should have prior (out-of-band) knowledge on remote security gateway capabilities? This does not seem right and I am wondering how do we achieve the backward compatibility where some devices are IKEv2/2401bis capable and some are not. Thanks Ravi From owner-ipsec@lists.tislabs.com Tue Apr 6 22:27:20 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i375RJ2N090392; Tue, 6 Apr 2004 22:27:19 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i36HxZM09795 for ipsec-outgoing; Tue, 6 Apr 2004 13:59:35 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f To: ipsec@lists.tislabs.com Subject: Disposition of the IKEv2 ID_KEY_ID type From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Tue, 06 Apr 2004 14:12:28 -0400 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 Discussion on this topic has died down, so here is my attempt to try to summarize the discussion. The main concern seems to be due to the phrase "an account name" in the following text from the ikev2 draft: ID_KEY_ID 11 An opaque octet stream which may be used to pass an account name or to pass vendor-specific information necessary to do certain proprietary types of identification. Specifically, the pandora's box which gets opened once "an account name" is added is the dreaded internationalization question. It seems one simple way of addressing this situation is to simply to revert to the IKEv1 wording, which would simply involve deleting the phrase "to pass an account name or" from the specification. This would leave ID_KEY_ID as being nothing more than a private use field that can be used between consenting clients and servers to pass a vendor- or site- specific identification. If we were to do this, which would make the use of ID_KEY_ID unambiguous, it raises the next question: should we create a new identity type that contains an account name, with some kind of tight specification about the use of UTF-8 or whatever. Noting that we already have support for an X.500 General Name, which does have internationalization support in it already, I am going to suggest that we do *not* try to define some kind of new account name identity type at this time. If there is a desire for such a new identity type, it will always be possible to define a new type in another RFC. But given that IKEv2 is currently in last call, it doesn't seem like it's the time now to try to add new identity types.... Is this an outcome that most people on the list could live with? - Ted From owner-ipsec@lists.tislabs.com Wed Apr 7 02:16:27 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i379GQKe076404; Wed, 7 Apr 2004 02:16:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i378VKO09039 for ipsec-outgoing; Wed, 7 Apr 2004 04:31:20 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f 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: <16499.48904.313410.326163@fireball.acr.fi> Date: Wed, 7 Apr 2004 11:42:48 +0300 From: Tero Kivinen To: Stephen Kent Cc: "Theodore Ts'o" , Mohan Parthasarathy , ipsec@lists.tislabs.com Subject: Re: CONSENSUS TEST: Fragmentation handling In-Reply-To: References: <16480.15529.482315.278735@fireball.acr.fi> <016c01c416c3$eb1d8270$861167c0@adithya> <16492.6896.588750.18184@fireball.acr.fi> <16493.10872.196792.111195@fireball.acr.fi> <20040406162758.GA10072@thunk.org> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 1 min X-Total-Time: 0 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > 1. All implementations MUST support tunnel mode SAs that pass traffic > without regard to port field values. If the SA will carry traffic for > specified protocols, the selector set for the SA MUST specify the > port fields values as ANY. An SA defined in this fashion will carry > all traffic for the indicated source/destination addresses and > specified protocol(s). If the SA will carry traffic without regard to > a specific protocol value (i.e., ANY is specified for the protocol > field), then the port field values MUST be set to ANY as well. That change is ok, by me. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Wed Apr 7 02:30:29 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i379USXs077424; Wed, 7 Apr 2004 02:30:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i378oY010442 for ipsec-outgoing; Wed, 7 Apr 2004 04:50:34 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f 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: <16499.50078.697939.503374@fireball.acr.fi> Date: Wed, 7 Apr 2004 12:02:22 +0300 From: Tero Kivinen To: Ravi Cc: ipsec@lists.tislabs.com Subject: SPD Policies - Backward compatibility In-Reply-To: <40737D8E.2020309@roc.co.in> References: <40737D8E.2020309@roc.co.in> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 7 min X-Total-Time: 8 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ravi writes: > I would assume that, security appliances would be providing > both IKEv1/v2 and rfc2401/2401bis implementations. In rfc2401bis and > IKEv2, there is provision for providing multiple ranges for source > and destination selectors. But, rfc2401/ikev1 does not support this > combination. You can simply expand all list of ranges to single ranges for IP-addresses, i.e. instead of creating 1 SA which will carry packets from source ip-ranges 10.0.0.0-10.0.0.255, 10.0.2.128-10.0.2.222 you will create two SAs, one for each range. This will work fine with IP-address ranges, but it will not work well on port ranges (it would be little bit annoying to create 65534 SAs to expand the port range 1-24, 26-65535 :-). On the other hand you can there create SAs per port basis, i.e. when the port is first time used you create new SA for that (per port pair SAs). This is again quite a lot more expensive than IKEv2 case, but it will still work even if the other end only supports IKEv1. > Does this mean that, the administrator configuring security policies > should have prior (out-of-band) knowledge on remote security gateway > capabilities? In most of the cases the administrator already have the prior knowledge about the remote security gateway capabilities, as he also configures that end :-) If he knows that the remote end only supports IKEv1 he should try to avoid expensive constructs (i.e. port holes etc), or the IKEv2 implementation can also disallow talking with IKEv1 implementations when such constructs is used. It is mostly implementation issue. > This does not seem right and I am wondering how do we achieve the > backward compatibility where some devices are IKEv2/2401bis capable > and some are not. As I said the IKEv2 implementations can expand their policies to the IKEv1 compatible format, but it might be very expensive in some cases (port holes, port ranges, multiple source and destination ranges etc). Whether the implementations will support that is another matter, and whether adminstrators configure systems and use those features is yet another matter. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Wed Apr 7 02:32:59 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i379Ww1a077578; Wed, 7 Apr 2004 02:32:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i378x8111012 for ipsec-outgoing; Wed, 7 Apr 2004 04:59:08 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Message-Id: <200404070910.i379AYSj002498@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: sommerfeld@east.sun.com cc: "Theodore Ts'o" , Stephen Kent , Tero Kivinen , Mohan Parthasarathy , ipsec@lists.tislabs.com Subject: Re: CONSENSUS TEST: Fragmentation handling In-reply-to: Your message of Tue, 06 Apr 2004 23:33:42 EDT. <200404070333.i373XgQU017075@thunk.east.sun.com> Date: Wed, 07 Apr 2004 11:10:34 +0200 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: > => anything which tries to look at inside my packets violates my > confidentiality, and I don't like this at all from something which > is supposed to protect it. IMHO a router should not look at something > which is not in the IP header, or do you argue we should only use > IPsec end-to-end? (I am not against the idea but this is a bit drastic). We're talking about behavior in an IPsec implementation which enforces policy based on port numbers. On the cleartext side, it's *already* looking into the packet well past the ip header.. => I have nothing against an IPsec implementation which enforces policy based on port numbers and when a security gateway is colocated with a stateful firewall this is the thing to do, so this has to be specified. My concern is as a side effect of this specification it seems that to enforce policy based on port numbers is RECOMMENDED. I believe the issue is in fact in the wording... Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Wed Apr 7 03:35:06 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37AZ5nr082193; Wed, 7 Apr 2004 03:35:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i379wQE15147 for ipsec-outgoing; Wed, 7 Apr 2004 05:58:26 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f 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: <16499.53929.188242.629272@fireball.acr.fi> Date: Wed, 7 Apr 2004 13:06:33 +0300 From: Tero Kivinen To: Stephen Kent Cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: CONSENSUS TEST: Fragmentation handling In-Reply-To: References: <16480.15529.482315.278735@fireball.acr.fi> <016c01c416c3$eb1d8270$861167c0@adithya> <16492.6896.588750.18184@fireball.acr.fi> <16493.10872.196792.111195@fireball.acr.fi> <20040406162758.GA10072@thunk.org> <1529.1081282308@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 26 min X-Total-Time: 63 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > > I'm unclear how a responder knows that a non-initial fragment SA is > >being negotiated in IKE. Is it based only on the OPAQUE value as > >port-selectors? What about the protocol? > > The use of OPAQUE is now restricted to carriage of non-initial > fragments, after the change that Mark suggested. so, yes, negotiating > an SA with port fields set to OPAQUE indicates that the SA is used to > carry non-initial fragments. for IPv4, this is irrespective of the > port field selector, which could be specific, or ANY. for v6, it is ^^^^^^^^^^ I assume this should be "protocol field selector", not "port" > conceivable that the next protocol would not be identified in the > initial fragment, so one would have to set protocol to ANY in that > case. > > > > > Theodore> 3. An implementation SHOULD support some form of stateful > > Theodore> fragment checking for a tunnel mode SA with non-trivial > > Theodore> port field values (not ANY or OPAQUE). Implementations > > Theodore> that will transmit non-initial fragments on a tunnel mode > > Theodore> SA that makes use of non-trivial port selectors MUST > > Theodore> notify a peer via an IKE payload (TBD). The peer MUST > > This seems like a new option to the TSx payload, right? > right. We have to think how to negotiate all of these in the IKEv2, but first I think we need to get agreement on that we are really going to accept the base proposal (I hope we have that agreement now). So we have 3 different things to negotiate: 1) All traffic through one SA regardless of ports 2) First-fragments on per port SAs, and non-first on one special SA 3) First-fragments and non-first fragments on per port SAs The case 1 is simple, 1) PROTO = ANY or xx PORT = ANY <-> ANY Case 2 is little more complicated: First-fragments SAs: 2a) PROTO = xx PORT = yy <-> zz Special non-first fragment SA: 2b) PROTO = ANY or xx PORT = OPAQUE <-> OPAQUE Case 3 SAs looks identical to the First-fragment SAs in case 2: 3) PROTO = xx PORT = yy <-> zz so we need some method to distinguish the SAs in cases 2a and 3, and make sure that if the negotiation fails we can fall back properly. One option is to add new notify to case 3, i.e. something like NON_FIRST_FRAGMENTS_ALSO notification. This notification would tell that the sender would like to send also non-first fragments inside this SA. If both ends send this notification then we are using case 3. If only one end sends it then we are using case 2, and the initiator should then create the 2b SA. If initiator does in that case want to fall back to case 1, it will delete the SA and create new SA for case 1. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Wed Apr 7 06:00:47 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37D0kTn091442; Wed, 7 Apr 2004 06:00:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i37CNRj26996 for ipsec-outgoing; Wed, 7 Apr 2004 08:23:27 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Date: Wed, 7 Apr 2004 08:35:16 -0400 From: "Theodore Ts'o" To: Francis Dupont Cc: Stephen Kent , Tero Kivinen , Mohan Parthasarathy , ipsec@lists.tislabs.com Subject: Re: CONSENSUS TEST: Fragmentation handling Message-ID: <20040407123515.GB13400@thunk.org> References: <20040406211929.GH10329@thunk.org> <200404062223.i36MNISj000857@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404062223.i36MNISj000857@givry.rennes.enst-bretagne.fr> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Apr 07, 2004 at 12:23:18AM +0200, Francis Dupont wrote: > You lost me there. How does incoming fragment reassembly violate the > goal of confidentiality? > > => anything which tries to look at inside my packets violates my > confidentiality, and I don't like this at all from something which > is supposed to protect it. IMHO a router should not look at something > which is not in the IP header, or do you argue we should only use > IPsec end-to-end? (I am not against the idea but this is a bit drastic). Um, fragment reassembly means that you are copying the bits around, but you are not actually "looking" at it. Many implementations end up copying the bits around anyway as they add and subtract headers, and certainly if they are encrypting the data payload! Also, as others have pointed out, when we do port-specific selectors, the implementation is forced to actually "look" at something which is beyond the IP header. So when you say this violates the goal of confidentiality, this seems to involved a very strange definition of confidentiality, which most IPSEC implementations are violating anyway. If you don't trust the IPSEC processor to reassemble your fragments, why are you trusting to encrypt your packets? Both involve "looking" at the data payload to roughly the same extent! - Ted From owner-ipsec@lists.tislabs.com Wed Apr 7 08:24:54 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37FOrOT003110; Wed, 7 Apr 2004 08:24:53 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i37EhxO07559 for ipsec-outgoing; Wed, 7 Apr 2004 10:43:59 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Wed, 7 Apr 2004 07:52:22 -0700 To: "Theodore Ts'o" , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Disposition of the IKEv2 ID_KEY_ID type Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:12 PM -0400 4/6/04, Theodore Ts'o wrote: >It seems one >simple way of addressing this situation is to simply to revert to the >IKEv1 wording, which would simply involve deleting the phrase "to pass >an account name or" from the specification. Yes. Code re-use from IKEv1 is good. >If we were to do this, which would make the use of ID_KEY_ID >unambiguous, it raises the next question: should we create a new >identity type that contains an account name, with some kind of tight >specification about the use of UTF-8 or whatever. No. There has been no demand for it. If there is such demand, someone can later register a new ID type. We can then also test the new versioning mechanism. :-) --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Apr 7 08:38:59 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37FcxZB004659; Wed, 7 Apr 2004 08:38:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i37Expv08618 for ipsec-outgoing; Wed, 7 Apr 2004 10:59:51 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200404070910.i379AYSj002498@givry.rennes.enst-bretagne.fr> References: <200404070910.i379AYSj002498@givry.rennes.enst-bretagne.fr> Date: Wed, 7 Apr 2004 10:29:08 -0400 To: Francis Dupont From: Stephen Kent Subject: Re: CONSENSUS TEST: Fragmentation handling Cc: sommerfeld@east.sun.com, "Theodore Ts'o" , Tero Kivinen , Mohan Parthasarathy , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:10 AM +0200 4/7/04, Francis Dupont wrote: > In your previous mail you wrote: > > > => anything which tries to look at inside my packets violates my > > confidentiality, and I don't like this at all from something which > > is supposed to protect it. IMHO a router should not look at something > > which is not in the IP header, or do you argue we should only use > > IPsec end-to-end? (I am not against the idea but this is a bit drastic). > > We're talking about behavior in an IPsec implementation which enforces > policy based on port numbers. On the cleartext side, it's *already* > looking into the packet well past the ip header.. > >=> I have nothing against an IPsec implementation which enforces policy >based on port numbers and when a security gateway is colocated with >a stateful firewall this is the thing to do, so this has to be specified. >My concern is as a side effect of this specification it seems that >to enforce policy based on port numbers is RECOMMENDED. I believe the >issue is in fact in the wording... > >Thanks > >Francis.Dupont@enst-bretagne.fr Compliant IPsec implementations have always had to be able to use port numbers in SPD entries, according to 2401. What we are saying here is that IF the user/admin is using port numbers in an SPD entry, AND if he needs to accommodate fragments, THEN support for approach #3 is RECOMMENDED. But, if the IPsec implementation is not capable of supporting reassembly or equivalent, stateful processing, then it need not implement #3. Steve From owner-ipsec@lists.tislabs.com Wed Apr 7 08:39:45 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37FdiBI004717; Wed, 7 Apr 2004 08:39:44 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i37F06x08640 for ipsec-outgoing; Wed, 7 Apr 2004 11:00:06 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16499.53929.188242.629272@fireball.acr.fi> References: <16480.15529.482315.278735@fireball.acr.fi> <016c01c416c3$eb1d8270$861167c0@adithya> <16492.6896.588750.18184@fireball.acr.fi> <16493.10872.196792.111195@fireball.acr.fi> <20040406162758.GA10072@thunk.org> <1529.1081282308@marajade.sandelman.ottawa.on.ca> <16499.53929.188242.629272@fireball.acr.fi> Date: Wed, 7 Apr 2004 11:11:21 -0400 To: Tero Kivinen From: Stephen Kent Subject: Re: CONSENSUS TEST: Fragmentation handling Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:06 PM +0300 4/7/04, Tero Kivinen wrote: >Stephen Kent writes: >> > I'm unclear how a responder knows that a non-initial fragment SA is >> >being negotiated in IKE. Is it based only on the OPAQUE value as >> >port-selectors? What about the protocol? >> >> The use of OPAQUE is now restricted to carriage of non-initial >> fragments, after the change that Mark suggested. so, yes, negotiating >> an SA with port fields set to OPAQUE indicates that the SA is used to >> carry non-initial fragments. for IPv4, this is irrespective of the >> port field selector, which could be specific, or ANY. for v6, it is > ^^^^^^^^^^ > >I assume this should be "protocol field selector", not "port" whoops. yes, I meant protocol, not port. I like your suggestion of NON_FIRST_FRAGMENTS_ALSO as a notification. Steve From owner-ipsec@lists.tislabs.com Wed Apr 7 08:40:16 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37FeFJL004766; Wed, 7 Apr 2004 08:40:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i37F04m08637 for ipsec-outgoing; Wed, 7 Apr 2004 11:00:04 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <40737D8E.2020309@roc.co.in> References: <40737D8E.2020309@roc.co.in> Date: Wed, 7 Apr 2004 09:53:12 -0400 To: Ravi From: Stephen Kent Subject: Re: SPD Policies - Backward compatibility Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:33 AM +0530 4/7/04, Ravi wrote: > Hi, > Based on one of the emails, I got an impression that >rfc2401-bis is mainly > intended for IKEv2. This got me thinking on the compatibility issues. > > I would assume that, security appliances would be providing >both IKEv1/v2 > and rfc2401/2401bis implementations. In rfc2401bis and IKEv2, there is > provision for providing multiple ranges for source and >destination selectors. > But, rfc2401/ikev1 does not support this combination. Does >this mean that, the > administrator configuring security policies should have prior >(out-of-band) > knowledge on remote security gateway capabilities? This does not seem > right and I am wondering how do we achieve the backward >compatibility where > some devices are IKEv2/2401bis capable and some are not. > > Thanks > Ravi Ignoring the ugly issue of manual keying, you will certainly know whether a peer is IKEv2 capable when you try to negotiate the IKE SA. So, presumably your question is how does a user/admin set up SPD entries that take advantage of the new capabilities present in 24001bis and IKEv2, prior to knowing the capabilities of a peer? Good question. Knowing the capabilities of the peers for which you have authorized communication in the SPD is not out of the question, although I admit it is not ideal. Presumably you can start off living with the old restrictions, since they represent the status quo, and move to the new features as you become more confident that peers have upgraded as well. One might adopt a fallback approach, i.e., try to negotiate IKEv2 and if it fails, use v1, and map SPD entries into v1 equivalents, which will result in more SAs. Steve From owner-ipsec@lists.tislabs.com Wed Apr 7 08:43:05 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37Fh449005017; Wed, 7 Apr 2004 08:43:04 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i37ExSC08590 for ipsec-outgoing; Wed, 7 Apr 2004 10:59:28 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.2.0.9.0.20040406154936.039aa6c8@10.1.5.10> References: <16480.15529.482315.278735@fireball.acr.fi> <016c01c416c3$eb1d8270$861167c0@adithya> <16492.6896.588750.18184@fireball.acr.fi> <16493.10872.196792.111195@fireball.acr.fi> <5.2.0.9.0.20040406154936.039aa6c8@10.1.5.10> Date: Wed, 7 Apr 2004 10:06:01 -0400 To: vamsi From: Stephen Kent Subject: Re: CONSENSUS TEST: Fragmentation handling Cc: "Theodore Ts'o" , Tero Kivinen , Mohan Parthasarathy , 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 Vamsi, >It seems fine to me, but I have these comments. >1. Case 3 can be made as 'MAY'. >2. When case 2 is not employed and when communicating security gateways > don't agree on, as mentioned in case3, the sender implementations, in my > view, MUST not drop the packets and use mechanisms such as 'reassembly'. > So, it would be better to indicate this explicitly in the text. > >Vamsi I have no idea what you mean in comment #2 above. If an implementation does not support the fragments-only SA approach, and does not successfully negotiate an SA for which the peer agrees to accept fragments and perform some form of stateful checking, the the implementation cannot send fragments for the traffic corresponding to the SA in question. is that what you want added? Steve From owner-ipsec@lists.tislabs.com Wed Apr 7 09:17:14 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37GHDYa008335; Wed, 7 Apr 2004 09:17:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i37FYQZ11102 for ipsec-outgoing; Wed, 7 Apr 2004 11:34:26 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Wed, 7 Apr 2004 08:45:15 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: IKEv2 security consideration over-statement Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. My apologies for not seeing this sooner. In the security considerations section of IKEv2, it says: The strength of a key derived from a Diffie-Hellman exchange using any of the groups defined here depends on the inherent strength of the group, the size of the exponent used, and the entropy provided by the random number generator used. Due to these inputs it is difficult to determine the strength of a key for any of the defined groups. Diffie-Hellman group number two, when used with a strong random number generator and an exponent no less than 200 bits, is sufficient for use with 3DES. Groups three through five provide greater security. Group one is for historic purposes only and does not provide sufficient strength except for use with DES, which is also for historic use only. Implementations should make note of these conservative estimates when establishing policy and negotiating security parameters. The sentence "Diffie-Hellman group number two, when used with a strong random number generator and an exponent no less than 200 bits, is sufficient for use with 3DES" is probably not true. Group 2 (1024 bits) is probably equivalent to about 80 bits of symmetric strength, not 112. A better wording for this sentence is "Diffie-Hellman group number two, when used with a strong random number generator and an exponent no less than 200 bits, is common for use with 3DES". That is, most VPN systems only need 80ish bits of symmetric strength. The sentence "Groups three through five provide greater security" is misleading. Group 3 is 155 bits using elliptic curve, meaning about 77 bits of symmetric strength, similar to group 2. Group 4 (185 bits using elliptic curve), or 92 bits of symmetric strength. Further, to date, almost no one implements groups 3 and 4 due to lack of customer demand and looming patent issued. It is better to change this to simply say "Group five provides greater security than group two." Also, maybe drop the word "conservative" in the last sentence since it is not clear what it means. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Apr 7 09:41:02 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37Gewro010703; Wed, 7 Apr 2004 09:41:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i37FvD212408 for ipsec-outgoing; Wed, 7 Apr 2004 11:57:13 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Message-Id: <200404071609.i37G9CSj004048@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Stephen Kent cc: sommerfeld@east.sun.com, "Theodore Ts'o" , Tero Kivinen , Mohan Parthasarathy , ipsec@lists.tislabs.com Subject: Re: CONSENSUS TEST: Fragmentation handling In-reply-to: Your message of Wed, 07 Apr 2004 10:29:08 EDT. Date: Wed, 07 Apr 2004 18:09:12 +0200 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: Compliant IPsec implementations have always had to be able to use port numbers in SPD entries, according to 2401. What we are saying here is that IF the user/admin is using port numbers in an SPD entry, AND if he needs to accommodate fragments, THEN support for approach #3 is RECOMMENDED. But, if the IPsec implementation is not capable of supporting reassembly or equivalent, stateful processing, then it need not implement #3. => so the issue is a wording issue, and what you'd like to get is a SHOULD for one of the two variants (#2 & #3) for implementations which support more than #1, isn't this? The idea has to be clear in the final text, perhaps with an introduction statement to #2 and #3 at the end of #1. BTW we should swap #2 and #3 too. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Wed Apr 7 09:43:49 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37GhmiE010906; Wed, 7 Apr 2004 09:43:49 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i37FsPp12275 for ipsec-outgoing; Wed, 7 Apr 2004 11:54:25 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: CONSENSUS TEST: Fragmentation handling Date: Wed, 7 Apr 2004 17:06:35 +0100 Message-ID: <579E83556A36E44EB2945CCE990B317401371B49@EUR-MSG-02.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CONSENSUS TEST: Fragmentation handling Thread-Index: AcQb+TvjFnp7ahOJTNiRchLo0StTdAAu+ZIA From: "Michael Roe" To: "Theodore Ts'o" Cc: X-OriginalArrivalTime: 07 Apr 2004 16:06:38.0743 (UTC) FILETIME=[4EF59A70:01C41CBA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id i37FsM812270 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This proposal is OK with me, although I have a few small quibbles: (a) I'd prefer "MAY" rather than "SHOULD" for #3 (stateful fragment checking), but don't feel very strongly about it. (b) In #1, I agree with Steve Kent's proposal to have the "ANY" selector match non-initial fragments (the packets that match "OPAQUE" are a subset of the packets that match "ANY") -- See Steve's revised version of #1. (c) > determination of the "strongest" > algorithms requires imposing a total ordering of the available > algorithms, a local determination at the discretion of the initiator > of the SA.) (i) To be pedantic, you don't need a total ordering - it can work with some partial orderings. forall x in initiatorAlgorithms Less_Than_Or_Equal_Initiator (x, negotiatedAlgorithm) forall y in responderAlgorithms Less_Than_Or_Equal_Responder (y, negotiatedAlgorithm) As long as negotiatedAlgorithm exists, you're OK - Less_Than_Or_Equal_Initiator and Less_Than_Or_Equal_Responder can be partial orderings. (ii) It's not just at the discretion of the initiator. As I understand it, both intiator and responder take their local ipsec policies, and their own idea of what the ordering on algorithms is, and separately decide which algorithms are acceptable for the fragment only SA. IKE then attempts to negotiate a choice in the intersection of these two sets of acceptable algorithms. [This is just a minor quibble - I'm basically in agreement with what is being proposed] Mike > 1. All implementations MUST support tunnel mode SAs that pass traffic > without regard to port field values. If the SA will carry traffic for > specified protocols, the two selector sets MUST be used to specify > the port fields for the SA: ANY and OPAQUE. An SA defined in this > fashion will carry all traffic for the indicated source/destination > addresses and specified protocol(s). If the SA will carry traffic > without regard to a specific protocol value (i.e., ANY is specified), > then the port field values MUST be set to ANY as well. > > 2. All implementations MAY support tunnel mode SAs that will carry > only non-initial fragments, separate from non-fragmented packets and > initial fragments. The OPAQUE value will be used to specify port > field selectors for an SA to carry non-initial fragments. Specific > port selector values will be used to define SAs to carry initial > fragments and non-fragmented packets. This approach can be used if a > user or administrator wants to create one or more tunnel mode SAs > between the same source/destination addresses that discriminate based > on port fields. These SAs MUST have non-trivial protocol selector > values, otherwise approach #1 above can be used. Receivers MUST > perform a minimum offset check on IPv4 (non-initial) fragments to > protect against overlapping fragment attacks when SAs of this type > are employed. Because such checks cannot be performed on IPv6 > non-initial fragments, users and administrators are advised that > carriage of such fragments may be dangerous, and implementers may > choose to NOT support such SAs for IPv6 traffic. Also, because a SA > of this sort will carry ALL non-initial fragments that match a > specified source/destination address pair and protocol value, users > and administrators are advised to protect such traffic using ESP > (with integrity) and the "strongest" integrity and encryption > algorithms available at both peers. (Determination of the "strongest" > algorithms requires imposing a total ordering of the available > algorithms, a local determination at the discretion of the initiator > of the SA.) > > 3. An implementation SHOULD support some form of stateful > fragment checking for a tunnel mode SA with non-trivial port field > values (not ANY or OPAQUE). Implementations that will transmit > non-initial fragments on a tunnel mode SA that makes use of > non-trivial port selectors MUST notify a peer via an IKE payload > (TBD). The peer MUST reject this proposal if it will not accept > non-initial fragments in this context. If an implementation does not > successfully negotiate transmission of non-initial fragments for such > an SA, it MUST NOT send such fragments over the SA. This standard > does not specify how peers will deal with such fragments, e.g., via > reassembly or other means, at either sender or receiver. However, a > receiver MUST drop non-initial fragments that arrive on an SA with > non-trivial port selector values unless this feature has been > negotiated. Dropping such packets is an auditable event. Note that in > configurations where fragments of a packet might be sent or received > via different security gateways or BITW implementations, stateful > strategies for tracking fragments may fail. > From owner-ipsec@lists.tislabs.com Wed Apr 7 10:23:09 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37HN8vR013853; Wed, 7 Apr 2004 10:23:08 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i37GUpd14344 for ipsec-outgoing; Wed, 7 Apr 2004 12:30:51 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Message-ID: <004701c41cbf$5d761ed0$6401a8c0@adithya> From: "Mohan Parthasarathy" To: , "Theodore Ts'o" References: Subject: Re: Disposition of the IKEv2 ID_KEY_ID type Date: Wed, 7 Apr 2004 09:42:49 -0700 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 > > Discussion on this topic has died down, so here is my attempt to try to > summarize the discussion. The main concern seems to be due to the > phrase "an account name" in the following text from the ikev2 draft: > > ID_KEY_ID 11 > > An opaque octet stream which may be used to pass an account > name or to pass vendor-specific information necessary to do > certain proprietary types of identification. > > Specifically, the pandora's box which gets opened once "an account name" > is added is the dreaded internationalization question. It seems one > simple way of addressing this situation is to simply to revert to the > IKEv1 wording, which would simply involve deleting the phrase "to pass > an account name or" from the specification. This would leave ID_KEY_ID > as being nothing more than a private use field that can be used between > consenting clients and servers to pass a vendor- or site- specific > identification. > > If we were to do this, which would make the use of ID_KEY_ID > unambiguous, it raises the next question: should we create a new > identity type that contains an account name, with some kind of tight > specification about the use of UTF-8 or whatever. Noting that we > already have support for an X.500 General Name, which does have > internationalization support in it already, I am going to suggest that > we do *not* try to define some kind of new account name identity type at > this time. > > If there is a desire for such a new identity type, it will always be > possible to define a new type in another RFC. But given that IKEv2 is > currently in last call, it doesn't seem like it's the time now to try to > add new identity types.... > > Is this an outcome that most people on the list could live with? > I am fine with this. But note that this discussion came out of an issue that was raised against 2401bis. Steve later clarified that contents of ID_KEY_ID would be added (clarified) as another selector in 2401bis. Perhaps, you were planning to summarize under a different subject ? -mohan > - Ted From owner-ipsec@lists.tislabs.com Wed Apr 7 12:02:40 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37J2ecZ022527; Wed, 7 Apr 2004 12:02:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i37IAPK19868 for ipsec-outgoing; Wed, 7 Apr 2004 14:10:25 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <004701c41cbf$5d761ed0$6401a8c0@adithya> References: <004701c41cbf$5d761ed0$6401a8c0@adithya> Date: Wed, 7 Apr 2004 14:09:16 -0400 To: "Mohan Parthasarathy" From: Stephen Kent Subject: Re: Disposition of the IKEv2 ID_KEY_ID type 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 9:42 AM -0700 4/7/04, Mohan Parthasarathy wrote: > > If there is a desire for such a new identity type, it will always be >> possible to define a new type in another RFC. But given that IKEv2 is >> currently in last call, it doesn't seem like it's the time now to try to >> add new identity types.... >> >> Is this an outcome that most people on the list could live with? >> >I am fine with this. > >But note that this discussion came out of an issue that was >raised against 2401bis. Steve later clarified that contents of ID_KEY_ID >would be added (clarified) as another selector in 2401bis. Perhaps, >you were planning >to summarize under a different subject ? > >-mohan > ID_KEY_ID is not a selector. It is a type of IKE ID and thus could be a candidate for the Name selector. Since we have decided that this ID is not used to identity users in the same way as, say, RFC822 names, it may or may not be appropriate. Steve From owner-ipsec@lists.tislabs.com Wed Apr 7 12:05:20 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37J5JPl022685; Wed, 7 Apr 2004 12:05:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i37INs620658 for ipsec-outgoing; Wed, 7 Apr 2004 14:23:54 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16500.18945.366270.796202@gargle.gargle.HOWL> Date: Wed, 7 Apr 2004 14:35:45 -0400 From: Paul Koning To: paul.hoffman@vpnc.org Cc: ipsec@lists.tislabs.com Subject: Re: IKEv2 security consideration over-statement References: X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "PaulH" == Paul Hoffman > writes: PaulH> The sentence "Diffie-Hellman group number two, when used with a PaulH> strong random number generator and an exponent no less than 200 PaulH> bits, is sufficient for use with 3DES" is probably not PaulH> true. Group 2 (1024 bits) is probably equivalent to about 80 PaulH> bits of symmetric strength, not 112. A better wording for this PaulH> sentence is "Diffie-Hellman group number two, when used with a PaulH> strong random number generator and an exponent no less than 200 PaulH> bits, is common for use with 3DES". That is, most VPN systems PaulH> only need 80ish bits of symmetric strength. Sounds reasonable. That suggests that a VPN application where this is true might also find it sensible to use group 2 with AES, even though in both cases the "net" security is somewhat less than the data cipher keysize. PaulH> The sentence "Groups three through five provide greater PaulH> security" is misleading.... PaulH> It is better to change this to simply say "Group PaulH> five provides greater security than group two." Yes, I agree that that's a necessary change. paul From owner-ipsec@lists.tislabs.com Wed Apr 7 12:14:51 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37JEoGl023479; Wed, 7 Apr 2004 12:14:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i37IZe221221 for ipsec-outgoing; Wed, 7 Apr 2004 14:35:40 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f x-mimeole: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IKEv2 and IANA registry Date: Wed, 7 Apr 2004 11:47:43 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IKEv2 and IANA registry Thread-Index: AcQbbfjh7ZdThuqqRrGUoTeo9cSOIQAlTwmA From: "Charlie Kaufman" To: "Kevin Li" , X-OriginalArrivalTime: 07 Apr 2004 18:47:53.0763 (UTC) FILETIME=[D5B87F30:01C41CD0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id i37IZc821218 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There are number of minor inconsistencies between ikev2-13 and ikev2-iana-01, of which the one you point out is the only really important one. I've been meaning to post a list so we can decide which document to change in each case. There was an error in ikev2-10(?) and prior where the security protocol ID was listed with two different sets of values in two places. The IANA document reflected this by having two different protocol ID registries with slightly different names with the different values. ('IKEv2 Security Protocol Identifiers' has the correct values; 'IKEv2 Proposal Substructure Protocol-IDs' has the incorrect values.). The fix is for the iana document to remove the second registry. The other inconsistencies are: 1) The ikev2-13 document lists all registries as being updated by expert review; the ikev2-iana-01 document lists them as updated by different means. Ikev2-13 reflects working group consensus reached after the iana document was published. 2) For pseudo-random transform type 2, the ikev2-13 document defines AUTH_AES_XCBC_96 5 I don't know the story here; perhaps this algorithm was added late, or perhaps it should be removed as an inappropriate PRF. 3) For Extended Sequence Numbers Transform Type 5, (0=NO; 1=YES), the iana document lists values 2-65535 as reserved to IANA (thus creating a registry). In the ikev2-13, they are RESERVED (avoiding the need for a registry). I believe no registry is needed; I doubt any expert would approve creation of a new value for a Boolean. 4) For Identification Payload ID types, the iana document says the values 12-255 are reserved to iana. Ikev2-13 says 12-200 are reserved to iana and 201-255 are for private use. 5) ikev2-13 has notification types apparently defined since the iana document: INVALID_SELECTORS 39 ESP_TFC_PADDING_NOT_SUPPORTED 16394 6) For traffic selector types, the iana document says types 9-255 are reserved to iana; ikev2-13 says 9-240 are reserved to iana and 241-255 are for private use. --Charlie -----Original Message----- From: Kevin Li [mailto:kli@cisco.com] Sent: Monday, April 05, 2004 5:28 PM To: Charlie Kaufman; ipsec@lists.tislabs.com Cc: kli@cisco.com Subject: IKEv2 and IANA registry Hi, I have two questions. 1. For protocol id in proposal payload, there is an inconsistency between draft-ietf-ipsec-ikev2-13.txt and draft-ietf-ipsec-ikev2-iana-01.txt The ikev2-13.txt defines: Protocol Protocol ID RESERVED 0 IKE 1 AH 2 ESP 3 RESERVED TO IANA 4-200 PRIVATE USE 201-255 The ikev2-iana-01.txt defines Attribute Type value ------------------------------------- IKE 0 AH 1 ESP 2 RESERVED TO IANA 3-255 Which one should be used? In general, if there is a conflict between protocol specification and iana, which one should be used? 2. What's the current status of standardizing/fianlizing IKEv2 protocol specification? I am afraid our implementation based on IKEv2-13 will not inter-operate with future standard version which other verdor implementations will base on. Shall we wait until the standard comes out? Please include me in the reply list as I haven't subcribed (in process) to the ipsec@lists.tislabs.com yet. Thank you very much. Kevin Cisco Systems From owner-ipsec@lists.tislabs.com Wed Apr 7 12:45:53 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37JjqZh025643; Wed, 7 Apr 2004 12:45:52 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i37J7p422680 for ipsec-outgoing; Wed, 7 Apr 2004 15:07:51 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Message-ID: <00c701c41cd5$35f95140$6401a8c0@adithya> From: "Mohan Parthasarathy" To: "Stephen Kent" Cc: References: <004701c41cbf$5d761ed0$6401a8c0@adithya> Subject: Re: Disposition of the IKEv2 ID_KEY_ID type Date: Wed, 7 Apr 2004 12:19:12 -0700 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 > > > > If there is a desire for such a new identity type, it will always be > >> possible to define a new type in another RFC. But given that IKEv2 is > >> currently in last call, it doesn't seem like it's the time now to try to > >> add new identity types.... > >> > >> Is this an outcome that most people on the list could live with? > >> > >I am fine with this. > > > >But note that this discussion came out of an issue that was > >raised against 2401bis. Steve later clarified that contents of ID_KEY_ID > >would be added (clarified) as another selector in 2401bis. Perhaps, > >you were planning > >to summarize under a different subject ? > > > >-mohan > > > > ID_KEY_ID is not a selector. It is a type of IKE ID and thus could be > a candidate for the Name selector. Since we have decided that this ID Yes, that's what i meant. > is not used to identity users in the same way as, say, RFC822 names, > it may or may not be appropriate. > Hmm.. i thought that the email thread did discuss the current uses and the general usefulness of it. Perhaps, we need a separate consensus test for it ? -mohan > Steve From owner-ipsec@lists.tislabs.com Wed Apr 7 13:20:41 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37KKevW028480; Wed, 7 Apr 2004 13:20:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i37JaFC23907 for ipsec-outgoing; Wed, 7 Apr 2004 15:36:15 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Wed, 7 Apr 2004 12:47:08 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: RE: IKEv2 and IANA registry Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It sounds like the draft-ietf-ipsec-ikev2-iana needs to be updated. At 11:47 AM -0700 4/7/04, Charlie Kaufman wrote: >2) For pseudo-random transform type 2, the ikev2-13 document defines > > AUTH_AES_XCBC_96 5 > >I don't know the story here; perhaps this algorithm was added late, or >perhaps it should be removed as an inappropriate PRF. It should instead say "AES-XCBC-PRF-128" and reference RFC 3664. >3) For Extended Sequence Numbers Transform Type 5, (0=NO; 1=YES), the >iana document lists values 2-65535 as reserved to IANA (thus creating a >registry). In the ikev2-13, they are RESERVED (avoiding the need for a >registry). I believe no registry is needed; I doubt any expert would >approve creation of a new value for a Boolean. Fully agree. >4) For Identification Payload ID types, the iana document says the >values 12-255 are reserved to iana. Ikev2-13 says 12-200 are reserved to >iana and 201-255 are for private use. It would be very good to have private use ID payloads. >6) For traffic selector types, the iana document says types 9-255 are >reserved to iana; ikev2-13 says 9-240 are reserved to iana and 241-255 >are for private use. It would be very good to have private use traffic selectors. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Apr 7 14:46:39 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37Lkco1034840; Wed, 7 Apr 2004 14:46:39 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i37L8iS28204 for ipsec-outgoing; Wed, 7 Apr 2004 17:08:44 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <579E83556A36E44EB2945CCE990B317401371B49@EUR-MSG-02.europe.corp.microsoft .com> References: <579E83556A36E44EB2945CCE990B317401371B49@EUR-MSG-02.europe.corp.microsoft .com> Date: Wed, 7 Apr 2004 17:19:31 -0400 To: "Michael Roe" From: Stephen Kent Subject: RE: CONSENSUS TEST: Fragmentation handling Cc: "Theodore Ts'o" , 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 5:06 PM +0100 4/7/04, Michael Roe wrote: >This proposal is OK with me, although I have a few small quibbles: > >(a) I'd prefer "MAY" rather than "SHOULD" for #3 (stateful fragment > checking), but don't feel very strongly about it. if neither #2 or #3 is a SHOULD, then I would like to add text that every implementation MUST implement at least one of these, to give us a decent chance of having a way to accommodate fragments for port-specific SAs. in fact, maybe that is the best way to state this, given the current set of comments on this topic. >(b) In #1, I agree with Steve Kent's proposal to have the "ANY" selector > match non-initial fragments (the packets that match "OPAQUE" are > a subset of the packets that match "ANY") -- See Steve's revised version > of #1. > >(c) > determination of the "strongest" > > algorithms requires imposing a total ordering of the available > > algorithms, a local determination at the discretion of the initiator > > of the SA.) > > (i) To be pedantic, you don't need a total ordering - it can work with > some partial orderings. > > forall x in initiatorAlgorithms > Less_Than_Or_Equal_Initiator (x, negotiatedAlgorithm) > > forall y in responderAlgorithms > Less_Than_Or_Equal_Responder (y, negotiatedAlgorithm) > > As long as negotiatedAlgorithm exists, you're OK - > Less_Than_Or_Equal_Initiator and Less_Than_Or_Equal_Responder > can be partial orderings. > > (ii) It's not just at the discretion of the initiator. As I understand it, > both intiator and responder take their local ipsec policies, > and their own idea of what the ordering on algorithms is, >and separately > decide which algorithms are acceptable for the fragment >only SA. IKE then > attempts to negotiate a choice in the intersection of these >two sets of > acceptable algorithms. I thought that a responder may choose only from among the set of proposals the initiator offers. if so, then the intitiator could look at all of the alg suites that he would use for any traffic that is to be protected when negotiating SAs for the peer in question, and choose the strongest as the only one proposed. If he imposed a total ordering, this would be possible. It is not clear that, in practice, people select different alg suites on a per-peer basis, and we do have mandatory to implement defaults. So, if the defaults are good, it is not clear that we would have problems. in the past, when DES was the default, it was probably common to see folks negotiate "up" to a better algorithm, but going forward this would seem to be a moot issue. Steve From owner-ipsec@lists.tislabs.com Wed Apr 7 14:48:15 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37LmFFL035148; Wed, 7 Apr 2004 14:48:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i37LAhj28312 for ipsec-outgoing; Wed, 7 Apr 2004 17:10:43 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200404071609.i37G9CSj004048@givry.rennes.enst-bretagne.fr> References: <200404071609.i37G9CSj004048@givry.rennes.enst-bretagne.fr> Date: Wed, 7 Apr 2004 17:20:53 -0400 To: Francis Dupont From: Stephen Kent Subject: Re: CONSENSUS TEST: Fragmentation handling Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:09 PM +0200 4/7/04, Francis Dupont wrote: > In your previous mail you wrote: > > Compliant IPsec implementations have always had to be able to use > port numbers in SPD entries, according to 2401. What we are saying > here is that IF the user/admin is using port numbers in an SPD entry, > AND if he needs to accommodate fragments, THEN support for approach > #3 is RECOMMENDED. But, if the IPsec implementation is not capable of > supporting reassembly or equivalent, stateful processing, then it > need not implement #3. > >=> so the issue is a wording issue, and what you'd like to get is >a SHOULD for one of the two variants (#2 & #3) for implementations >which support more than #1, isn't this? The idea has to be clear >in the final text, perhaps with an introduction statement to #2 and #3 >at the end of #1. BTW we should swap #2 and #3 too. #1 is a MUST, so there is no ambiguity there, and, so far no disagreement. I want every implementation to support either #2 or #3, so that we have a good chance of having some way to accommodate fragments for port-specific SAs. Maybe we should just say that every implementation MUST support either #2 of #3. Steve From owner-ipsec@lists.tislabs.com Wed Apr 7 15:04:04 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i37M43lP036687; Wed, 7 Apr 2004 15:04:04 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i37LQBE29282 for ipsec-outgoing; Wed, 7 Apr 2004 17:26:11 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Message-Id: <200404072102.i37L21Fl008098@rs9.luxsci.com> From: "William Dixon" To: "'Theodore Ts'o'" Cc: "'Stephen Kent'" , Subject: RE: Issue 83 will be withdrawn Date: Wed, 7 Apr 2004 17:01:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <20040406191112.GE10329@thunk.org> X-Lux-Comment: LuxSci remailer message ID code - 1081371721-8924342.37994905 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thank Ted & Steve for the explanations. I apologize for the delay. Unfortunately, I'm not in a position to argue why this is a good thing, not just a troubleshooting aid. I agree that for dedicated purpose IPsec implementations this ICMP is not required - but then neither perhaps is interoperability... I'll note that host OS IPsec implementations (or some combination of code within the stack) already have to process the ICMP Dest Unreachable for TCP PMTU. It may not actually be "the IPsec driver or component" exactly that does the processing. The discussion here sounds like you are not considering all aspects of the host OS TCP/IP stack functionality involved in enabling IPsec. I'm very concerned that host OS implementers are not speaking up on issues, given that they can fully change any part of the stack they want to when they integrate IPsec functionality into the release, and they may be faced with greater needs for interoperability. Since I've been the only one recently interested, drop away... > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Theodore Ts'o > Sent: Tuesday, April 06, 2004 3:11 PM > To: William Dixon > Cc: 'Stephen Kent'; ipsec@lists.tislabs.com > Subject: Re: Issue 83 will be withdrawn > > William, > > The discussion (what little there was of it) basically > revolved around doing the following: > > * Making generation of the ICMP messages a "MUST" > * Making generation of the ICMP messages a "SHOULD" > * Making generation of the ICMP messages a "MAY" > * Not talking ICMP messages at all (which is what we > did in IKEv1) > > The concern with "MUST" was that this would be problematic > for high-speed IPSEC devices. > > The concern with "SHOULD" was that from the point of RFP's, > SHOULD often turn into "MUST"'s, and this would be painful > for some vendor. > > The argument against "MAY" was that given that the ICMP codes > were already defined, there was no value in reprinting them here. > > When this issue was raised, there was relatively little > discussion, which is why we settled on simply dropping issue > #83. So I wouldn't necessarily characterize this as a > consensus decision, as much as a decision based on Apathy.... > > Does this satisfy your concerns, or would you like make an > argument for one of the other above options? > > - Ted > > From owner-ipsec@lists.tislabs.com Wed Apr 7 17:05:12 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3805B2C045896; Wed, 7 Apr 2004 17:05:11 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i37NSKL08887 for ipsec-outgoing; Wed, 7 Apr 2004 19:28:20 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Message-ID: <40749198.80207@cisco.com> Date: Wed, 07 Apr 2004 16:41:12 -0700 From: Kevin Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charlie Kaufman , ipsec@lists.tislabs.com Subject: IKEv2 Standardization Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Charlie and IKEv2 folks, I am separating this question from another email thread to be more specific. We like the simplicity, effeciency and clarity of IKEv2, and have projects implementing it on various Cisco's products. However, I am a little bit concerned that our implementation based on current IKEv2 spec won't interoperate with products from other vendors based on the standard IKEv2 (future). There have been some update activitities on IKEv2 protocol spec, the latest version now is IKEv2-13. I am wondering how far away IKEv2 spec is from standardization? Will it take another half a year or more? It would definitely help if we could get some sense of how mature the IKEv2-13 is from the IKEv2 experts' point of view. Thank you very much. Kevin Li Cisco Systems From owner-ipsec@lists.tislabs.com Wed Apr 7 17:32:09 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i380W8tL047755; Wed, 7 Apr 2004 17:32:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i37NtRd11164 for ipsec-outgoing; Wed, 7 Apr 2004 19:55:27 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f x-mimeole: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IKEv2 Standardization Date: Wed, 7 Apr 2004 17:05:11 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IKEv2 Standardization Thread-Index: AcQc+ZsgbB0cMMLXQteisVwyM8l1eAAAc5UQ From: "Charlie Kaufman" To: "Kevin Li" , X-OriginalArrivalTime: 08 Apr 2004 00:06:02.0074 (UTC) FILETIME=[473D9BA0:01C41CFD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id i37NtK811143 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The only analogy I can think of is being pecked to death by ducks. IKEv2 has been on final drafts for over a year, and was pretty much done a year before that. It will never be the case that there is nothing anyone can think of to 'improve'. I don't know how to make it stop. >Will it take another half a year or more? I would confidently say 'certainly not' except I've said that so many times that I'm no longer credible even to myself. --Charlie -----Original Message----- From: Kevin Li [mailto:kli@cisco.com] Sent: Wednesday, April 07, 2004 4:41 PM To: Charlie Kaufman; ipsec@lists.tislabs.com Subject: IKEv2 Standardization Hi Charlie and IKEv2 folks, I am separating this question from another email thread to be more specific. We like the simplicity, effeciency and clarity of IKEv2, and have projects implementing it on various Cisco's products. However, I am a little bit concerned that our implementation based on current IKEv2 spec won't interoperate with products from other vendors based on the standard IKEv2 (future). There have been some update activitities on IKEv2 protocol spec, the latest version now is IKEv2-13. I am wondering how far away IKEv2 spec is from standardization? Will it take another half a year or more? It would definitely help if we could get some sense of how mature the IKEv2-13 is from the IKEv2 experts' point of view. Thank you very much. Kevin Li Cisco Systems From Administration@computeradmin.org Wed Apr 7 21:11:04 2004 Received: from 208.184.76.50 ([61.11.73.142]) by above.proper.com (8.12.11/8.12.8) with SMTP id i384ArCV062594; Wed, 7 Apr 2004 21:10:58 -0700 (PDT) (envelope-from Administration@computeradmin.org) Received: from gl3.3n4x99.net ([94.178.132.50]) by 208.184.76.50; Thu, 08 Apr 2004 09:14:29 +0400 Message-ID: <6ow73yf-g$5v$9$u1$9fd43kx77o19@g7zh07gv1> From: "Admin" To: nk@vpnc.org Subject: ADV: Attention All Nonprofit Orgs: (Members, Staff and Associates): Date: Thu, 08 Apr 04 09:14:29 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="B.D_2E9F9.E" This is a multi-part message in MIME format. --B.D_2E9F9.E Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Nonprofit Organizations, Members, Staff and Associates: You Must Respond By 5 P.M. Friday, April 9, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Members, Staff and Associates who respond to this message before 5 P.M., Friday, April 9, 2004. All desktop computers are brand-new packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2004 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktop Computers with the latest Intel technology at an amazing price to all who call: 1-800-884-9510 by 5 P.M. Friday, April 9, 2004 The fast and powerful AT-2400 series Desktop features: * Intel 2.0Ghz Processor for amazing speed and performance * 128MB DDR RAM, --- Upgradeable to 1024 * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW * 1.44 Floppy disk drive * Next Generation Technology * ATI Premium video and sound * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $699 ........................................ Your Cost $297 How to qualify: 1. You must be a Member, Staff or Associate of a Nonprofit: 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-884-9510 by 5 P.M. Friday, April 9, 2004 and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. Call Avtech Direct 1-800-884-9510 before 5 P.M. Friday, April 9, 2004 If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp --B.D_2E9F9.E-- From owner-ipsec@lists.tislabs.com Wed Apr 7 22:21:28 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i385LRQI071369; Wed, 7 Apr 2004 22:21:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i384hjp08721 for ipsec-outgoing; Thu, 8 Apr 2004 00:43:45 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f X-MessageWall-Score: 0 (roc.co.in) Message-ID: <4074D148.6000206@roc.co.in> Date: Thu, 08 Apr 2004 09:42:56 +0530 From: Ravi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent CC: ipsec@lists.tislabs.com Subject: Re: SPD Policies - Backward compatibility References: <40737D8E.2020309@roc.co.in> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk OK. Thank you for your and Tero's answers on this subject. In site-to-site scenario, I also feel that, it can be assumed that administrator need to know the capabilities of peer gateway. But this would be a problem in remote access scenario, where peers are unknown. Since, rfc2401 capabilities can be exchanged using both IKEv1/v2, as you indicated, policies can be configured with capabilities given in rfc2401. I think I can live with this, rather than creating multiple (could be very high) SA tunnels for each remote user. Thanks Ravi Stephen Kent wrote: > At 9:33 AM +0530 4/7/04, Ravi wrote: > >> Hi, >> Based on one of the emails, I got an impression that >> rfc2401-bis is mainly >> intended for IKEv2. This got me thinking on the compatibility >> issues. >> >> I would assume that, security appliances would be providing >> both IKEv1/v2 >> and rfc2401/2401bis implementations. In rfc2401bis and IKEv2, >> there is >> provision for providing multiple ranges for source and >> destination selectors. >> But, rfc2401/ikev1 does not support this combination. Does >> this mean that, the >> administrator configuring security policies should have prior >> (out-of-band) >> knowledge on remote security gateway capabilities? This does >> not seem >> right and I am wondering how do we achieve the backward >> compatibility where >> some devices are IKEv2/2401bis capable and some are not. >> >> Thanks >> Ravi > > > Ignoring the ugly issue of manual keying, you will certainly know > whether a peer is IKEv2 capable when you try to negotiate the IKE SA. > So, presumably your question is how does a user/admin set up SPD > entries that take advantage of the new capabilities present in > 24001bis and IKEv2, prior to knowing the capabilities of a peer? Good > question. > > Knowing the capabilities of the peers for which you have authorized > communication in the SPD is not out of the question, although I admit > it is not ideal. Presumably you can start off living with the old > restrictions, since they represent the status quo, and move to the new > features as you become more confident that peers have upgraded as > well. One might adopt a fallback approach, i.e., try to negotiate > IKEv2 and if it fails, use v1, and map SPD entries into v1 > equivalents, which will result in more SAs. > > Steve > From owner-ipsec@lists.tislabs.com Thu Apr 8 00:47:40 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i387leX6025212; Thu, 8 Apr 2004 00:47:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i3875Tv21603 for ipsec-outgoing; Thu, 8 Apr 2004 03:05:29 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f X-MessageWall-Score: 0 (roc.co.in) Message-ID: <4074FC8D.2020102@roc.co.in> Date: Thu, 08 Apr 2004 12:47:33 +0530 From: Ravi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: SPD Policies - Backward compatibility References: <40737D8E.2020309@roc.co.in> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk OK. Thank you for your and Tero's answers on this subject. In site-to-site scenario, I also feel that, it can be assumed that administrator need to know the capabilities of peer gateway. But this would be a problem in remote access scenario, where peers are unknown. Since, rfc2401 capabilities can be exchanged using both IKEv1/v2, as you indicated, policies can be configured with capabilities given in rfc2401. I think I can live with this, rather than creating multiple (could be very high) SA tunnels for each remote user. Thanks Ravi Stephen Kent wrote: > At 9:33 AM +0530 4/7/04, Ravi wrote: > >> Hi, >> Based on one of the emails, I got an impression that >> rfc2401-bis is mainly >> intended for IKEv2. This got me thinking on the compatibility >> issues. >> >> I would assume that, security appliances would be providing >> both IKEv1/v2 >> and rfc2401/2401bis implementations. In rfc2401bis and IKEv2, >> there is >> provision for providing multiple ranges for source and >> destination selectors. >> But, rfc2401/ikev1 does not support this combination. Does >> this mean that, the >> administrator configuring security policies should have prior >> (out-of-band) >> knowledge on remote security gateway capabilities? This does >> not seem >> right and I am wondering how do we achieve the backward >> compatibility where >> some devices are IKEv2/2401bis capable and some are not. >> >> Thanks >> Ravi > > > Ignoring the ugly issue of manual keying, you will certainly know > whether a peer is IKEv2 capable when you try to negotiate the IKE SA. > So, presumably your question is how does a user/admin set up SPD > entries that take advantage of the new capabilities present in > 24001bis and IKEv2, prior to knowing the capabilities of a peer? Good > question. > > Knowing the capabilities of the peers for which you have authorized > communication in the SPD is not out of the question, although I admit > it is not ideal. Presumably you can start off living with the old > restrictions, since they represent the status quo, and move to the new > features as you become more confident that peers have upgraded as > well. One might adopt a fallback approach, i.e., try to negotiate > IKEv2 and if it fails, use v1, and map SPD entries into v1 > equivalents, which will result in more SAs. > > Steve > From owner-ipsec@lists.tislabs.com Thu Apr 8 02:33:50 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i389XovZ061193; Thu, 8 Apr 2004 02:33:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i388w7n02159 for ipsec-outgoing; Thu, 8 Apr 2004 04:58:07 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Message-ID: <1e1401c41d49$9801a800$4406a8c0@leila> From: "Muriel Souville" To: "Ipsec@Lists. Tislabs. Com" Subject: ETSI Interoperability Event Date: Thu, 8 Apr 2004 11:12:18 +0200 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear all, As you probably know, The European Telecommunications Standards Institute (ETSI) is organising an interoperability event in the field of security. We already have many participants working on PKIs and XadES. But some of them are also interested in testing IKEv2, that's why we are searching new actors working on this field. I remind you that the deadline is the 5th of May. If you are interested in, please contact us at interop@actimage.net or just take a look at http://www.etsi.org/plugtests/security.htm Thanks for your attention. Best regards, Muriel SOUVILLE ETSI Consultant ----------------------------- +33 3 90 23 63 From owner-ipsec@lists.tislabs.com Thu Apr 8 04:58:23 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38BwNA6073948; Thu, 8 Apr 2004 04:58:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i38BMCI14396 for ipsec-outgoing; Thu, 8 Apr 2004 07:22:12 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f 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: <16501.14558.282707.461014@fireball.acr.fi> Date: Thu, 8 Apr 2004 14:34:54 +0300 From: Tero Kivinen To: Stephen Kent Cc: "Michael Roe" , "Theodore Ts'o" , Subject: RE: CONSENSUS TEST: Fragmentation handling In-Reply-To: References: <579E83556A36E44EB2945CCE990B317401371B49@EUR-MSG-02.europe.corp.microsoft .com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 2 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > if neither #2 or #3 is a SHOULD, then I would like to add text that > every implementation MUST implement at least one of these, to give us > a decent chance of having a way to accommodate fragments for > port-specific SAs. in fact, maybe that is the best way to state this, > given the current set of comments on this topic. Then we can have two implementations both implementing different parts of that MUST and they do not interoperate. Also the case #3 can also be used with IPv6, and the case #2 cannot securely be used with it, so I think it is better to have case #3 as SHOULD and case #2 MAY. I do not think we need requirement for "MUST" for at least one, as there will be implementations which do not care about port selectors and/or fragments. -- kivinen@safenet-inc.com From owner-ipsec@lists.tislabs.com Thu Apr 8 06:53:16 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38DrGo8082566; Thu, 8 Apr 2004 06:53:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i38DC8g23318 for ipsec-outgoing; Thu, 8 Apr 2004 09:12:08 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f To: Paul Hoffman / VPNC cc: ipsec@lists.tislabs.com Subject: Re: IKEv2 and IANA registry In-Reply-To: Message from Paul Hoffman / VPNC of "Wed, 07 Apr 2004 12:47:08 PDT." References: X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Thu, 08 Apr 2004 09:22:53 -0400 Message-ID: <1682.1081430573@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "VPNC" == VPNC writes: VPNC> It sounds like the draft-ietf-ipsec-ikev2-iana needs to be VPNC> updated. I made the below changes to the document. Is it worth resubmitting it? -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Thu Apr 8 08:02:47 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38F2kcC088050; Thu, 8 Apr 2004 08:02:46 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i38EIOj29433 for ipsec-outgoing; Thu, 8 Apr 2004 10:18:25 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16501.25038.397000.682666@gargle.gargle.HOWL> Date: Thu, 8 Apr 2004 10:29:34 -0400 From: Paul Koning To: kivinen@iki.fi Cc: kent@bbn.com, mroe@microsoft.com, tytso@mit.edu, ipsec@lists.tislabs.com Subject: RE: CONSENSUS TEST: Fragmentation handling References: <579E83556A36E44EB2945CCE990B317401371B49@EUR-MSG-02.europe.corp.microsoft .com> <16501.14558.282707.461014@fireball.acr.fi> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Tero" == Tero Kivinen writes: Tero> Stephen Kent writes: >> if neither #2 or #3 is a SHOULD, then I would like to add text >> that every implementation MUST implement at least one of these, to >> give us a decent chance of having a way to accommodate fragments >> for port-specific SAs. in fact, maybe that is the best way to >> state this, given the current set of comments on this topic. Tero> Then we can have two implementations both implementing Tero> different parts of that MUST and they do not interoperate. Agreed. There really isn't any point in saying "you MUST do at least one of x and y". From an interop point of view "you SHOULD do both x and y" is no worse and probably better. With either text, you have no guarantee of interoperability. The only way to guarantee interoperability is to have "you MUST do x". If we can get consensus on that (re #2 and #3), fine. If not, then weonly have #1 (not port specific) as guaranteed interoperable. Personally I think that is sufficient. paul From owner-ipsec@lists.tislabs.com Thu Apr 8 09:58:01 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38Gw0K3096353; Thu, 8 Apr 2004 09:58:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i38GGQq11361 for ipsec-outgoing; Thu, 8 Apr 2004 12:16:26 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <1682.1081430573@marajade.sandelman.ottawa.on.ca> References: <1682.1081430573@marajade.sandelman.ottawa.on.ca> Date: Thu, 8 Apr 2004 09:29:04 -0700 To: Michael Richardson From: Paul Hoffman / VPNC Subject: Re: IKEv2 and IANA registry Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:22 AM -0400 4/8/04, Michael Richardson wrote: > >>>>> "VPNC" == VPNC writes: > VPNC> It sounds like the draft-ietf-ipsec-ikev2-iana needs to be > VPNC> updated. > > I made the below changes to the document. > Is it worth resubmitting it? Absolutely. Given the problems we have had with agreeing on this part of yours and Charlie's and Jeff's documents, it is important to see the changes as soon as possible. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Apr 8 13:00:23 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38K0M2M006836; Thu, 8 Apr 2004 13:00:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i38J2sl11971 for ipsec-outgoing; Thu, 8 Apr 2004 15:02:54 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Date: Thu, 8 Apr 2004 15:15:34 -0400 From: "Theodore Ts'o" To: Michael Richardson Cc: Paul Hoffman / VPNC , ipsec@lists.tislabs.com Subject: Re: IKEv2 and IANA registry Message-ID: <20040408191534.GA8105@thunk.org> References: <1682.1081430573@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1682.1081430573@marajade.sandelman.ottawa.on.ca> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Apr 08, 2004 at 09:22:53AM -0400, Michael Richardson wrote: > > >>>>> "VPNC" == VPNC writes: > VPNC> It sounds like the draft-ietf-ipsec-ikev2-iana needs to be > VPNC> updated. > > I made the below changes to the document. > Is it worth resubmitting it? Yes. We want to be able to point the IANA at an I-D that is exactly the way we want it. - Ted From owner-ipsec@lists.tislabs.com Thu Apr 8 20:54:12 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i393sBK5045622; Thu, 8 Apr 2004 20:54:11 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i393CRi21896 for ipsec-outgoing; Thu, 8 Apr 2004 23:12:27 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Message-Id: <5.2.0.9.0.20040408175747.029c9e10@10.1.5.10> X-Sender: vamsi@10.1.5.10 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 08 Apr 2004 20:20:50 -0700 To: ipsec@lists.tislabs.com From: vamsi Subject: Question about Version Numbers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Friends, In IKEv2 of section 2.5 Version Numbers and Forward Compatibility ,the text says ".....If Alice is capable of speaking versions n, n+1, and n+2, and Bob is capable of speaking versions n and n+1, then they will negotiate speaking n+1, where Alice will set the flag indicating ability to speak a higher version. If they mistakenly (perhaps through an active attacker sending error messages) negotiate to version n, then both will notice that the other side can support a higher version number, and they MUST break the connection and reconnect using version n+1." Let us assume the following scenario Alice has sent the message with version n+2 to Bob and in between the attacker 'yyy' has tricked to make Alice to use version 'n'. So the next message from Alice with version 'n' and enabling the Flag (which indicates that Alice support higher version) is sent to the BOB and he(BOB) will sent the second message with version 'n' and flag enabled(which indicates that BOB supports higher version) . Then draft says "they MUST break the connection and reconnect using version n+1." So Alice again start with version 'n+1' and the attacker again trick him to use version 'n' or the attacker even trick the Alice by sending with n+1 version and flag(that indicates the higher version) enabled where Bob doesn't even support higher version than n+1 and there by attacker succeeds interrupting the IKE exchanges . My doubt is that are we not going in a loop?? My feeling is that the text should be as follows ".....If Alice is capable of speaking versions n, n+1, and n+2, and Bob is capable of speaking versions n and n+1, then they will negotiate speaking n+1, where Alice will set the flag indicating ability to speak a higher version. If they mistakenly (perhaps through an active attacker sending error messages) negotiate to version n, then both will notice that the other side can support a higher version number, and they SHOULD continue and SHOULD audit the event" Thanks Vamsi CTO Office Intoto Inc. www.intoto.com From Administration@computeradmin.org Thu Apr 8 20:58:56 2004 Received: from 208.184.76.50 ([211.42.111.200]) by above.proper.com (8.12.11/8.12.8) with SMTP id i393wm0b046108; Thu, 8 Apr 2004 20:58:52 -0700 (PDT) (envelope-from Administration@computeradmin.org) Received: from 759.xkio.org [248.50.30.2] by 208.184.76.50 SMTP id O9KDZy753246B9 for ; Thu, 08 Apr 2004 22:53:33 -0600 Message-ID: <23589iu-$18-o@9524.y8sq> From: "Admin" To: nk@vpnc.org Subject: ADV: Attention All Nonprofit Orgs: (Members, Staff and Associates): Date: Thu, 08 Apr 04 22:53:33 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 5.50.4522.1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="E6_2B.A2D0C.82E.F8D_D2A" This is a multi-part message in MIME format. --E6_2B.A2D0C.82E.F8D_D2A Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Nonprofit Organizations, Members, Staff and Associates: You Must Respond By 5 P.M. Monday, April 12, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Members, Staff and Associates who respond to this message before 5 P.M., Monday, April 12, 2004. All desktop computers are brand-new packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2004 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktop Computers with the latest Intel technology at an amazing price to all who call: 1-800-884-9510 by 5 P.M. Monday, April 12, 2004 The fast and powerful AT-2400 series Desktop features: * Intel 2.0Ghz Processor for amazing speed and performance * 128MB DDR RAM, --- Upgradeable to 1024 * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW * 1.44 Floppy disk drive * Next Generation Technology * ATI Premium video and sound * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $699 ........................................ Your Cost $297 How to qualify: 1. You must be a Member, Staff or Associate of a Nonprofit: 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-884-9510 by 5 P.M. Monday, April 12, 2004 and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. Call Avtech Direct 1-800-884-9510 before 5 P.M. Monday, April 12, 2004 If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp --E6_2B.A2D0C.82E.F8D_D2A-- From owner-ipsec@lists.tislabs.com Fri Apr 9 05:55:23 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39CtMxn086315; Fri, 9 Apr 2004 05:55:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i39C7qx08710 for ipsec-outgoing; Fri, 9 Apr 2004 08:07:52 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Date: Fri, 09 Apr 2004 02:29:47 -0400 From: Radia Perlman Subject: Re: Question about Version Numbers To: vamsi Cc: ipsec@lists.tislabs.com Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.16 (built May 14 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yeah, as you said, an active attacker can keep responding to the first message with an unauthenticated notification message saying "the highest I support is n", and cause the connection to break and restart, and the active attacker can disrupt that one also. What should be done about it? a) (your suggestion), allow them to continue talking the lower version number b) ignore this problem in the spec as being not important enough at this point, and perhaps fix it later. Maybe consider it a feature, that an active attacker can prevent Alice and Bob from talking, but can't trick them into talking in an insecure manner. c) have the negotiation for version n+1 be authenticated, using the protection of the IKE version n SA already created (rather than tearing it down and starting from scratch with n+1) d) have Alice remember that Bob can talk n+1, and refuse to believe an unauthenticated notification telling her otherwise e) I'm sure other solutions are possible. Note that d) is allowed by the current spec (wouldn't violate any on-the-wire messages). So I think we should do that, which doesn't require changing the spec. Perhaps this will motivate me to revive the tutorial spec and mention that in an implementation tip. Radia ----- Original Message ----- From: vamsi Date: Thursday, April 8, 2004 11:20 pm Subject: Question about Version Numbers > Hi Friends, > In IKEv2 of section 2.5 Version Numbers and Forward Compatibility > ,the > text says > ".....If Alice is capable of speaking versions n, > n+1, and n+2, and Bob is capable of speaking versions n and > n+1, then > they will negotiate speaking n+1, where Alice will set the flag > indicating ability to speak a higher version. If they mistakenly > (perhaps through an active attacker sending error messages) > negotiate to version n, then both will notice that the other > side can support a > higher version number, and they MUST break the connection and > reconnect using version n+1." > > Let us assume the following scenario > Alice has sent the message with version n+2 to Bob and in between > the attacker > 'yyy' has tricked to make Alice to use version 'n'. So the next > message > from Alice with version 'n' > and enabling the Flag (which indicates that Alice support higher > version) > is sent to the BOB and he(BOB) will sent the > second message with version 'n' and flag enabled(which indicates > that BOB > supports higher version) . Then draft says "they MUST break the > connection > and reconnect using version n+1." So Alice again start with > version 'n+1' > and the attacker again trick him to use version > 'n' or the attacker even trick the Alice by sending with n+1 > version and > flag(that indicates the higher version) enabled where Bob > doesn't even > support higher version than n+1 and there by attacker succeeds > interrupting > the IKE exchanges . My doubt is that are we not going in a loop?? > > My feeling is that the text should be as follows > ".....If Alice is capable of speaking versions n, > n+1, and n+2, and Bob is capable of speaking versions n and > n+1, then > they will negotiate speaking n+1, where Alice will set the flag > indicating ability to speak a higher version. If they mistakenly > (perhaps through an active attacker sending error messages) > negotiate to version n, then both will notice that the other > side can support a > higher version number, and they SHOULD continue and SHOULD > audit the event" > > > Thanks > Vamsi > CTO Office > Intoto Inc. > www.intoto.com > > From owner-ipsec@lists.tislabs.com Fri Apr 9 07:09:00 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39E8xNT094487; Fri, 9 Apr 2004 07:08:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i39DRac13081 for ipsec-outgoing; Fri, 9 Apr 2004 09:27:36 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16502.42894.765000.265420@gargle.gargle.HOWL> Date: Fri, 9 Apr 2004 09:39:26 -0400 From: Paul Koning To: vamsi@intotoinc.com Cc: ipsec@lists.tislabs.com Subject: Re: Question about Version Numbers References: <5.2.0.9.0.20040408175747.029c9e10@10.1.5.10> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid X-OriginalArrivalTime: 09 Apr 2004 13:39:27.0007 (UTC) FILETIME=[13A922F0:01C41E38] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "vamsi" == vamsi writes: vamsi> Hi Friends, In IKEv2 of section 2.5 Version Numbers and vamsi> Forward Compatibility ,the text says ".....If Alice is capable vamsi> of speaking versions n, n+1, and n+2, and Bob is capable of vamsi> speaking versions n and n+1, then they will negotiate speaking vamsi> n+1, where Alice will set the flag indicating ability to speak vamsi> a higher version. If they mistakenly (perhaps through an vamsi> active attacker sending error messages) negotiate to version vamsi> n, then both will notice that the other side can support a vamsi> higher version number, and they MUST break the connection and vamsi> reconnect using version n+1." vamsi> Let us assume the following scenario Alice has sent the vamsi> message with version n+2 to Bob and in between the attacker vamsi> 'yyy' has tricked to make Alice to use version 'n'. So the vamsi> next message from Alice with version 'n' and enabling the Flag vamsi> (which indicates that Alice support higher version) is sent to vamsi> the BOB and he(BOB) will sent the second message with version vamsi> 'n' and flag enabled(which indicates that BOB supports higher vamsi> version) . Then draft says "they MUST break the connection and vamsi> reconnect using version n+1." So Alice again start with vamsi> version 'n+1' and the attacker again trick him to use version vamsi> 'n' or the attacker even trick the Alice by sending with n+1 vamsi> version and flag(that indicates the higher version) enabled vamsi> where Bob doesn't even support higher version than n+1 and vamsi> there by attacker succeeds interrupting the IKE exchanges . My vamsi> doubt is that are we not going in a loop?? If the attacker wants to persist in the attack, sure, it becomes a denial of service attack. So what? An active attacker can easily deny service in many easier ways. The important point here is that the attack is ONLY a denial of service attack, not a protocol downgrade attack. That's what the spec requires, and it should stay that way. paul From owner-ipsec@lists.tislabs.com Fri Apr 9 07:19:31 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39EJU7u095976; Fri, 9 Apr 2004 07:19:30 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i39DhLU14082 for ipsec-outgoing; Fri, 9 Apr 2004 09:43:21 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16501.25038.397000.682666@gargle.gargle.HOWL> References: <579E83556A36E44EB2945CCE990B317401371B49@EUR-MSG-02.europe.corp.microsoft .com> <16501.14558.282707.461014@fireball.acr.fi> <16501.25038.397000.682666@gargle.gargle.HOWL> Date: Fri, 9 Apr 2004 09:48:22 -0400 To: Paul Koning From: Stephen Kent Subject: RE: CONSENSUS TEST: Fragmentation handling Cc: kivinen@iki.fi, mroe@microsoft.com, tytso@mit.edu, ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:29 AM -0400 4/8/04, Paul Koning wrote: > >>>>> "Tero" == Tero Kivinen writes: > > Tero> Stephen Kent writes: > >> if neither #2 or #3 is a SHOULD, then I would like to add text > >> that every implementation MUST implement at least one of these, to > >> give us a decent chance of having a way to accommodate fragments > >> for port-specific SAs. in fact, maybe that is the best way to > >> state this, given the current set of comments on this topic. > > Tero> Then we can have two implementations both implementing > Tero> different parts of that MUST and they do not interoperate. > >Agreed. There really isn't any point in saying "you MUST do at least >one of x and y". From an interop point of view "you SHOULD do both x >and y" is no worse and probably better. With either text, you have no >guarantee of interoperability. I can live with two SHOULDs. >The only way to guarantee interoperability is to have "you MUST do x". >If we can get consensus on that (re #2 and #3), fine. If not, then >weonly have #1 (not port specific) as guaranteed interoperable. >Personally I think that is sufficient. yes, #1 is interoperable, but also feature poor. Steve From owner-ipsec@lists.tislabs.com Fri Apr 9 07:21:25 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39ELOpm096249; Fri, 9 Apr 2004 07:21:24 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i39DhJ014079 for ipsec-outgoing; Fri, 9 Apr 2004 09:43:20 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16501.14558.282707.461014@fireball.acr.fi> References: <579E83556A36E44EB2945CCE990B317401371B49@EUR-MSG-02.europe.corp.microsoft .com> <16501.14558.282707.461014@fireball.acr.fi> Date: Fri, 9 Apr 2004 09:45:39 -0400 To: Tero Kivinen From: Stephen Kent Subject: RE: CONSENSUS TEST: Fragmentation handling Cc: "Michael Roe" , "Theodore Ts'o" , 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 2:34 PM +0300 4/8/04, Tero Kivinen wrote: >Stephen Kent writes: >> if neither #2 or #3 is a SHOULD, then I would like to add text that >> every implementation MUST implement at least one of these, to give us >> a decent chance of having a way to accommodate fragments for >> port-specific SAs. in fact, maybe that is the best way to state this, >> given the current set of comments on this topic. > >Then we can have two implementations both implementing different parts >of that MUST and they do not interoperate. Also the case #3 can also >be used with IPv6, and the case #2 cannot securely be used with it, so >I think it is better to have case #3 as SHOULD and case #2 MAY. I do >not think we need requirement for "MUST" for at least one, as there >will be implementations which do not care about port selectors and/or >fragments. >-- >kivinen@safenet-inc.com I too would prefer one MUST, for interoperability, be we can't get consensus on that, hence my suggestion. Your final comment above is problematic: "as there will be implementations which do not care about port selectors and/or fragments." Implementations MUST support port selectors; it was a 2401 requirement and it is a 2401bis requirement. The question is how to handle the port selector specific SAs in contexts where fragmentation occurs. Steve From owner-ipsec@lists.tislabs.com Fri Apr 9 10:51:51 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39HpoPr024297; Fri, 9 Apr 2004 10:51:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i39H5n423624 for ipsec-outgoing; Fri, 9 Apr 2004 13:05:49 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: Question on Issue#74: Inbound SA lookup - multicast & unicast Date: Fri, 9 Apr 2004 10:18:28 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on Issue#74: Inbound SA lookup - multicast & unicast Thread-Index: AcQeVqyGkt9fZ8wAT7qisgbRFRnW9Q== From: "Sharma, Suman" To: X-OriginalArrivalTime: 09 Apr 2004 17:18:29.0332 (UTC) FILETIME=[AD18C940:01C41E56] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id i39H5k823621 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Statement below is part of Issue 74 resolution, "If an IPsec implementation supports multicast SAs as well as unicast SAs, then it MUST use the following algorithm for mapping all inbound IPsec datagrams to SAs. (Implementations that support only unicast traffic need not implement this algorithm.) Each entry in the Security Association Database (SAD) must indicate whether the SA lookup makes use of (a) the SPI but neither the source or destination address (unicast), (b) the destination IP address plus the SPI, or (c) source plus destination IP addresses in addition to the SPI. (For multicast SAs, the protocol field is not employed for SA lookups.) Nominally, this indication can be represented by two bits, one associated with the source IP address and the other for the destination IP address. A "1" value for each bit indicates the need to match against the corresponding address field as part of the SA lookup process. Thus, for example, unicast SAs would have both bits set to zero, since neither the source nor destination IP address is required for SA matching." My question is for implementation supporting multicast & unicast: From the above statement, it looks like that 2 bit flag will be stored inside SAD. But To get to SAD, lookup is required? And what all fields to use for lookup is inside SAD (in 2 bit flag)? So how this is supposed to work? -suman From owner-ipsec@lists.tislabs.com Fri Apr 9 13:34:04 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39KY345042414; Fri, 9 Apr 2004 13:34:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i39JoqN00304 for ipsec-outgoing; Fri, 9 Apr 2004 15:50:52 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <4076E2A9.30806@isi.edu> References: <16480.15529.482315.278735@fireball.acr.fi> <016c01c416c3$eb1d8270$861167c0@adithya> <16492.6896.588750.18184@fireball.acr.fi> <16493.10872.196792.111195@fireball.acr.fi> <20040406162758.GA10072@thunk.org> <4076E2A9.30806@isi.edu> Date: Fri, 9 Apr 2004 15:01:44 -0400 To: Joe Touch From: Stephen Kent Subject: Re: CONSENSUS TEST: Fragmentation handling Cc: "Theodore Ts'o" , Tero Kivinen , Mohan Parthasarathy , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:51 AM -0700 4/9/04, Joe Touch wrote: >Stephen Kent wrote: > >>Ted, >> >>>1. All implementations MUST support tunnel mode SAs that pass traffic >>>without regard to port field values. If the SA will carry traffic for >>>specified protocols, the two selector sets MUST be used to specify >>>the port fields for the SA: ANY and OPAQUE. An SA defined in this >>>fashion will carry all traffic for the indicated source/destination >>>addresses and specified protocol(s). If the SA will carry traffic >>>without regard to a specific protocol value (i.e., ANY is specified), >>>then the port field values MUST be set to ANY as well. >> >> >>Mark Duffy convinced me that we should interpret ANY to encompass >>OPAQUE, as I noted in a message last week. So this part should be >>reworded to say: >> >> 1. All implementations MUST support tunnel mode SAs that pass traffic >>without regard to port field values. If the SA will carry traffic for >>specified protocols, the selector set for the SA MUST specify the >>port fields values as ANY. An SA defined in this fashion will >>carry all traffic for the indicated source/destination addresses >>and specified protocol(s). If the SA will carry traffic without >>regard to a specific protocol value (i.e., ANY is specified for the >>protocol field), then the port field values MUST be set to ANY as >>well. >> >> >>Steve > > >In the last case, it might be worth noting that if the protocol >field is ANY, then the port field values are undefined anyway. > >(the reason is to preclude an implementation that interprets "ANY" >protocol with "ANY" port to include only protocols that have ports.) > >Joe agreed. Steve From owner-ipsec@lists.tislabs.com Fri Apr 9 13:45:55 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39KjtaM043658; Fri, 9 Apr 2004 13:45:55 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i39K6Pf01059 for ipsec-outgoing; Fri, 9 Apr 2004 16:06:25 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Message-Id: <200404092018.i39KIIQU007532@thunk.east.sun.com> From: Bill Sommerfeld To: Radia Perlman cc: vamsi , ipsec@lists.tislabs.com Subject: Re: Question about Version Numbers In-Reply-To: Your message of "Fri, 09 Apr 2004 02:29:47 EDT." Reply-to: sommerfeld@east.sun.com Date: Fri, 09 Apr 2004 16:18:18 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > d) have Alice remember that Bob can talk n+1, and refuse to believe > an unauthenticated notification telling her otherwise > > Note that d) is allowed by the current spec (wouldn't violate any > on-the-wire messages). So I think we should do that, which doesn't > require changing the spec. Perhaps this will motivate me to revive > the tutorial spec and mention that in an implementation tip. Actually, I'd like to discourage this particular strategy -- it makes it extremely difficult to cleanly back out of a failed upgrade. There's a common OS/firmware upgrade strategy involving the use of multiple OS images -- you can update a standby image, activate the standby image and reboot, and then, because you still have the original image around, you can (relatively) easily fall back to a known working configuration if everything didn't work as anticipated. The reason for falling back to the previous version may have nothing to do with IKE/IPsec -- the new IKE version may just be along for the ride in the new configuration. With a "once I've seen you speak n+1, I refuse to talk version n to you" strategy, I now have to track down all the nodes that this system spoke to during this interval and apply percussive maintainance -- and I may not have the authority to use the necessary hammers myself. - Bill From owner-ipsec@lists.tislabs.com Fri Apr 9 13:52:30 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39KqUGg044398; Fri, 9 Apr 2004 13:52:30 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i39KHH501436 for ipsec-outgoing; Fri, 9 Apr 2004 16:17:17 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Date: Fri, 09 Apr 2004 16:30:15 -0400 From: Radia Perlman Subject: Re: Question about Version Numbers To: sommerfeld@east.sun.com Cc: vamsi , ipsec@lists.tislabs.com Message-id: <148a112410.12410148a1@bur-mail2.east.sun.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.16 (built May 14 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Fair enough Bill (see his concern below). How about instead of Alice completely ignoring the "I only speak n", having Alice continue with n+1 but also do n. That way the worst the attacker can do is force you to do two connections, and then once n+1 comes up, you can drop the version n SA. This also doesn't require a change to the protocol. Radia ----- Original Message ----- From: Bill Sommerfeld Date: Friday, April 9, 2004 4:18 pm Subject: Re: Question about Version Numbers > > d) have Alice remember that Bob can talk n+1, and refuse to believe > > an unauthenticated notification telling her otherwise > > > > Note that d) is allowed by the current spec (wouldn't violate any > > on-the-wire messages). So I think we should do that, which doesn't > > require changing the spec. Perhaps this will motivate me to revive > > the tutorial spec and mention that in an implementation tip. > > Actually, I'd like to discourage this particular strategy -- it makes > it extremely difficult to cleanly back out of a failed upgrade. > > There's a common OS/firmware upgrade strategy involving the use of > multiple OS images -- you can update a standby image, activate the > standby image and reboot, and then, because you still have the > original image around, you can (relatively) easily fall back to a > known working configuration if everything didn't work as anticipated. > > The reason for falling back to the previous version may have nothing > to do with IKE/IPsec -- the new IKE version may just be along for the > ride in the new configuration. > > With a "once I've seen you speak n+1, I refuse to talk version n to > you" strategy, I now have to track down all the nodes that this system > spoke to during this interval and apply percussive maintainance -- and > I may not have the authority to use the necessary hammers myself. > > - Bill > From owner-ipsec@lists.tislabs.com Fri Apr 9 15:36:01 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i39Ma1RM055622; Fri, 9 Apr 2004 15:36:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i39LvCt04496 for ipsec-outgoing; Fri, 9 Apr 2004 17:57:12 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16503.8003.673000.660515@gargle.gargle.HOWL> Date: Fri, 9 Apr 2004 18:10:11 -0400 From: Paul Koning To: Radia.Perlman@sun.com Cc: sommerfeld@east.sun.com, vamsi@intotoinc.com, ipsec@lists.tislabs.com Subject: Re: Question about Version Numbers References: <148a112410.12410148a1@bur-mail2.east.sun.com> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid X-OriginalArrivalTime: 09 Apr 2004 22:10:11.0877 (UTC) FILETIME=[6D6D3550:01C41E7F] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Radia" == Radia Perlman writes: Radia> Fair enough Bill (see his concern below). How about instead Radia> of Alice completely ignoring the "I only speak n", having Radia> Alice continue with n+1 but also do n. That way the worst the Radia> attacker can do is force you to do two connections, and then Radia> once n+1 comes up, you can drop the version n SA. But that doesn't fix the downgrade attack. If I can keep SA n+1 from coming up, I've downgraded you. How about leaving things alone? It still looks like a denial of service attack to me, so why fiddle with things? paul From owner-ipsec@lists.tislabs.com Fri Apr 9 17:08:13 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3A08Dd4066155; Fri, 9 Apr 2004 17:08:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i39NRsg07361 for ipsec-outgoing; Fri, 9 Apr 2004 19:27:54 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Message-ID: <40773427.2090700@cisco.com> Date: Fri, 09 Apr 2004 16:39:19 -0700 From: Kevin Li Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, zh, zh-hk MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: IKEv2 AUTH payload Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, IKEv2-13 says that the entire IKE message (from the first octet to last octet of the paylod) will be signed. I am assuming that the AUTH payload is not included (even the nullified one -- all set to 0) for signature. It means that the AUTH payload will be the last one in the IKE message and message is signed up to the beggining of the AUTH payload. Is above the right interpretation? If so, it may be a good idea to clarify this in the spec. Thanks. Kevin Cisco Systems ============= Quote from IKEv2-13 --- Start 2.15 Authentication of the IKE_SA When not using extended authentication (see section 2.16), the peers are authenticated by having each sign (or MAC using a shared secret as the key) a block of data. For the responder, the octets to be signed start with the first octet of the first SPI in the header of the second message and end with the last octet of the last payload in the second message. Appended to this (for purposes of computing the signature) are the initiator's nonce Ni (just the value, not the payload containing it), and the value prf(SK_ar,IDr') where IDr' is the responder's ID payload excluding the fixed header. Note that neither the nonce Ni nor the value prf(SK_ar,IDr') are transmitted. ============ Quote from IKEv2-13 --- End From owner-ipsec@lists.tislabs.com Fri Apr 9 19:22:06 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3A2M5rs077400; Fri, 9 Apr 2004 19:22:05 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i3A1ikT14049 for ipsec-outgoing; Fri, 9 Apr 2004 21:44:46 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Date: Fri, 9 Apr 2004 20:24:41 -0400 (EDT) From: George Gross To: "Sharma, Suman" cc: , Subject: Re: Question on Issue#74: Inbound SA lookup - multicast & unicast In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Suman, I agree that the language in this section is mildly confusing, I had a hard time parsing it on my first read. For my GSAKMP/IPsec implementation, I interpreted that section to mean that the SAD was conceptually three databases, not one. The three SAD databases are indexed and searched as follows: 1) First you search SAD-1 using the SAD index triple {source address, destination multicast address, SPI}. If the search finds a matching SAD-1 entry, then use its associated SA state to process the ESP payload. 2) Second, you search SAD-2 using the SAD index pair {destination multicast address, SPI}. If the search finds a matching SAD-2 entry, then use its SA state. 3) third you search SAD-3 using only the SPI as the index. If the search finds a matching SAD-3 entry, then use its SA state. 4) discard the packet if none of the above searches got a match. Typically, SAD-1 is assigned to the Source-Specific Multicast group SA(s), SAD-2 to Any-Source Multicast group SA(s), and SAD-3 is for unicast SA(s). The SAD-1 would also be used for any group SA that required anti-replay protection using ESP sequence numbers. Steve: If the above procedure is what was intended, then I would like to suggest that it would be helpful if some additional language be added to rfc2401-bis describing the above SAD search order (i.e. use SAD longest search indice first). The above procedure in principal would allow unicast and multicast SA to happen to have duplicate SPI assignments. Was that the intention? I infer that the unmentioned goal is allowing a multicast key management protocol, such as GSAKMP, to be autonomous from the IKE SPI allocations. would it be good for rfc2401-bis to explicitly point this out? AFAIK, no MSEC doc covers this facet of the MSEC/IPsec interaction yet... tia, George On Fri, 9 Apr 2004, Sharma, Suman wrote: > Statement below is part of Issue 74 resolution, > > "If an IPsec implementation supports multicast SAs as well as > unicast SAs, then it MUST use the following algorithm for > mapping all inbound IPsec datagrams to SAs. (Implementations > that support only unicast traffic need not implement this > algorithm.) Each entry in the Security Association Database > (SAD) must indicate whether the SA lookup makes use of (a) > the SPI but neither the source or destination address > (unicast), (b) the destination IP address plus the SPI, or > (c) source plus destination IP addresses in addition to the > SPI. (For multicast SAs, the protocol field is not employed > for SA lookups.) Nominally, this indication can be > represented by two bits, one associated with the source IP > address and the other for the destination IP address. A "1" > value for each bit indicates the need to match against the > corresponding address field as part of the SA lookup > process. Thus, for example, unicast SAs would have both bits > set to zero, since neither the source nor destination IP > address is required for SA matching." > > My question is for implementation supporting multicast & unicast: > From the above statement, it looks like that 2 bit flag will be stored > inside SAD. > But To get to SAD, lookup is required? And what all fields to use for > lookup is inside SAD (in 2 bit flag)? > So how this is supposed to work? > > > -suman > From owner-ipsec@lists.tislabs.com Fri Apr 9 20:28:49 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3A3SmpQ083849; Fri, 9 Apr 2004 20:28:48 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i3A2p9Y16925 for ipsec-outgoing; Fri, 9 Apr 2004 22:51:09 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: Question on Issue#74: Inbound SA lookup - multicast & unicast Date: Fri, 9 Apr 2004 20:04:03 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on Issue#74: Inbound SA lookup - multicast & unicast Thread-Index: AcQenxq7oWXahfhAQbmPPdlpBQsM0gAB1gyA From: "Sharma, Suman" To: "George Gross" Cc: X-OriginalArrivalTime: 10 Apr 2004 03:04:03.0837 (UTC) FILETIME=[7AE4CAD0:01C41EA8] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id i3A2p6816918 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is the description I got from Steve about this, "Once we have determined that the inbound packet appears to be an IPsec protected packet addressed to us, and not ICMP, then we need to match the packet to an appropriate SAD entry. the two-bit flag is a way of saying how to perform the match against the SAD entry parameters. If the flags are set for unicast, then just match using the SPI. If the flags say sender-specific multicast, match using SPI and source address. If the flags say multicast but not SSM, match using SPI plus destination address." >From this it looks like that SAD lookup will be done using SPI. Once SA is known, 2-bit flag will be read to find the entries to match for verification (if this SA is the right one or not). So, in case this bit is 0, just SPI will be checked. If any of the bits of two bit vecotor is set, that indicates which all IP addr (dst/src) to match other then SPI. Doing three lookups (as mentioned by George) will have big performance impact for unicast. -suman -----Original Message----- From: George Gross [mailto:gmgross@nac.net] Sent: Friday, April 09, 2004 5:25 PM To: Sharma, Suman Cc: ipsec@lists.tislabs.com; gmgross@nac.net Subject: Re: Question on Issue#74: Inbound SA lookup - multicast & unicast Hi Suman, I agree that the language in this section is mildly confusing, I had a hard time parsing it on my first read. For my GSAKMP/IPsec implementation, I interpreted that section to mean that the SAD was conceptually three databases, not one. The three SAD databases are indexed and searched as follows: 1) First you search SAD-1 using the SAD index triple {source address, destination multicast address, SPI}. If the search finds a matching SAD-1 entry, then use its associated SA state to process the ESP payload. 2) Second, you search SAD-2 using the SAD index pair {destination multicast address, SPI}. If the search finds a matching SAD-2 entry, then use its SA state. 3) third you search SAD-3 using only the SPI as the index. If the search finds a matching SAD-3 entry, then use its SA state. 4) discard the packet if none of the above searches got a match. Typically, SAD-1 is assigned to the Source-Specific Multicast group SA(s), SAD-2 to Any-Source Multicast group SA(s), and SAD-3 is for unicast SA(s). The SAD-1 would also be used for any group SA that required anti-replay protection using ESP sequence numbers. Steve: If the above procedure is what was intended, then I would like to suggest that it would be helpful if some additional language be added to rfc2401-bis describing the above SAD search order (i.e. use SAD longest search indice first). The above procedure in principal would allow unicast and multicast SA to happen to have duplicate SPI assignments. Was that the intention? I infer that the unmentioned goal is allowing a multicast key management protocol, such as GSAKMP, to be autonomous from the IKE SPI allocations. would it be good for rfc2401-bis to explicitly point this out? AFAIK, no MSEC doc covers this facet of the MSEC/IPsec interaction yet... tia, George On Fri, 9 Apr 2004, Sharma, Suman wrote: > Statement below is part of Issue 74 resolution, > > "If an IPsec implementation supports multicast SAs as well as > unicast SAs, then it MUST use the following algorithm for > mapping all inbound IPsec datagrams to SAs. (Implementations > that support only unicast traffic need not implement this > algorithm.) Each entry in the Security Association Database > (SAD) must indicate whether the SA lookup makes use of (a) > the SPI but neither the source or destination address > (unicast), (b) the destination IP address plus the SPI, or > (c) source plus destination IP addresses in addition to the > SPI. (For multicast SAs, the protocol field is not employed > for SA lookups.) Nominally, this indication can be > represented by two bits, one associated with the source IP > address and the other for the destination IP address. A "1" > value for each bit indicates the need to match against the > corresponding address field as part of the SA lookup > process. Thus, for example, unicast SAs would have both bits > set to zero, since neither the source nor destination IP > address is required for SA matching." > > My question is for implementation supporting multicast & unicast: > From the above statement, it looks like that 2 bit flag will be stored > inside SAD. > But To get to SAD, lookup is required? And what all fields to use for > lookup is inside SAD (in 2 bit flag)? > So how this is supposed to work? > > > -suman > From owner-ipsec@lists.tislabs.com Fri Apr 9 21:07:37 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3A47bcj087280; Fri, 9 Apr 2004 21:07:37 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i3A3Ypc18832 for ipsec-outgoing; Fri, 9 Apr 2004 23:34:52 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Date: Fri, 09 Apr 2004 23:47:46 -0400 From: Radia Perlman Subject: Re: IKEv2 AUTH payload To: Kevin Li Cc: ipsec@lists.tislabs.com Message-id: <1148418c5c.18c5c11484@bur-mail2.east.sun.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.16 (built May 14 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You're concerned about a recursion problem if the AUTH payload is signing the message in which the AUTH payload appears. However, the AUTH payload is signing a different message, so there isn't a problem. Alice (the initiator) is signing message 1, and her AUTH payload is in message 3. Bob is signing message 2 and his AUTH payload is in message 4. Radia ----- Original Message ----- From: Kevin Li Date: Friday, April 9, 2004 7:39 pm Subject: IKEv2 AUTH payload > Hi, > > IKEv2-13 says that the entire IKE message (from the first octet to > last octet of > the paylod) will be signed. I am assuming that the AUTH payload is > not included > (even the nullified one -- all set to 0) for signature. It means > that the AUTH > payload will be the last one in the IKE message and message is > signed up to the > beggining of the AUTH payload. > > Is above the right interpretation? If so, it may be a good idea to > clarify this > in the spec. > > Thanks. > > Kevin > Cisco Systems > > > > ============= Quote from IKEv2-13 --- Start > > 2.15 Authentication of the IKE_SA > > > When not using extended authentication (see section 2.16), the > peers are authenticated by having each sign (or MAC using a > shared secret > as the key) a block of data. For the responder, the octets to be > signed start with the first octet of the first SPI in the > header of > the second message and end with the last octet of the last > payload in > the second message. Appended to this (for purposes of > computing the > signature) are the initiator's nonce Ni (just the value, not the > payload containing it), and the value prf(SK_ar,IDr') where > IDr' is > the responder's ID payload excluding the fixed header. Note that > neither the nonce Ni nor the value prf(SK_ar,IDr') are > transmitted. > ============ Quote from IKEv2-13 --- End > > From owner-ipsec@lists.tislabs.com Sat Apr 10 00:31:30 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3A7VTwd054504; Sat, 10 Apr 2004 00:31:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i3A6rrp27477 for ipsec-outgoing; Sat, 10 Apr 2004 02:53:53 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Message-ID: <53462.217.132.152.26.1081584279.squirrel@sslvpn.checkpoint.com> In-Reply-To: <1148418c5c.18c5c11484@bur-mail2.east.sun.com> References: <1148418c5c.18c5c11484@bur-mail2.east.sun.com> Date: Sat, 10 Apr 2004 08:04:39 -0000 (UTC) Subject: Re: IKEv2 AUTH payload From: "Yoav Nir" To: "Radia Perlman" Cc: "Kevin Li" , ipsec@lists.tislabs.com Reply-To: ynir@checkpoint.com User-Agent: WebMail Portal/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Because of EAP, the AUTH payloads may appear in later messages, but they always sign messages 1 and 2 of the INITIAL exchange. I still haven't received any responses to my question of last week, about what to do if the autentication exchange is repeated later on. It appears that in order to support this, I would have to store the old initial exchanges so as to produce and verify the AUTH payloads, but that seems wasteful. Radia Perlman said: > You're concerned about a recursion problem if the AUTH payload is signing > the message in which the AUTH payload appears. However, the AUTH payload > is signing a different message, so there isn't a problem. > > Alice (the initiator) is signing message 1, and her AUTH payload is in > message 3. > Bob is signing message 2 and his AUTH payload is in message 4. > > Radia > > ----- Original Message ----- > From: Kevin Li > Date: Friday, April 9, 2004 7:39 pm > Subject: IKEv2 AUTH payload > >> Hi, >> >> IKEv2-13 says that the entire IKE message (from the first octet to >> last octet of >> the paylod) will be signed. I am assuming that the AUTH payload is >> not included >> (even the nullified one -- all set to 0) for signature. It means >> that the AUTH >> payload will be the last one in the IKE message and message is >> signed up to the >> beggining of the AUTH payload. >> >> Is above the right interpretation? If so, it may be a good idea to >> clarify this >> in the spec. >> >> Thanks. >> >> Kevin >> Cisco Systems >> >> >> >> ============= Quote from IKEv2-13 --- Start >> >> 2.15 Authentication of the IKE_SA >> >> >> When not using extended authentication (see section 2.16), the >> peers are authenticated by having each sign (or MAC using a >> shared secret >> as the key) a block of data. For the responder, the octets to be >> signed start with the first octet of the first SPI in the >> header of >> the second message and end with the last octet of the last >> payload in >> the second message. Appended to this (for purposes of >> computing the >> signature) are the initiator's nonce Ni (just the value, not the >> payload containing it), and the value prf(SK_ar,IDr') where >> IDr' is >> the responder's ID payload excluding the fixed header. Note that >> neither the nonce Ni nor the value prf(SK_ar,IDr') are >> transmitted. >> ============ Quote from IKEv2-13 --- End >> >> > > From owner-ipsec@lists.tislabs.com Sat Apr 10 09:17:39 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AGHcdQ051495; Sat, 10 Apr 2004 09:17:39 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i3AFYFT26430 for ipsec-outgoing; Sat, 10 Apr 2004 11:34:15 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Sat, 10 Apr 2004 08:47:13 -0700 To: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ikev2-iana-02.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Initial IANA registry contents Author(s) : M. Richardson Filename : draft-ietf-ipsec-ikev2-iana-02.txt Pages : 24 Date : 2004-4-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-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-02.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-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. [The following attachment must be fetched by mail. Command-click the URL below and send the resulting message to get the attachment.] [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] From owner-ipsec@lists.tislabs.com Sat Apr 10 11:05:20 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3AI5Kkr063398; Sat, 10 Apr 2004 11:05:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i3AHOU402159 for ipsec-outgoing; Sat, 10 Apr 2004 13:24:30 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Date: Sat, 10 Apr 2004 11:57:42 -0400 (EDT) From: George Gross To: "Sharma, Suman" cc: George Gross , Subject: RE: Question on Issue#74: Inbound SA lookup - multicast & unicast In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Suman, On Fri, 9 Apr 2004, Sharma, Suman wrote: > This is the description I got from Steve about this, > > "Once we have determined that the inbound packet appears to be an IPsec > protected packet addressed to us, and not ICMP, then we need to match > the packet to an appropriate SAD entry. the two-bit flag is a way of > saying how to perform the match against the SAD entry parameters. If the > flags are set for unicast, then just match using the SPI. If the flags > say sender-specific multicast, match using SPI and source address. If > the flags say multicast but not SSM, match using SPI plus destination > address." This statement does not clarify that the "longer" SAD search index is examined before a shorter one, so as to discriminate those multicast and unicast SA that have the same SPI. The benefit is that a central group key management system can allocate SPI for a group without coordinating that allocation with all of the group's end system IKE key management systems. For example, if a group SA uses SPI 2059, and there is a unicast SA that also uses SPI 2059, the SAD lookup should de-mux their packet flows correctly. If a multicast packet is received, and the algorithm looked at the SPI 2059 SAD entry that had both bits off before the one that multicast address bits on, then it would match and use the wrong SAD entry. > > >From this it looks like that SAD lookup will be done using SPI. Once SA > is known, 2-bit flag will be read to find the entries to match for > verification (if this SA is the right one or not). So, in case this bit > is 0, just SPI will be checked. If any of the bits of two bit vecotor is > set, that indicates which all IP addr (dst/src) to match other then SPI. As described above, this is not quite complete unless the order of match is sorted. > > > Doing three lookups (as mentioned by George) will have big performance > impact for unicast. I expressed the procedure that way for definition purposes; in my implementation, I use a similar approach as mentioned above but with the distinction that multicast SA identifiers are checked before unicast. The SPI indexes into a hash table, with the SAD entries at the hash table bucket arranged in a linked list sorted by the longest SA id first. George > > -suman > > -----Original Message----- > From: George Gross [mailto:gmgross@nac.net] > Sent: Friday, April 09, 2004 5:25 PM > To: Sharma, Suman > Cc: ipsec@lists.tislabs.com; gmgross@nac.net > Subject: Re: Question on Issue#74: Inbound SA lookup - multicast & > unicast > > Hi Suman, > > I agree that the language in this section is mildly confusing, I > had a hard time parsing it on my first read. For my GSAKMP/IPsec > implementation, I interpreted that section to mean that the SAD was > conceptually three databases, not one. > > The three SAD databases are indexed and searched as follows: > > 1) First you search SAD-1 using the SAD index triple {source address, > destination multicast address, SPI}. If the search finds a matching > SAD-1 > entry, then use its associated SA state to process the ESP payload. > > 2) Second, you search SAD-2 using the SAD index pair {destination > multicast address, SPI}. If the search finds a matching SAD-2 entry, > then > use its SA state. > > 3) third you search SAD-3 using only the SPI as the index. If the search > finds a matching SAD-3 entry, then use its SA state. > > 4) discard the packet if none of the above searches got a match. > > Typically, SAD-1 is assigned to the Source-Specific Multicast group > SA(s), > SAD-2 to Any-Source Multicast group SA(s), and SAD-3 is for unicast > SA(s). > The SAD-1 would also be used for any group SA that required anti-replay > protection using ESP sequence numbers. > > Steve: If the above procedure is what was intended, then I would like to > suggest that it would be helpful if some additional language be added to > rfc2401-bis describing the above SAD search order (i.e. use SAD longest > search indice first). > > The above procedure in principal would allow unicast and multicast SA to > happen to have duplicate SPI assignments. Was that the intention? I > infer > that the unmentioned goal is allowing a multicast key management > protocol, > such as GSAKMP, to be autonomous from the IKE SPI allocations. would it > be > good for rfc2401-bis to explicitly point this out? AFAIK, no MSEC doc > covers this facet of the MSEC/IPsec interaction yet... > > tia, > George > > On Fri, 9 Apr 2004, Sharma, Suman wrote: > > > Statement below is part of Issue 74 resolution, > > > > "If an IPsec implementation supports multicast SAs as well as > > unicast SAs, then it MUST use the following algorithm for > > mapping all inbound IPsec datagrams to SAs. (Implementations > > that support only unicast traffic need not implement this > > algorithm.) Each entry in the Security Association Database > > (SAD) must indicate whether the SA lookup makes use of (a) > > the SPI but neither the source or destination address > > (unicast), (b) the destination IP address plus the SPI, or > > (c) source plus destination IP addresses in addition to the > > SPI. (For multicast SAs, the protocol field is not employed > > for SA lookups.) Nominally, this indication can be > > represented by two bits, one associated with the source IP > > address and the other for the destination IP address. A "1" > > value for each bit indicates the need to match against the > > corresponding address field as part of the SA lookup > > process. Thus, for example, unicast SAs would have both bits > > set to zero, since neither the source nor destination IP > > address is required for SA matching." > > > > My question is for implementation supporting multicast & unicast: > > From the above statement, it looks like that 2 bit flag will be > stored > > inside SAD. > > But To get to SAD, lookup is required? And what all fields to use for > > lookup is inside SAD (in 2 bit flag)? > > So how this is supposed to work? > > > > > > -suman > > > From owner-ipsec@lists.tislabs.com Mon Apr 12 18:39:59 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D1dwoP089465; Mon, 12 Apr 2004 18:39:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i3D0hE401717 for ipsec-outgoing; Mon, 12 Apr 2004 20:43:14 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: References: Date: Mon, 12 Apr 2004 20:54:17 -0400 To: George Gross From: Stephen Kent Subject: RE: Question on Issue#74: Inbound SA lookup - multicast & unicast Cc: "Sharma, Suman" , George Gross , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:57 AM -0400 4/10/04, George Gross wrote: >Suman, > >On Fri, 9 Apr 2004, Sharma, Suman wrote: > >> This is the description I got from Steve about this, >> >> "Once we have determined that the inbound packet appears to be an IPsec >> protected packet addressed to us, and not ICMP, then we need to match >> the packet to an appropriate SAD entry. the two-bit flag is a way of >> saying how to perform the match against the SAD entry parameters. If the >> flags are set for unicast, then just match using the SPI. If the flags >> say sender-specific multicast, match using SPI and source address. If >> the flags say multicast but not SSM, match using SPI plus destination >> address." > >This statement does not clarify that the "longer" SAD search index is >examined before a shorter one, so as to discriminate those multicast and >unicast SA that have the same SPI. The benefit is that a central group key >management system can allocate SPI for a group without coordinating that >allocation with all of the group's end system IKE key management systems. > >For example, if a group SA uses SPI 2059, and there is a unicast SA that >also uses SPI 2059, the SAD lookup should de-mux their packet flows >correctly. If a multicast packet is received, and the algorithm looked at >the SPI 2059 SAD entry that had both bits off before the one that >multicast address bits on, then it would match and use the wrong SAD >entry. > George, Your are right that there is a need to avoid the possibility of matching a multicast datagram against just the SPI for a unicast SA. your suggestion calls for essentially ordering the search, to start with longest possible matches (S+D+SPI) then shorter matches (S+SPI) then shortest (SPI). the three SAD tables you describe represent one way of encoding the 2-bit field described in the latest revs of AH, ESP, and 2401bis. the approach you described works, and since support for multicast is not mandated by 2401bis or AH or ESP, the cost of this serial search would not be incurred by implementations that support only unicast. we really should have been more precise in our description to help people avoid the pitfall of a "too short" match. One can get fancier, of course. Since MIKE is used to create SAs for multicast traffic, it can note the source addresses for SSM and the destination addresses for conventional multicast, to cause an inbound packet to be matched appropriately, without the need to do as much serialization as suggested. Steve From owner-ipsec@lists.tislabs.com Tue Apr 13 08:35:13 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DFZC67050661; Tue, 13 Apr 2004 08:35:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i3DF12227662 for ipsec-outgoing; Tue, 13 Apr 2004 11:01:02 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Tue, 13 Apr 2004 07:59:09 -0700 To: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ui-suites-05.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Cryptographic Suites for IPsec Author(s) : P. Hoffman Filename : draft-ietf-ipsec-ui-suites-05.txt Pages : 5 Date : 2004-4-12 The IPsec, IKE, and IKEv2 protocols rely on security algorithms to provide privacy and authentication between the initiator and responder. There are many such algorithms available, and two IPsec systems cannot interoperate unless they are using the same algorithms. This document specifies optional suites of algorithms and attributes that can be used to simplify the administration of IPsec when used in manual keying mode, with IKE version 1, or with IKEv2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ui-suites-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ui-suites-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ui-suites-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. [The following attachment must be fetched by mail. Command-click the URL below and send the resulting message to get the attachment.] [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] From owner-ipsec@lists.tislabs.com Tue Apr 13 17:22:24 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3E0MOMJ010839; Tue, 13 Apr 2004 17:22:24 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i3DNm9s01991 for ipsec-outgoing; Tue, 13 Apr 2004 19:48:09 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Tue, 13 Apr 2004 19:54:27 -0400 To: ipsec@lists.tislabs.com From: Karen Seo Subject: 2401bis -- Issue 91 -- handling ICMP error messages Cc: 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, Following up on a discussion at the end of February/early March re: how to handle ICMP traffic... We were talking about how to carry ICMP traffic via an SA between two IPsec implementations. This did NOT involve ICMP traffic that might be bypassed or consumed on the ciphertext side of the IPsec boundary. Also, there are two categories of ICMP traffic -- error messages (e.g., type = destination unreachable) and non-error messages (e.g., type = echo). This discussion covered ONLY error messages. Non-error ICMP messages should be explicitly accounted for in the SPD. Two approaches were discussed: 1. The sender of ICMP error message uses the (return) SA for the packet that resulted in the ICMP error message. In this discussion, the SA was assumed to not be configured to carry ICMP error messages. 2. The sender of ICMP error message uses an SA that is configured to handle ICMP error messages of the relevant type and code. Note that while this case was viewed in the discussion as being a different/separate SA from case 1 above, this SA could be the same as case 1, if that SA were configured to carry ICMP error taffic (in addition to user traffic). Note also that the ICMP Type and Code for this SA could be set to ANY, if there is no need to restrict the type of ICMP traffic that it is allowed to carry. Here's what needs to happen at the sender and receiver, to make each case work: For case 1: a. The sender notices that the packet is an ICMP error message and diverts it to slow path processing. It examines the enclosed packet (or portion thereof), swaps the source and destination addresses and ports, and performs an SPD lookup to find the SA to use. Then the ICMP packet is sent via the the selected SA. b. The receiver notices that a packet has failed the selector check (e.g., the source address or the protocol does not match). The packet is diverted to slow path processing where it is observed to be an ICMP error message and the enclosed packet is examined. The source and destination addresses and ports are swapped and matched against the selectors for the SA via which the ICMP packet was received. If they match, the ICMP message is passed on for further processing, e.g., PMTU check. This case assumes that no further access control checks are desired for the ICMP packet. For case 2: a. The sender extracts ICMP type and code and does an SPD lookup to find an appropriate SA. (The Sender only does fast path processing.) b. The receiver processes the ICMP packet on the SA via which it was received, verifying that the ICMP type and code of the message match the selectors for the SA. If they do, then the receiver passes the ICMP message to slow path processing. The selectors of the enclosed packet are extracted and matched against the SPD-S cache, to ensure that the enclosed packet is consistent with its source. If they do, the ICMP message is passed along for further processing, e.g., PMTU check. (The receiver does both fast path and slow path processing.) Note that an ICMP packet may arrive on an SA unrelated to the SA used for the triggering packet. The sender will use the first SPD or SPD-S cache entry that it comes to that is configured to carry ICMP traffic of the given type and code. Even if the SA for the triggering packet is configured to carry ICMP traffic, there may be an earlier entry in the SPD that matches the ICMP message's type and code. So one has to search the outbound SPD-S cache to verify whether or not there's an extant SA for the enclosed (triggering) packet. Proposed approach To simplify the processing done by the Sender (of the ICMP message) to find the SA to use for sending the ICMP message and to support access control checks on the ICMP messages (using ICMP Message Type and Code) by the Receiver, we propose to use the second approach. Note: In the second approach, there is no requirement that the SA used for the ICMP message be dedicated only to ICMP messages. To minimize the number of SAs between two IPsec systems, an administrator may wish to configure the SPD such that the ICMP messages may be combined with other traffic, i.e., by specifying SPD entries that carry both normal traffic and ICMP traffic. Comments? Thank you, Karen From ipsec-admin@ietf.org Tue Apr 13 20:07:01 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3E371bI032173; Tue, 13 Apr 2004 20:07:01 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDaZG-0004oL-Mj; Tue, 13 Apr 2004 22:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDaUf-00044P-6W for ipsec@optimus.ietf.org; Tue, 13 Apr 2004 22:51:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25982 for ; Tue, 13 Apr 2004 22:51:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDaUb-0004H2-00 for ipsec@ietf.org; Tue, 13 Apr 2004 22:51:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDaTr-0004As-00 for ipsec@ietf.org; Tue, 13 Apr 2004 22:50:28 -0400 Received: from mails.tsinghua.edu.cn ([166.111.8.16]) by ietf-mx with smtp (Exim 4.12) id 1BDaT3-000405-00 for ipsec@ietf.org; Tue, 13 Apr 2004 22:49:37 -0400 Received: (eyou send program); Wed, 14 Apr 2004 10:44:42 +0800 Message-ID: <281910682.23116@mails.tsinghua.edu.cn> Received: from unknown (HELO mails.tsinghua.edu.cn) (unknown@127.0.0.1) by 127.0.0.1 with SMTP; Wed, 14 Apr 2004 10:44:42 +0800 X-scanvirus: By Symantec Scan Engine X-scanresult: CLEAN Received: (eqmail ); 14 Apr 2004 02:44:42 -0000 Received: from unknown (HELO csnetlab-zcd) (zcd03@166.111.68.231) by mails.tsinghua.edu.cn with SMTP; 14 Apr 2004 02:44:42 -0000 Date: Wed, 14 Apr 2004 10:49:43 +0800 From: "zcd" To: "ipsec" X-mailer: Foxmail 5.0 beta1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.0 required=5.0 tests=FROM_ENDS_IN_NUMS, MAILTO_TO_SPAM_ADDR,MSGID_FROM_MTA_HEADER,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Ipsec] (no subject) Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , zcd03@mails.tsinghua.edu.cn _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 13 23:57:09 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3E6v8bV094268; Tue, 13 Apr 2004 23:57:09 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDeFd-0005qj-Ok; Wed, 14 Apr 2004 02:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDe9G-00051i-UX for ipsec@optimus.ietf.org; Wed, 14 Apr 2004 02:45:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04385 for ; Wed, 14 Apr 2004 02:45:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDe9D-0000UC-00 for ipsec@ietf.org; Wed, 14 Apr 2004 02:45:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDe8T-0000Nf-00 for ipsec@ietf.org; Wed, 14 Apr 2004 02:44:37 -0400 Received: from vsmtp3alice.tin.it ([212.216.176.143]) by ietf-mx with esmtp (Exim 4.12) id 1BDe7t-0000BA-00 for ipsec@ietf.org; Wed, 14 Apr 2004 02:44:02 -0400 Received: from cappone (82.49.97.74) by vsmtp3alice.tin.it (7.0.027) id 4061BAA6001221F4 for ipsec@ietf.org; Wed, 14 Apr 2004 08:43:32 +0200 Message-ID: <001601c421eb$b43e4ef0$2101a8c0@cappone> From: "Giacomo Pisano" To: Date: Wed, 14 Apr 2004 08:42:49 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C421FC.775AA180" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_MESSAGE, MIME_HTML_MOSTLY autolearn=no version=2.60 Subject: [Ipsec] (no subject) Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C421FC.775AA180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0013_01C421FC.775AA180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0013_01C421FC.775AA180-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 14 00:16:27 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3E7GQOt002483; Wed, 14 Apr 2004 00:16:26 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDeW8-0000a4-A6; Wed, 14 Apr 2004 03:09:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDeTa-00089p-An for ipsec@optimus.ietf.org; Wed, 14 Apr 2004 03:06:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05240 for ; Wed, 14 Apr 2004 03:06:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDeTV-0002uB-00 for ipsec@ietf.org; Wed, 14 Apr 2004 03:06:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDeSc-0002mz-00 for ipsec@ietf.org; Wed, 14 Apr 2004 03:05:27 -0400 Received: from vsmtp3alice.tin.it ([212.216.176.143]) by ietf-mx with esmtp (Exim 4.12) id 1BDeRz-0002f5-00 for ipsec@ietf.org; Wed, 14 Apr 2004 03:04:48 -0400 Received: from cappone (82.49.97.74) by vsmtp3alice.tin.it (7.0.027) id 4061BAA6001223C0 for ipsec@ietf.org; Wed, 14 Apr 2004 09:04:19 +0200 Message-ID: <012c01c421ee$9b83dda0$2101a8c0@cappone> From: "Giacomo Pisano" To: Date: Wed, 14 Apr 2004 09:03:36 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0129_01C421FF.5EAF9980" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 Subject: [Ipsec] ipsec on WLAN Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0129_01C421FF.5EAF9980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I'm a novice but i'm trying to make IPSec work on WLAN in order to = use level3 security instead of level2. Has anyone of you tried to do the = same?? I don't have any idea of what to do! TNX ------=_NextPart_000_0129_01C421FF.5EAF9980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi, I'm a novice but i'm trying to make = IPSec work=20 on WLAN in order to use level3 security instead of level2. Has anyone of = you=20 tried to do the same?? I don't have any idea of what to do!
 
TNX
 
------=_NextPart_000_0129_01C421FF.5EAF9980-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 14 00:42:53 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3E7gpmg013488; Wed, 14 Apr 2004 00:42:53 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDeuI-0003wq-7x; Wed, 14 Apr 2004 03:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDeoi-0003LA-Tn for ipsec@optimus.ietf.org; Wed, 14 Apr 2004 03:28:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06170 for ; Wed, 14 Apr 2004 03:28:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDeog-0005Vd-00 for ipsec@ietf.org; Wed, 14 Apr 2004 03:28:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDeng-0005PE-00 for ipsec@ietf.org; Wed, 14 Apr 2004 03:27:13 -0400 Received: from sparte.int-evry.fr ([157.159.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1BDemg-0005BM-00 for ipsec@ietf.org; Wed, 14 Apr 2004 03:26:10 -0400 Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 866BD302DB for ; Wed, 14 Apr 2004 09:23:42 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.1.0.29) with SMTP id M2004041409253021138 for ; Wed, 14 Apr 2004 09:25:30 +0200 Received: from cesium.int-evry.fr (bernard.int-evry.fr [157.159.100.53]) by sparte.int-evry.fr (Postfix) with ESMTP id 7A4BE302DB for ; Wed, 14 Apr 2004 09:23:42 +0200 (CEST) Received: from jjp by cesium.int-evry.fr with local id 1BDemU-00005u-00 for ; Wed, 14 Apr 2004 09:25:58 +0200 Date: Wed, 14 Apr 2004 09:25:58 +0200 From: Jean-Jacques Puig To: ipsec@ietf.org Subject: Re: [Ipsec] ipsec on WLAN Message-ID: <20040414072558.GA32067@ivan.int-evry.fr> Mail-Followup-To: ipsec@ietf.org References: <012c01c421ee$9b83dda0$2101a8c0@cappone> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012c01c421ee$9b83dda0$2101a8c0@cappone> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , On Wed, Apr 14, 2004 at 09:03:36AM +0200, Giacomo Pisano wrote: > Hi, I'm a novice but i'm trying to make IPSec work on WLAN in order to use > level3 security instead of level2. Has anyone of you tried to do the > same?? I don't have any idea of what to do! Hi, It all depends on what you want to achieve. If you really want to use level3 instead of level 2, then you will set a tunnel between your laptop and a security gateway behind the access point (in the access network). Depending on the scenario, it may be more interesting to set the tunnel with destination's security gateway or to use transport mode directly with destination. Anyway, may be you should begin with a look at http://www.wavesec.org/ -- Jean-Jacques Puig [homepage] http://www-lor.int-evry.fr/~puig/ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 14 01:30:31 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3E8US2i032955; Wed, 14 Apr 2004 01:30:29 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDfdo-0003e4-69; Wed, 14 Apr 2004 04:21:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDfZF-0002sG-4t for ipsec@optimus.ietf.org; Wed, 14 Apr 2004 04:16:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07489 for ; Wed, 14 Apr 2004 04:16:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDfZ5-0002hB-00 for ipsec@ietf.org; Wed, 14 Apr 2004 04:16:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDfXP-0002aj-00 for ipsec@ietf.org; Wed, 14 Apr 2004 04:14:27 -0400 Received: from washington.noc11.net ([66.192.185.4]) by ietf-mx with esmtp (Exim 4.12) id 1BDfWT-0002UR-00 for ipsec@ietf.org; Wed, 14 Apr 2004 04:13:29 -0400 Received: from [81.196.95.177] (helo=yo2lux) by washington.noc11.net with smtp (Exim 4.24) id 1BDfWf-0007mA-Ve; Wed, 14 Apr 2004 01:13:42 -0700 Message-ID: <002101c421f8$58105d50$040aa8c0@yo2lux> From: "yo2lux" To: "Giacomo Pisano" , References: <012c01c421ee$9b83dda0$2101a8c0@cappone> Subject: Re: [Ipsec] ipsec on WLAN Date: Wed, 14 Apr 2004 11:13:13 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C42211.7A6F4F00" 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-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - washington.noc11.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - wplink.net X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C42211.7A6F4F00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable you want to make an IPSec between OpenBSD and Windows ?=20 ----- Original Message -----=20 From: Giacomo Pisano=20 To: ipsec@ietf.org=20 Sent: Wednesday, April 14, 2004 10:03 AM Subject: [Ipsec] ipsec on WLAN Hi, I'm a novice but i'm trying to make IPSec work on WLAN in order to = use level3 security instead of level2. Has anyone of you tried to do the = same?? I don't have any idea of what to do! TNX ------=_NextPart_000_001C_01C42211.7A6F4F00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
you want to make an IPSec between = OpenBSD and=20 Windows ?
----- Original Message -----
From:=20 Giacomo=20 Pisano
Sent: Wednesday, April 14, 2004 = 10:03=20 AM
Subject: [Ipsec] ipsec on = WLAN

Hi, I'm a novice but i'm trying to = make IPSec=20 work on WLAN in order to use level3 security instead of level2. Has = anyone of=20 you tried to do the same?? I don't have any idea of what to = do!
 
TNX
 
------=_NextPart_000_001C_01C42211.7A6F4F00-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 14 01:47:59 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3E8lvY0039992; Wed, 14 Apr 2004 01:47:58 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDfpP-0005zs-Ds; Wed, 14 Apr 2004 04:33:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDfju-0004aL-KY for ipsec@optimus.ietf.org; Wed, 14 Apr 2004 04:27:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09091 for ; Wed, 14 Apr 2004 04:27:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDfjr-00043D-00 for ipsec@ietf.org; Wed, 14 Apr 2004 04:27:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDfj0-0003wH-00 for ipsec@ietf.org; Wed, 14 Apr 2004 04:26:26 -0400 Received: from vsmtp3alice.tin.it ([212.216.176.143]) by ietf-mx with esmtp (Exim 4.12) id 1BDfhz-0003hj-00 for ipsec@ietf.org; Wed, 14 Apr 2004 04:25:23 -0400 Received: from cappone (82.49.97.74) by vsmtp3alice.tin.it (7.0.027) id 4061BAA600123DE9 for ipsec@ietf.org; Wed, 14 Apr 2004 10:24:53 +0200 Message-ID: <000a01c421f9$dc62eae0$2101a8c0@cappone> From: "Giacomo Pisano" To: Date: Wed, 14 Apr 2004 10:24:09 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C4220A.9F89EBD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Subject: [Ipsec] ipsec on WLAN Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C4220A.9F89EBD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have one client (possibly Windows) one AP and a server (possibly = Windows).......do you think it's possible to make the server act as a = getway for the LAN?? I need to build an IPSec Tunnel between the wi-fi = client and the server. The server then has to relay the data on the LAN = and viceversa. What I'm trying to secure is just the radio link ------=_NextPart_000_0007_01C4220A.9F89EBD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have one client (possibly Windows) = one AP and a=20 server (possibly Windows).......do you think it's possible to make the = server=20 act as a getway for the LAN?? I need to build an IPSec Tunnel between = the wi-fi=20 client and the server. The server then has to relay the data on the LAN = and=20 viceversa.
 
What I'm trying to secure is just the = radio=20 link
 
------=_NextPart_000_0007_01C4220A.9F89EBD0-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 14 02:04:02 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3E940KM046500; Wed, 14 Apr 2004 02:04:01 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDg8k-0001gi-49; Wed, 14 Apr 2004 04:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDg4P-0000IN-VQ for ipsec@optimus.ietf.org; Wed, 14 Apr 2004 04:48:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09872 for ; Wed, 14 Apr 2004 04:48:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDg4N-0006X0-00 for ipsec@ietf.org; Wed, 14 Apr 2004 04:48:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDg3M-0006NV-00 for ipsec@ietf.org; Wed, 14 Apr 2004 04:47:29 -0400 Received: from vsmtp3alice.tin.it ([212.216.176.143]) by ietf-mx with esmtp (Exim 4.12) id 1BDg2P-00069y-00 for ipsec@ietf.org; Wed, 14 Apr 2004 04:46:29 -0400 Received: from cappone (82.49.97.74) by vsmtp3alice.tin.it (7.0.027) id 4061BAA600124622; Wed, 14 Apr 2004 10:45:57 +0200 Message-ID: <001101c421fc$cde9bfe0$2101a8c0@cappone> From: "Giacomo Pisano" To: "yo2lux" , References: <012c01c421ee$9b83dda0$2101a8c0@cappone> <002101c421f8$58105d50$040aa8c0@yo2lux> Subject: Re: [Ipsec] ipsec on WLAN Date: Wed, 14 Apr 2004 10:45:13 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C4220D.90F0B5B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C4220D.90F0B5B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have one client (possibly Windows) one AP and a server (possibly = Windows).......do you think it's possible to make the server act as a = getway for the LAN?? I need to build an IPSec Tunnel between the wi-fi = client and the server. The server then has to relay the data on the LAN = and viceversa. What I'm trying to secure is just the radio link ----- Original Message -----=20 From: yo2lux=20 To: Giacomo Pisano ; ipsec@ietf.org=20 Sent: Wednesday, April 14, 2004 10:13 AM Subject: Re: [Ipsec] ipsec on WLAN you want to make an IPSec between OpenBSD and Windows ?=20 ----- Original Message -----=20 From: Giacomo Pisano=20 To: ipsec@ietf.org=20 Sent: Wednesday, April 14, 2004 10:03 AM Subject: [Ipsec] ipsec on WLAN Hi, I'm a novice but i'm trying to make IPSec work on WLAN in order = to use level3 security instead of level2. Has anyone of you tried to do = the same?? I don't have any idea of what to do! TNX ------=_NextPart_000_000E_01C4220D.90F0B5B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have one client (possibly Windows) = one AP and a=20 server (possibly Windows).......do you think it's possible to make the = server=20 act as a getway for the LAN?? I need to build an IPSec Tunnel between = the wi-fi=20 client and the server. The server then has to relay the data on the LAN = and=20 viceversa.
 
What I'm trying to secure is just the = radio=20 link
 
----- Original Message -----
From:=20 yo2lux =
To: Giacomo=20 Pisano ; ipsec@ietf.org
Sent: Wednesday, April 14, 2004 = 10:13=20 AM
Subject: Re: [Ipsec] ipsec on = WLAN

you want to make an IPSec between=20 OpenBSD and Windows ?
----- Original Message -----
From:=20 Giacomo=20 Pisano
Sent: Wednesday, April 14, = 2004 10:03=20 AM
Subject: [Ipsec] ipsec on = WLAN

Hi, I'm a novice but i'm trying to = make IPSec=20 work on WLAN in order to use level3 security instead of level2. Has = anyone=20 of you tried to do the same?? I don't have any idea of what to=20 do!
 
TNX
 
------=_NextPart_000_000E_01C4220D.90F0B5B0-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 14 03:43:51 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3EAhnn0066788; Wed, 14 Apr 2004 03:43:50 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDheh-0004qt-KZ; Wed, 14 Apr 2004 06:30:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDha9-0003Mf-Gh for ipsec@optimus.ietf.org; Wed, 14 Apr 2004 06:25:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13948 for ; Wed, 14 Apr 2004 06:25:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDha5-0002rT-00 for ipsec@ietf.org; Wed, 14 Apr 2004 06:25:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDhZ7-0002kc-00 for ipsec@ietf.org; Wed, 14 Apr 2004 06:24:21 -0400 Received: from web61007.mail.yahoo.com ([216.155.196.96]) by ietf-mx with smtp (Exim 4.12) id 1BDhY9-0002YA-00 for ipsec@ietf.org; Wed, 14 Apr 2004 06:23:21 -0400 Message-ID: <20040414102253.82608.qmail@web61007.mail.yahoo.com> Received: from [143.53.66.94] by web61007.mail.yahoo.com via HTTP; Wed, 14 Apr 2004 03:22:52 PDT Date: Wed, 14 Apr 2004 03:22:52 -0700 (PDT) From: shaga asha To: ipsec@ietf.org In-Reply-To: <000a01c421f9$dc62eae0$2101a8c0@cappone> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1174649575-1081938172=:82373" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 Subject: [Ipsec] VPN and IPSec Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , --0-1174649575-1081938172=:82373 Content-Type: text/plain; charset=us-ascii Hi all, As issues on IPSec and WLAN is being discussed, I will be grateful if anybody will throw more light on setting VPN using IPSec. As I am currently trying to set up VPN using IPSec and MPLS. I am using linux platform. Ideas are highly welcome. Cheers Shaga --------------------------------- Do you Yahoo!? Yahoo! Tax Center - File online by April 15th --0-1174649575-1081938172=:82373 Content-Type: text/html; charset=us-ascii


Hi all,
 
As issues on IPSec and WLAN is being discussed, I will be grateful if anybody will throw more light on setting VPN using IPSec. As I am currently trying to set up VPN using IPSec and MPLS. I am using linux platform.
Ideas are highly welcome.
Cheers
Shaga

Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th --0-1174649575-1081938172=:82373-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From owner-ipsec@lists.tislabs.com Wed Apr 14 05:37:49 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3ECbmsR078875; Wed, 14 Apr 2004 05:37:48 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.11.6/8.11.6) id i3EBsIO10922 for ipsec-outgoing; Wed, 14 Apr 2004 07:54:18 -0400 (EDT) X-Authentication-Warning: portal.tislabs.com: majordom set sender to owner-ipsec@lists.tislabs.com using -f X-Scanned: Wed, 14 Apr 2004 14:50:52 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IKEv2 AUTH payload Date: Wed, 14 Apr 2004 14:48:42 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61223CC@esebe023.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IKEv2 AUTH payload Thread-Index: AcQezmTsV7+6hggQRA+VDD3SjwkyWADQ/2Zw From: To: , X-OriginalArrivalTime: 14 Apr 2004 11:48:42.0389 (UTC) FILETIME=[6F39A450:01C42216] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id i3EBs2110870 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yoav Nir wrote: > > I still haven't received any responses to my question of last > week, about what to do if the autentication exchange is repeated > later on. It appears that in order to support this, I would have > to store the old initial exchanges so as to produce and verify the > AUTH payloads, but that seems wasteful. I don't think that storing the initial exchange messages, or even re-keying, is that big a problem if the reauthentication works just fine. However, as you pointed out, IKEv2 spec does not really talk about reauthentication at all... At least additional IKE_AUTH exchanges are not allowed (within the same SA) after the first authentication has completed. Presumably the original initiator could start a new IKE SA from scratch, establish new child SAs (for the same "internal" address in remote access VPN gateway situations, without REKEY flag), and then delete the old IKE SA and the old child SAs, right? However, at least when EAP is used, the original responder ("VPN gateway") can't trigger this reauthentication... because if it created a new IKE SA, it would be the initiator in that. Any ideas how to solve this? Perhaps the gateway (original responder) could delete the old IKE SA (with Delete payload), and that would signal the client (initiator) to start from scratch? Or perhaps a notification message should be used? Or perhaps additional IKE_AUTH exchange could be allowed within the same IKE SA? (IMHO the notification sounds like the simplest approach, if it actually works; there might be some aspects I haven't considered. The overhead of setting up a new IKE SA is probably not very serious if reauthentication happens every couple of hours or so.) Best regards, Pasi From ipsec-admin@ietf.org Wed Apr 14 05:57:00 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3ECuxFI080943; Wed, 14 Apr 2004 05:57:00 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDjkM-0006A7-JV; Wed, 14 Apr 2004 08:44:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDjh4-0005SZ-Ic for ipsec@optimus.ietf.org; Wed, 14 Apr 2004 08:40:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21135 for ; Wed, 14 Apr 2004 08:40:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDjh1-0004SQ-00 for ipsec@ietf.org; Wed, 14 Apr 2004 08:40:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDjgC-0004Kg-00 for ipsec@ietf.org; Wed, 14 Apr 2004 08:39:49 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BDjfg-0004Cm-00 for ipsec@ietf.org; Wed, 14 Apr 2004 08:39:16 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3ECce114990 for ; Wed, 14 Apr 2004 08:38:40 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3ECaSQm003956 for ; Wed, 14 Apr 2004 08:36:28 -0400 (EDT) Received: from michael.checkpoint.com(194.29.32.68) by nutshell.tislabs.com via csmap (V6.0) id srcAAA68aimh; Wed, 14 Apr 04 08:34:51 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i3ECax917597; Wed, 14 Apr 2004 15:36:59 +0300 (IDT) In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61223CC@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A61223CC@esebe023.ntc.nokia.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6C08C547-8E10-11D8-A925-000A95834BAA@checkpoint.com> Content-Transfer-Encoding: 7bit Cc: From: Yoav Nir Date: Wed, 14 Apr 2004 15:36:59 +0300 To: X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Ipsec] Re: IKEv2 AUTH payload Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , It's a pity we haven't thought of it months ago. I think there is a general consensus that it is too late now to do anything so radical as add new exchange types. I don't like the idea of the gateway triggering a new authentication with a DELETE notification, because a delete notification requires the client to delete all the child SAs. If the EAP method requires the user to enter a password (or the token card value) this means many seconds without an IPSec SA. That could kill an ongoing FTP, Telnet or mail download. A better solution would be a notification within the original IKE_AUTH exchange, where the gateway tells the client how long the authentication is valid. In essence, the gateway tells the client to re-authenticate within 2 hours. A properly designed client will ask the user for a password 5 minutes before the deadline, and begin a new initial exchange from scratch. This way, the IKE and IPSec SAs can be replaced without a loss of connectivity. If the client does not re-authenticate in time, then the gateway can send a delete notification. We could add an AUTH_LIFETIME notification (16395?) with 4 bytes of data signifying the time (in seconds) before the authentication expires. If it's too late for it to enter the IKEv2 RFC, it can still be used as a private notification. In IKEv1 few configure an IKE SA lifetime shorter than 2 hours. Many extend it to 24 hours. The worst interoperability problem that could happen, is that clients abruptly disconnect after 2 hours. Does that sound reasonable? On Apr 14, 2004, at 2:48 PM, wrote: > Yoav Nir wrote: >> >> I still haven't received any responses to my question of last >> week, about what to do if the autentication exchange is repeated >> later on. It appears that in order to support this, I would have >> to store the old initial exchanges so as to produce and verify the >> AUTH payloads, but that seems wasteful. > > I don't think that storing the initial exchange messages, or > even re-keying, is that big a problem if the reauthentication > works just fine. > > However, as you pointed out, IKEv2 spec does not really talk > about reauthentication at all... At least additional IKE_AUTH > exchanges are not allowed (within the same SA) after the first > authentication has completed. > > Presumably the original initiator could start a new IKE SA from > scratch, establish new child SAs (for the same "internal" address > in remote access VPN gateway situations, without REKEY flag), and > then delete the old IKE SA and the old child SAs, right? > > However, at least when EAP is used, the original responder > ("VPN gateway") can't trigger this reauthentication... because > if it created a new IKE SA, it would be the initiator in that. > > Any ideas how to solve this? > > Perhaps the gateway (original responder) could delete the old > IKE SA (with Delete payload), and that would signal the client > (initiator) to start from scratch? Or perhaps a notification message > should be used? Or perhaps additional IKE_AUTH exchange could > be allowed within the same IKE SA? > > (IMHO the notification sounds like the simplest approach, > if it actually works; there might be some aspects I haven't > considered. The overhead of setting up a new IKE SA is probably > not very serious if reauthentication happens every couple > of hours or so.) > > Best regards, > Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 14 06:05:45 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3ED5iEt081895; Wed, 14 Apr 2004 06:05:45 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDjxs-0000dF-1s; Wed, 14 Apr 2004 08:58:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDjpd-00078z-4v for ipsec@optimus.ietf.org; Wed, 14 Apr 2004 08:49:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21738 for ; Wed, 14 Apr 2004 08:49:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDjpb-00060x-00 for ipsec@ietf.org; Wed, 14 Apr 2004 08:49:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDjoh-0005qo-00 for ipsec@ietf.org; Wed, 14 Apr 2004 08:48:35 -0400 Received: from washington.noc11.net ([66.192.185.4]) by ietf-mx with esmtp (Exim 4.12) id 1BDjno-0005fF-00 for ipsec@ietf.org; Wed, 14 Apr 2004 08:47:40 -0400 Received: from [81.196.95.177] (helo=yo2lux) by washington.noc11.net with smtp (Exim 4.24) id 1BDjnp-0000r3-47; Wed, 14 Apr 2004 05:47:41 -0700 Message-ID: <000201c4221e$a22bcfc0$040aa8c0@yo2lux> From: "yo2lux" To: "Giacomo Pisano" , References: <000a01c421f9$dc62eae0$2101a8c0@cappone> Subject: Re: [Ipsec] ipsec on WLAN Date: Wed, 14 Apr 2004 15:36:21 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C42236.3CA98EE0" 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-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - washington.noc11.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - wplink.net X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C42236.3CA98EE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have a gateway that run OpenBSD. This OpenBSD gateway do NAT for = windows clients and i have IPSec between OpenBSD and windows clients = using wi-fi. On windows you need a commercial vpn client like SSH Sentinel or = SoftRemote. This softwares work with ISAKMPD (OpenBSD). use this webpage for help : www.allard.nu/openbsd/ ----- Original Message -----=20 From: Giacomo Pisano=20 To: ipsec@ietf.org=20 Sent: Wednesday, April 14, 2004 11:24 AM Subject: [Ipsec] ipsec on WLAN I have one client (possibly Windows) one AP and a server (possibly = Windows).......do you think it's possible to make the server act as a = getway for the LAN?? I need to build an IPSec Tunnel between the wi-fi = client and the server. The server then has to relay the data on the LAN = and viceversa. What I'm trying to secure is just the radio link ------=_NextPart_000_0022_01C42236.3CA98EE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have a gateway that run OpenBSD. = This=20 OpenBSD gateway do NAT for windows clients and i have IPSec between = OpenBSD and=20 windows clients using wi-fi.
 
On windows you need a commercial vpn = client like=20 SSH Sentinel or SoftRemote. This softwares work with ISAKMPD=20 (OpenBSD).
 
use this webpage for help : www.allard.nu/openbsd/<= /DIV>
 
 
 
 
 
 
----- Original Message -----
From:=20 Giacomo=20 Pisano
Sent: Wednesday, April 14, 2004 = 11:24=20 AM
Subject: [Ipsec] ipsec on = WLAN

I have one client (possibly Windows) = one AP and a=20 server (possibly Windows).......do you think it's possible to make the = server=20 act as a getway for the LAN?? I need to build an IPSec Tunnel between = the=20 wi-fi client and the server. The server then has to relay the data on = the LAN=20 and viceversa.
 
What I'm trying to secure is just the = radio=20 link
 
------=_NextPart_000_0022_01C42236.3CA98EE0-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 14 06:27:42 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3EDRcIK085053; Wed, 14 Apr 2004 06:27:41 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDkL7-0005lb-4m; Wed, 14 Apr 2004 09:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDkHl-0004qq-LQ for ipsec@optimus.ietf.org; Wed, 14 Apr 2004 09:18:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23122 for ; Wed, 14 Apr 2004 09:18:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDkHk-0002Ew-00 for ipsec@ietf.org; Wed, 14 Apr 2004 09:18:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDkGr-00028Q-00 for ipsec@ietf.org; Wed, 14 Apr 2004 09:17:41 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1BDkGP-00021d-00 for ipsec@ietf.org; Wed, 14 Apr 2004 09:17:13 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i3EDH8gH029360; Wed, 14 Apr 2004 22:17:08 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i3EDH8Rc001649; Wed, 14 Apr 2004 22:17:08 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id YAA01648 ; Wed, 14 Apr 2004 22:17:08 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id WAA04448; Wed, 14 Apr 2004 22:17:07 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id WAA12933; Wed, 14 Apr 2004 22:17:07 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i3EDH6a3001756; Wed, 14 Apr 2004 22:17:06 +0900 (JST) Received: from steelhead ([172.30.24.114]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HW500AM7WWFL6@tsbpo1.po.toshiba.co.jp>; Wed, 14 Apr 2004 22:17:05 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BDY7v-0003eB-00; Tue, 13 Apr 2004 17:19:39 -0700 Date: Tue, 13 Apr 2004 17:19:39 -0700 From: Yoshihiro Ohba Subject: Re: [Ipsec] ipsec on WLAN In-reply-to: <001101c421fc$cde9bfe0$2101a8c0@cappone> To: Giacomo Pisano Cc: yo2lux , ipsec@ietf.org Message-id: <20040414001939.GN11313@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i References: <012c01c421ee$9b83dda0$2101a8c0@cappone> <002101c421f8$58105d50$040aa8c0@yo2lux> <001101c421fc$cde9bfe0$2101a8c0@cappone> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , An IPsec usage in WLAN is being discussed in the PANA WG. There are several drafts related to the usage: draft-ietf-pana-ipsec-02.txt draft-ohba-pana-framework-00.txt Regards, Yoshihiro Ohba On Wed, Apr 14, 2004 at 10:45:13AM +0200, Giacomo Pisano wrote: > I have one client (possibly Windows) one AP and a server (possibly Windows).......do you think it's possible to make the server act as a getway for the LAN?? I need to build an IPSec Tunnel between the wi-fi client and the server. The server then has to relay the data on the LAN and viceversa. > > What I'm trying to secure is just the radio link > > ----- Original Message ----- > From: yo2lux > To: Giacomo Pisano ; ipsec@ietf.org > Sent: Wednesday, April 14, 2004 10:13 AM > Subject: Re: [Ipsec] ipsec on WLAN > > > you want to make an IPSec between OpenBSD and Windows ? > ----- Original Message ----- > From: Giacomo Pisano > To: ipsec@ietf.org > Sent: Wednesday, April 14, 2004 10:03 AM > Subject: [Ipsec] ipsec on WLAN > > > Hi, I'm a novice but i'm trying to make IPSec work on WLAN in order to use level3 security instead of level2. Has anyone of you tried to do the same?? I don't have any idea of what to do! > > TNX > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 14 09:33:07 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3EGX5S5011138; Wed, 14 Apr 2004 09:33:06 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnBU-0004zT-AW; Wed, 14 Apr 2004 12:24:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmHz-0003Sd-QK for ipsec@optimus.ietf.org; Wed, 14 Apr 2004 11:26:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01402 for ; Wed, 14 Apr 2004 11:26:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDmHy-0001r8-00 for ipsec@ietf.org; Wed, 14 Apr 2004 11:26:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDmH0-0001qB-00 for ipsec@ietf.org; Wed, 14 Apr 2004 11:25:59 -0400 Received: from vsmtp3alice.tin.it ([212.216.176.143]) by ietf-mx with esmtp (Exim 4.12) id 1BDmGL-0001oh-00 for ipsec@ietf.org; Wed, 14 Apr 2004 11:25:17 -0400 Received: from cappone (82.49.97.74) by vsmtp3alice.tin.it (7.0.027) id 4061BAA60012D07D; Wed, 14 Apr 2004 17:24:33 +0200 Message-ID: <001101c42234$7d088290$2101a8c0@cappone> From: "Giacomo Pisano" To: "Yoshihiro Ohba" Cc: "yo2lux" , References: <012c01c421ee$9b83dda0$2101a8c0@cappone> <002101c421f8$58105d50$040aa8c0@yo2lux> <001101c421fc$cde9bfe0$2101a8c0@cappone> <20040414001939.GN11313@steelhead> Subject: Re: [Ipsec] ipsec on WLAN Date: Wed, 14 Apr 2004 17:23:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , If i used a Gateway such as FreesWan for Linux i'm afrad that I could only cipher the tunnel between the client and the gateway whilst i need to chipher the traffic between each mobile client as well. ----- Original Message ----- From: "Yoshihiro Ohba" To: "Giacomo Pisano" Cc: "yo2lux" ; Sent: Wednesday, April 14, 2004 2:19 AM Subject: Re: [Ipsec] ipsec on WLAN > An IPsec usage in WLAN is being discussed in the PANA WG. > There are several drafts related to the usage: > > draft-ietf-pana-ipsec-02.txt > draft-ohba-pana-framework-00.txt > > Regards, > > Yoshihiro Ohba > > > On Wed, Apr 14, 2004 at 10:45:13AM +0200, Giacomo Pisano wrote: > > I have one client (possibly Windows) one AP and a server (possibly Windows).......do you think it's possible to make the server act as a getway for the LAN?? I need to build an IPSec Tunnel between the wi-fi client and the server. The server then has to relay the data on the LAN and viceversa. > > > > What I'm trying to secure is just the radio link > > > > ----- Original Message ----- > > From: yo2lux > > To: Giacomo Pisano ; ipsec@ietf.org > > Sent: Wednesday, April 14, 2004 10:13 AM > > Subject: Re: [Ipsec] ipsec on WLAN > > > > > > you want to make an IPSec between OpenBSD and Windows ? > > ----- Original Message ----- > > From: Giacomo Pisano > > To: ipsec@ietf.org > > Sent: Wednesday, April 14, 2004 10:03 AM > > Subject: [Ipsec] ipsec on WLAN > > > > > > Hi, I'm a novice but i'm trying to make IPSec work on WLAN in order to use level3 security instead of level2. Has anyone of you tried to do the same?? I don't have any idea of what to do! > > > > TNX > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 14 09:38:45 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3EGcif6011928; Wed, 14 Apr 2004 09:38:44 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnBc-00052C-Kr; Wed, 14 Apr 2004 12:24:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmVA-0006Dr-0r for ipsec@optimus.ietf.org; Wed, 14 Apr 2004 11:40:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02217 for ; Wed, 14 Apr 2004 11:40:33 -0400 (EDT) From: kseo@bbn.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDmV8-0002cB-00 for ipsec@ietf.org; Wed, 14 Apr 2004 11:40:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDmUM-0002Ue-00 for ipsec@ietf.org; Wed, 14 Apr 2004 11:39:46 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BDmT8-0002KB-00 for ipsec@ietf.org; Wed, 14 Apr 2004 11:38:30 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3EFbl125799 for ; Wed, 14 Apr 2004 11:37:47 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3EFZqxh007439 for ; Wed, 14 Apr 2004 11:35:52 -0400 (EDT) Received: from aragorn.bbn.com(128.33.0.62) by nutshell.tislabs.com via csmap (V6.0) id srcAAAIAa4ro; Wed, 14 Apr 04 11:35:15 -0400 Received: from po2.bbn.com (po2.bbn.com [128.33.0.56]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i3EFbU7W026365 for ; Wed, 14 Apr 2004 11:37:31 -0400 (EDT) Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by po2.bbn.com (8.10.2+Sun/8.10.2) with ESMTP id i3EFbU616224; Wed, 14 Apr 2004 11:37:30 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Wed, 14 Apr 2004 11:44:13 -0400 To: ipsec@lists.tislabs.com Cc: kseo@po2.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.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Subject: [Ipsec] Re: 2401bis -- Issue 91 -- handling ICMP error messages Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Folks, Re: whether or not this discussion applies to ICMPv6 (as well as ICMPv4).... I just checked the ICMPv6 spec (RFC2463) and didn't see anything that should cause problems. So I think the proposed approach should work for ICMPv6 too. Comments/corrections? (Thanks go to Rich Graveman for reminding us about ICMPv6) Thank you, Karen _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 14 09:52:43 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3EGqg0d013762; Wed, 14 Apr 2004 09:52:42 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnCM-0005OY-4r; Wed, 14 Apr 2004 12:25:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDmvp-0002EB-4t for ipsec@optimus.ietf.org; Wed, 14 Apr 2004 12:08:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03452 for ; Wed, 14 Apr 2004 12:08:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDmvn-0003nR-00 for ipsec@ietf.org; Wed, 14 Apr 2004 12:08:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDmuv-0003kU-00 for ipsec@ietf.org; Wed, 14 Apr 2004 12:07:14 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BDmuA-0003iA-00 for ipsec@ietf.org; Wed, 14 Apr 2004 12:06:26 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3EG5s127592 for ; Wed, 14 Apr 2004 12:05:55 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3EG3PHj012376 for ; Wed, 14 Apr 2004 12:03:25 -0400 (EDT) Received: from thunk.org(140.239.227.29) by nutshell.tislabs.com via csmap (V6.0) id srcAAACwaW_x; Wed, 14 Apr 04 12:02:22 -0400 Received: from dsl092-109-027.nyc2.dsl.speakeasy.net ([66.92.109.27] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1BDmsI-0002xw-00; Wed, 14 Apr 2004 12:04:30 -0400 Received: from tytso by thunk.org with local (Exim 4.31) id 1BDmsH-0002x3-8l; Wed, 14 Apr 2004 12:04:29 -0400 To: ipsec@lists.tislabs.com From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Wed, 14 Apr 2004 12:04:29 -0400 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 . X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-7.9 required=5.0 tests=AWL,HABEAS_SWE autolearn=no version=2.60 Subject: [Ipsec] Testing, please ignore Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Testing, please ignore - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 14 10:35:35 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3EHZYfJ019365; Wed, 14 Apr 2004 10:35:35 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDo4N-0002i0-AF; Wed, 14 Apr 2004 13:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDns3-0007Pl-2j for ipsec@optimus.ietf.org; Wed, 14 Apr 2004 13:08:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07060 for ; Wed, 14 Apr 2004 13:08:16 -0400 (EDT) From: Atul.Sharma@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDns1-0000Jk-00 for ipsec@ietf.org; Wed, 14 Apr 2004 13:08:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDnr7-0000G3-00 for ipsec@ietf.org; Wed, 14 Apr 2004 13:07:21 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BDnqU-0000Bm-00 for ipsec@ietf.org; Wed, 14 Apr 2004 13:06:42 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3EH6YH20648; Wed, 14 Apr 2004 20:06:34 +0300 (EET DST) X-Scanned: Wed, 14 Apr 2004 20:05:44 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3EH5iIx001035; Wed, 14 Apr 2004 20:05:44 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00iwVbqs; Wed, 14 Apr 2004 20:05:42 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3EH5fF20618; Wed, 14 Apr 2004 20:05:41 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 14 Apr 2004 12:04:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Ipsec] ipsec on WLAN Date: Wed, 14 Apr 2004 13:04:06 -0400 Message-ID: Thread-Topic: [Ipsec] ipsec on WLAN Thread-Index: AcQiJOyhpSTH5WSmTCWOdaPpcW9tawAGyRig To: , Cc: , X-OriginalArrivalTime: 14 Apr 2004 17:04:07.0295 (UTC) FILETIME=[7F5920F0:01C42242] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , If the goal is just to secure the radio link, then my understanding is that layer-2 WiFi (802.11i) security would be sufficient, layer-3 IPsec security may not be needed. Usage of IPsec tunnel between the wireless device and the security gateway is an interim measure to compensate for inadequacy of WEP and WPA security of the radio link. Atul > -----Original Message----- > From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org]On > Behalf Of ext Yoshihiro Ohba > Sent: Tuesday, April 13, 2004 8:20 PM > To: Giacomo Pisano > Cc: yo2lux; ipsec@ietf.org > Subject: Re: [Ipsec] ipsec on WLAN > > > An IPsec usage in WLAN is being discussed in the PANA WG. > There are several drafts related to the usage: > > draft-ietf-pana-ipsec-02.txt > draft-ohba-pana-framework-00.txt > > Regards, > > Yoshihiro Ohba > > > On Wed, Apr 14, 2004 at 10:45:13AM +0200, Giacomo Pisano wrote: > > I have one client (possibly Windows) one AP and a server > (possibly Windows).......do you think it's possible to make > the server act as a getway for the LAN?? I need to build an > IPSec Tunnel between the wi-fi client and the server. The > server then has to relay the data on the LAN and viceversa. > > > > What I'm trying to secure is just the radio link > > > > ----- Original Message ----- > > From: yo2lux > > To: Giacomo Pisano ; ipsec@ietf.org > > Sent: Wednesday, April 14, 2004 10:13 AM > > Subject: Re: [Ipsec] ipsec on WLAN > > > > > > you want to make an IPSec between OpenBSD and Windows ? > > ----- Original Message ----- > > From: Giacomo Pisano > > To: ipsec@ietf.org > > Sent: Wednesday, April 14, 2004 10:03 AM > > Subject: [Ipsec] ipsec on WLAN > > > > > > Hi, I'm a novice but i'm trying to make IPSec work on > WLAN in order to use level3 security instead of level2. Has > anyone of you tried to do the same?? I don't have any idea of > what to do! > > > > TNX > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 14 11:16:46 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3EIGiNV024500; Wed, 14 Apr 2004 11:16:45 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDokx-0006jE-MO; Wed, 14 Apr 2004 14:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDoZW-0002YS-Hq for ipsec@optimus.ietf.org; Wed, 14 Apr 2004 13:53:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11044 for ; Wed, 14 Apr 2004 13:53:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDoZU-0003wH-00 for ipsec@ietf.org; Wed, 14 Apr 2004 13:53:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDoYf-0003tb-00 for ipsec@ietf.org; Wed, 14 Apr 2004 13:52:22 -0400 Received: from static-151047.static.umsystem.edu ([207.160.151.47] helo=um-exproto7.um.umsystem.edu) by ietf-mx with esmtp (Exim 4.12) id 1BDoYH-0003pm-00 for ipsec@ietf.org; Wed, 14 Apr 2004 13:51:57 -0400 Received: from UM-EMAIL08.um.umsystem.edu ([207.160.151.27]) by um-exproto7.um.umsystem.edu with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 Apr 2004 12:51:27 -0500 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="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [Ipsec] ipsec on WLAN Date: Wed, 14 Apr 2004 12:51:26 -0500 Message-ID: Thread-Topic: [Ipsec] ipsec on WLAN Thread-Index: AcQiJOyhpSTH5WSmTCWOdaPpcW9tawAGyRigAAHKd7A= From: "Shelton, Raymond A." To: , , Cc: , X-OriginalArrivalTime: 14 Apr 2004 17:51:27.0208 (UTC) FILETIME=[1C117680:01C42249] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , I once stumbled across something that may be a tangentially interesting notion to consider: http://www.xtdnet.nl/paul/gallery/IETF57/dscf0004 (which I always have to reload in my Browser of Choice in order to actually view the image); a follow-up effort yielded interesting info @ the following "I probably wrap" url: http://www.research.att.com/areas/wireless/Mobile_Interdomain_Roaming/Mobility_Management/internet_roaming.html In this forum I am, too, am a novice, but another option (sentiment being, if I can do this, anyone can) IFF your o/s is XP would be to type "ipv6 install", I believe. Regards, Raymond A. Shelton ITS Network Services - University of Missouri Health Care DC017.00, QD263I, 2401 LeMone Industrial Boulevard Columbia, MO 65212 Voice 573-884-0661 Fax 573-884-8192 sheltonr ampersand Health. missouri.edu Fingerprint: 2795 9E15 9B67 85BD 19A5 F494 B3AB AF7A 93DF 064A _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 14 12:23:30 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3EJNTsl035183; Wed, 14 Apr 2004 12:23:30 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDppi-0005Ce-4c; Wed, 14 Apr 2004 15:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDphA-0006NQ-W3 for ipsec@optimus.ietf.org; Wed, 14 Apr 2004 15:05:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15378 for ; Wed, 14 Apr 2004 15:05:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDph7-0000mP-00 for ipsec@ietf.org; Wed, 14 Apr 2004 15:05:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDpg7-0000jA-00 for ipsec@ietf.org; Wed, 14 Apr 2004 15:04:08 -0400 Received: from thunk.org ([140.239.227.29] helo=thunker.thunk.org) by ietf-mx with esmtp (Exim 4.12) id 1BDpfG-0000hH-00 for ipsec@ietf.org; Wed, 14 Apr 2004 15:03:15 -0400 Received: from dsl092-109-027.nyc2.dsl.speakeasy.net ([66.92.109.27] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1BDpfH-0003cv-00; Wed, 14 Apr 2004 15:03:15 -0400 Received: from tytso by thunk.org with local (Exim 4.31) id 1BDpfF-00033w-K1; Wed, 14 Apr 2004 15:03:13 -0400 To: ipsec@ietf.org From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Wed, 14 Apr 2004 15:03:13 -0400 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 . X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-7.9 required=5.0 tests=AWL,HABEAS_SWE autolearn=no version=2.60 Subject: [Ipsec] Moving the IPSEC mailing list Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , As some of you have no doubt noticed, you recently received a mail message announcing that you have been subscribed to the mailing list "ipsec@ietf.org". This move of the list from ipsec@lists.tislabs.com was caused by increasing problems with the list that had caused various complaints from working group members. Unfortunately, the personnel at lists.tislabs.com were getting overwhelmed by spam attacks, so the service had declined to unacceptable levels. Some of these problems included tislabs.com ending up on the ORBS lists temporarily, and various messages (coming from people posting from non-standard addresses) getting mistaken as SPAM and getting lost. So we have arranged to moved the ipsec mailing list to the ipsec@ietf.org. Please use ipsec@ietf.org for all future ipsec mailing list traffic. ipsec@lists.tislabs.com will forward to ipsec@ietf.org for a short while, to aid in the transition. - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 14 13:50:52 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3EKopG5049332; Wed, 14 Apr 2004 13:50:52 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDqGN-0003Yl-Cm; Wed, 14 Apr 2004 15:41:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDqAY-0004C1-Ay for ipsec@optimus.ietf.org; Wed, 14 Apr 2004 15:35:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18448 for ; Wed, 14 Apr 2004 15:35:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDqAW-0002dt-00 for ipsec@ietf.org; Wed, 14 Apr 2004 15:35:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDq9c-0002c0-00 for ipsec@ietf.org; Wed, 14 Apr 2004 15:34:36 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BDq9I-0002aE-00 for ipsec@ietf.org; Wed, 14 Apr 2004 15:34:16 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3EJXi111517 for ; Wed, 14 Apr 2004 15:33:45 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3EJVp0g018763 for ; Wed, 14 Apr 2004 15:31:51 -0400 (EDT) Received: from odin.ietf.org(132.151.1.176) by nutshell.tislabs.com via csmap (V6.0) id srcAAABFaqJK; Wed, 14 Apr 04 15:31:39 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18373; Wed, 14 Apr 2004 15:33:58 -0400 (EDT) Message-Id: <200404141933.PAA18373@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Date: Wed, 14 Apr 2004 15:33:58 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Subject: [Ipsec] I-D ACTION:draft-ietf-ipsec-ui-suites-06.txt Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , --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 Suites for IPsec Author(s) : P. Hoffman Filename : draft-ietf-ipsec-ui-suites-06.txt Pages : 5 Date : 2004-4-14 The IPsec, IKE, and IKEv2 protocols rely on security algorithms to provide privacy and authentication between the initiator and responder. There are many such algorithms available, and two IPsec systems cannot interoperate unless they are using the same algorithms. This document specifies optional suites of algorithms and attributes that can be used to simplify the administration of IPsec when used in manual keying mode, with IKE version 1, or with IKEv2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ui-suites-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ui-suites-06.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-ui-suites-06.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-4-14153523.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ui-suites-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ui-suites-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-14153523.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 14 14:12:33 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3ELCVbH052384; Wed, 14 Apr 2004 14:12:32 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrMZ-00038T-6E; Wed, 14 Apr 2004 16:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDk3G-0001pV-BA for ipsec@optimus.ietf.org; Wed, 14 Apr 2004 09:03:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22415 for ; Wed, 14 Apr 2004 09:03:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDk3E-0000EH-00 for ipsec@ietf.org; Wed, 14 Apr 2004 09:03:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDk2N-00006D-00 for ipsec@ietf.org; Wed, 14 Apr 2004 09:02:44 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BDk1R-0007ku-00 for ipsec@ietf.org; Wed, 14 Apr 2004 09:01:45 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3ED1E116206 for ; Wed, 14 Apr 2004 09:01:14 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3ECxIEh008239 for ; Wed, 14 Apr 2004 08:59:18 -0400 (EDT) Received: from sunbeam.cs.biu.ac.il(132.70.1.24) by nutshell.tislabs.com via csmap (V6.0) id srcAAATzaaop; Wed, 14 Apr 04 08:56:44 -0400 Received: from amir-herzberg.cs.biu.ac.il (herzbea [132.70.4.58]) by sunbeam.cs.biu.ac.il with ESMTP id i3ECwwo6007233 for ; Wed, 14 Apr 2004 15:58:58 +0300 (IDT) Message-Id: <6.0.0.22.0.20040414153817.0256cb18@mailhost.cs.biu.ac.il> X-Sender: herzbea@mailhost.cs.biu.ac.il X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 14 Apr 2004 16:03:44 +0200 To: ipsec@lists.tislabs.com From: Amir Herzberg Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Ipsec] IKEv2 questions (for lecture) Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , I'm updating my IP-Sec lecture, in particular to cover IKEv2. While doing so, I read the current (March 22, 2004, ikev2-13.txt) draft. There are few issues where I wasn't sure if I understood correctly, or where there may be some typos/errors. All of some of these issues may have been discussed before, as I was not able to follow up with IKE recently, so I apologize for any such repeating, but would still appreciate a reply, possibly off-list. 1. In section 2.14 Generating Keying Material for the IKE_SA, you use SKEYSEED = prf(Ni | Nr, g^ir). But, the key to the prf is the _first_ parameter, in this case Ni | Nr, which is of course not secret. Is this intentional or a typo (i.e. the intention was SKEYSEED = prf(g^ir, Ni | Nr) ? 2. I didn't find where the (optional) N parameter of CREATE_CHILD_SA request is defined, and also, I wonder if there is a good reason for using here the letter N as the symbol for this value. (See section 1.3). 3. Also in section 1.3: there is a comment there `if the SA offers include different Diffie-Hellman groups,...` - doesn't the same comment apply for the initial exchange (section 1.2)? 4. Section 2.4: s/It is important when/It is important that when/ I may have few additional questions later on... still reading. Unless you prefer currently to discuss only identified open issues. BTW: I expect to complete this revision of the IP-Sec lecture in few days (so please DON'T download the current version...). Best regards, Amir Herzberg http://amirherzberg.com (information and lectures in cryptography & security) _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu Apr 15 00:16:23 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3F7GM8W090142; Thu, 15 Apr 2004 00:16:22 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE0wv-00027t-6z; Thu, 15 Apr 2004 03:06:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE0vj-0001O5-IA for ipsec@optimus.ietf.org; Thu, 15 Apr 2004 03:04:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06372 for ; Thu, 15 Apr 2004 03:04:56 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE0vf-0002Wr-00 for ipsec@ietf.org; Thu, 15 Apr 2004 03:04:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE0ul-0002TV-00 for ipsec@ietf.org; Thu, 15 Apr 2004 03:04:00 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BE0uG-0002QK-00 for ipsec@ietf.org; Thu, 15 Apr 2004 03:03:28 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3F6xfO02195; Thu, 15 Apr 2004 09:59:42 +0300 (EET DST) X-Scanned: Thu, 15 Apr 2004 09:59:39 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3F6xd44014969; Thu, 15 Apr 2004 09:59:39 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 002gRlNb; Thu, 15 Apr 2004 09:59:37 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3F6xVs28865; Thu, 15 Apr 2004 09:59:31 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 15 Apr 2004 09:59:21 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Ipsec] IKEv2 questions (for lecture) Date: Thu, 15 Apr 2004 09:59:13 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61223D1@esebe023.ntc.nokia.com> Thread-Topic: [Ipsec] IKEv2 questions (for lecture) Thread-Index: AcQibN8q5tjBR55KQQanY4Er4pwkAAARwJ2A To: , X-OriginalArrivalTime: 15 Apr 2004 06:59:21.0710 (UTC) FILETIME=[2DDE00E0:01C422B7] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3F7GM8W090142 Amir Herzberg wrote: > 1. In section 2.14 Generating Keying Material for the IKE_SA, you > use SKEYSEED = prf(Ni | Nr, g^ir). But, the key to the prf is > the _first_ parameter, in this case Ni | Nr, which is of course > not secret. Is this intentional or a typo (i.e. the intention > was SKEYSEED = prf(g^ir, Ni | Nr) ? This is intentional (and was done the same way in IKEv1). Appendix C.2 in Hugo Krawczyk's SIGMA paper explains why this was done (http://www.ee.technion.ac.il/~hugo/sigma.ps). > 2. I didn't find where the (optional) N parameter of CREATE_CHILD_SA > request is defined, and also, I wonder if there is a good reason for > using here the letter N as the symbol for this value. (See section > 1.3). I agree, this is not perhaps the best possible notation :-) "N" means a "Notify" payload (but this isn't explained until section 3.2), and the text in section 1.3 says that the notify type is REKEY_SA. > 3. Also in section 1.3: there is a comment there `if the SA offers > include different Diffie-Hellman groups,...` - doesn't the same > comment apply for the initial exchange (section 1.2)? Yes, the comment applies to initial exchange also (and it is mentioned later, in section 3.3.6). Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu Apr 15 05:36:57 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3FCatOV058768; Thu, 15 Apr 2004 05:36:55 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE5ug-00041T-7i; Thu, 15 Apr 2004 08:24:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE4oL-00023L-BK for ipsec@optimus.ietf.org; Thu, 15 Apr 2004 07:13:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17252 for ; Thu, 15 Apr 2004 07:13:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE4oK-0006Em-00 for ipsec@ietf.org; Thu, 15 Apr 2004 07:13:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE4nV-00065n-00 for ipsec@ietf.org; Thu, 15 Apr 2004 07:12:45 -0400 Received: from vsmtp3alice.tin.it ([212.216.176.143]) by ietf-mx with esmtp (Exim 4.12) id 1BE4mD-0005l6-00 for ipsec@ietf.org; Thu, 15 Apr 2004 07:11:25 -0400 Received: from mastro (82.49.97.74) by vsmtp3alice.tin.it (7.0.027) id 4061BAA600133D7F; Thu, 15 Apr 2004 13:10:45 +0200 Message-ID: <004b01c422da$5641e330$2201a8c0@mastro> From: "Giacomo Pisano" To: "Shelton, Raymond A." , , Cc: References: Subject: Re: [Ipsec] ipsec on WLAN Date: Thu, 15 Apr 2004 13:11:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , The sketch for my System is thi one: Wired LAN 802.3<-->Gateway Server<-->Cisco 1200AP<-->WirelessLAN (Win2000 or XP) (WinXp Pro or Linux) (Win2k or XP) I Understand that the Gateway Server could route the traffic from the WIFI LAN to the WiredLAN and viceversa. The problem is that I want to protect the traffic between Wireless Clients as well. If I used a tunnel between a WiFi client and the gateway I could probably reach the Wired LAN but what if I wanted to protect the traffic to another client? I'm Afraid that TCP would use the WiFi connection to communicate to the other mobile clients, ignoring the VPN tunnel to the gateway. My idea was to use a a FreeSWAN Server with two LAN interfaces installed: One facind the WiredLAN (e.g. 192.168.1.xxx) and the other connected directly to the AP and the WLAN(e.g. 192.168.2.xxx). A WIFI client (e.g. 192.168.2.2) connecting to a WIRED client (e.g. 192.168.1.25) would use the gateway through the VPN tunnel I estabilished. But I don't think it would do the same connecting to another WIFI client (the TX client would check the subnet mask and use the common ARP protocol on the WiFi branch of the LAN), thus leaving the traffic unprotected. The reason why I'm doing all this is for an University research trying to demonstrate that the normal level2 protection with WEP or WPA is much better in terms of total throughput and that's because everything is implemented in HW instead of running in SW. Moreover IPSec has a very though overhead on IP packets. Do you have any good idea about all this?? TNX ----- Original Message ----- From: "Shelton, Raymond A." To: ; ; Cc: ; Sent: Wednesday, April 14, 2004 7:51 PM Subject: RE: [Ipsec] ipsec on WLAN > I once stumbled across something that may be a tangentially interesting notion to consider: > http://www.xtdnet.nl/paul/gallery/IETF57/dscf0004 > (which I always have to reload in my Browser of Choice in order to actually view the image); a follow-up effort yielded interesting info @ the following "I probably wrap" url: > > http://www.research.att.com/areas/wireless/Mobile_Interdomain_Roaming/Mobili ty_Management/internet_roaming.html > > In this forum I am, too, am a novice, but another option (sentiment being, if I can do this, anyone can) IFF your o/s is XP would be to type "ipv6 install", I believe. > > Regards, > Raymond A. Shelton > ITS Network Services - University of Missouri Health Care > DC017.00, QD263I, 2401 LeMone Industrial Boulevard > Columbia, MO 65212 > Voice 573-884-0661 Fax 573-884-8192 > sheltonr ampersand Health. missouri.edu > Fingerprint: 2795 9E15 9B67 85BD 19A5 F494 B3AB AF7A 93DF 064A > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri Apr 16 11:03:52 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3GI3j96099333; Fri, 16 Apr 2004 11:03:48 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEXTY-0007Yi-80; Fri, 16 Apr 2004 13:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEXO8-0005Fq-8x for ipsec@optimus.ietf.org; Fri, 16 Apr 2004 13:44:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23909 for ; Fri, 16 Apr 2004 13:44:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEXO5-0007JE-Rf for ipsec@ietf.org; Fri, 16 Apr 2004 13:44:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEXNI-0007FZ-00 for ipsec@ietf.org; Fri, 16 Apr 2004 13:43:37 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BEXMH-00075D-00 for ipsec@ietf.org; Fri, 16 Apr 2004 13:42:33 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 16 Apr 2004 10:42:17 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i3GHg0hE006180; Fri, 16 Apr 2004 10:42:01 -0700 (PDT) Received: from cisco.com ([128.107.176.155]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASE04027; Fri, 16 Apr 2004 10:41:13 -0700 (PDT) Message-ID: <40801AE8.7030207@cisco.com> Date: Fri, 16 Apr 2004 10:42:00 -0700 From: Geoffrey Huang User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoav Nir CC: Pasi.Eronen@nokia.com, ipsec@ietf.org Subject: Re: [Ipsec] Re: IKEv2 AUTH payload References: <052E0C61B69C3741AFA5FE88ACC775A61223CC@esebe023.ntc.nokia.com> <6C08C547-8E10-11D8-A925-000A95834BAA@checkpoint.com> In-Reply-To: <6C08C547-8E10-11D8-A925-000A95834BAA@checkpoint.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , [changed cc to ipsec@ietf.org] Yoav Nir wrote: > It's a pity we haven't thought of it months ago. I think there is a > general consensus that it is too late now to do anything so radical as > add new exchange types. > > I don't like the idea of the gateway triggering a new authentication > with a DELETE notification, because a delete notification requires the > client to delete all the child SAs. If the EAP method requires the user > to enter a password (or the token card value) this means many seconds > without an IPSec SA. That could kill an ongoing FTP, Telnet or mail > download. > > A better solution would be a notification within the original IKE_AUTH > exchange, where the gateway tells the client how long the authentication > is valid. In essence, the gateway tells the client to re-authenticate > within 2 hours. A properly designed client will ask the user for a > password 5 minutes before the deadline, and begin a new initial exchange > from scratch. This way, the IKE and IPSec SAs can be replaced without a > loss of connectivity. If the client does not re-authenticate in time, > then the gateway can send a delete notification. > > We could add an AUTH_LIFETIME notification (16395?) with 4 bytes of data > signifying the time (in seconds) before the authentication expires. If > it's too late for it to enter the IKEv2 RFC, it can still be used as a > private notification. In IKEv1 few configure an IKE SA lifetime shorter > than 2 hours. Many extend it to 24 hours. The worst interoperability > problem that could happen, is that clients abruptly disconnect after 2 > hours. > > Does that sound reasonable? I don't think it does. This idea of an AUTH_LIFETIME goes against the notion of enforcing an IKE lifetime as local policy. I understand that the auth lifetime is slightly different from an IKE lifetime, but the difference is fairly nuanced. Nonetheless, if we do decide to have such a notification, I object to using a private value, as this would only add to interoperability issues. I'm not too familiar with the various user authentication methods, but do any of these methods support the notion of an authentication lifetime? Note that we'll have a similar problem with certificate lifetimes. The way IKEv2 is currently written, an entity can present a certificate that expires in say, 5 minutes. In the absence of another authentication exchange, the IKE peers could rekey indefinitely using the child SA exchange (even though the certificate is no longer valid). In this case, as with the authentication lifetime, the implementation will have to enforce the certificate lifetime by deleting the SA(s) when the certificate validity expires. -g > On Apr 14, 2004, at 2:48 PM, wrote: > >> Yoav Nir wrote: >> >>> >>> I still haven't received any responses to my question of last >>> week, about what to do if the autentication exchange is repeated >>> later on. It appears that in order to support this, I would have >>> to store the old initial exchanges so as to produce and verify the >>> AUTH payloads, but that seems wasteful. >> >> >> I don't think that storing the initial exchange messages, or >> even re-keying, is that big a problem if the reauthentication >> works just fine. >> >> However, as you pointed out, IKEv2 spec does not really talk >> about reauthentication at all... At least additional IKE_AUTH >> exchanges are not allowed (within the same SA) after the first >> authentication has completed. >> >> Presumably the original initiator could start a new IKE SA from >> scratch, establish new child SAs (for the same "internal" address >> in remote access VPN gateway situations, without REKEY flag), and >> then delete the old IKE SA and the old child SAs, right? >> >> However, at least when EAP is used, the original responder >> ("VPN gateway") can't trigger this reauthentication... because >> if it created a new IKE SA, it would be the initiator in that. >> >> Any ideas how to solve this? >> >> Perhaps the gateway (original responder) could delete the old >> IKE SA (with Delete payload), and that would signal the client >> (initiator) to start from scratch? Or perhaps a notification message >> should be used? Or perhaps additional IKE_AUTH exchange could >> be allowed within the same IKE SA? >> >> (IMHO the notification sounds like the simplest approach, >> if it actually works; there might be some aspects I haven't >> considered. The overhead of setting up a new IKE SA is probably >> not very serious if reauthentication happens every couple >> of hours or so.) >> >> Best regards, >> Pasi > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri Apr 16 15:14:41 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3GMEelZ034100; Fri, 16 Apr 2004 15:14:40 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEbOR-000859-Ce; Fri, 16 Apr 2004 18:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEbI1-0005qK-T5 for ipsec@optimus.ietf.org; Fri, 16 Apr 2004 17:54:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12598 for ; Fri, 16 Apr 2004 17:54:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEbHz-0004Vs-8l for ipsec@ietf.org; Fri, 16 Apr 2004 17:54:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEbH5-0004UO-00 for ipsec@ietf.org; Fri, 16 Apr 2004 17:53:27 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1BEbGK-0004QW-00 for ipsec@ietf.org; Fri, 16 Apr 2004 17:52:40 -0400 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3GLpvgx016558; Fri, 16 Apr 2004 14:51:58 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i3GLpvlE020474; Fri, 16 Apr 2004 17:51:57 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i3GLpvQU012761; Fri, 16 Apr 2004 17:51:57 -0400 (EDT) Message-Id: <200404162151.i3GLpvQU012761@thunk.east.sun.com> From: Bill Sommerfeld To: Geoffrey Huang cc: Yoav Nir , Pasi.Eronen@nokia.com, ipsec@ietf.org Subject: Re: [Ipsec] Re: IKEv2 AUTH payload In-Reply-To: Your message of "Fri, 16 Apr 2004 10:42:00 PDT." <40801AE8.7030207@cisco.com> Reply-to: sommerfeld@east.sun.com Date: Fri, 16 Apr 2004 17:51:57 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , > I'm not too familiar with the various user authentication methods, > but do any of these methods support the notion of an authentication > lifetime? Yes. (Kerberos is a notable example). - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri Apr 16 15:29:56 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3GMTtul036416; Fri, 16 Apr 2004 15:29:55 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEbhr-0002wx-43; Fri, 16 Apr 2004 18:21:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEbeR-0000GQ-M1 for ipsec@optimus.ietf.org; Fri, 16 Apr 2004 18:17:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15409 for ; Fri, 16 Apr 2004 18:17:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEbeO-00069W-Nj for ipsec@ietf.org; Fri, 16 Apr 2004 18:17:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEbdR-00065g-00 for ipsec@ietf.org; Fri, 16 Apr 2004 18:16:34 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1BEbcY-00060V-00 for ipsec@ietf.org; Fri, 16 Apr 2004 18:15:38 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i3GMFP9Z024955; Fri, 16 Apr 2004 16:15:25 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i3GMFP4F028772; Fri, 16 Apr 2004 16:15:25 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i3GMEmhf028587; Fri, 16 Apr 2004 17:14:48 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i3GMEgKg028586; Fri, 16 Apr 2004 17:14:42 -0500 (CDT) Date: Fri, 16 Apr 2004 17:14:42 -0500 From: Nicolas Williams To: Bill Sommerfeld Cc: Geoffrey Huang , Yoav Nir , Pasi.Eronen@nokia.com, ipsec@ietf.org Subject: Re: [Ipsec] Re: IKEv2 AUTH payload Message-ID: <20040416221442.GF22519@binky.central.sun.com> Mail-Followup-To: Bill Sommerfeld , Geoffrey Huang , Yoav Nir , Pasi.Eronen@nokia.com, ipsec@ietf.org References: <40801AE8.7030207@cisco.com> <200404162151.i3GLpvQU012761@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404162151.i3GLpvQU012761@thunk.east.sun.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , On Fri, Apr 16, 2004 at 05:51:57PM -0400, Bill Sommerfeld wrote: > > I'm not too familiar with the various user authentication methods, > > but do any of these methods support the notion of an authentication > > lifetime? > > Yes. (Kerberos is a notable example). And plain old PKI too, since certificates have expiration dates. Suppose you're using something like kx509 to get short-lived certs issued after authenticating with Kerberos V... presumably you'd want sessions authenticated with such certs to expire when the certs do. Nico -- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri Apr 16 15:57:20 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3GMvI7S039981; Fri, 16 Apr 2004 15:57:19 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEc41-0002mI-7P; Fri, 16 Apr 2004 18:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEbxm-0008B1-5K for ipsec@optimus.ietf.org; Fri, 16 Apr 2004 18:37:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16816 for ; Fri, 16 Apr 2004 18:37:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEbxj-0007Xx-3U for ipsec@ietf.org; Fri, 16 Apr 2004 18:37:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEbwd-0007U5-00 for ipsec@ietf.org; Fri, 16 Apr 2004 18:36:24 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1BEbvi-0007Qx-00 for ipsec@ietf.org; Fri, 16 Apr 2004 18:35:26 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3GMYi6N004598; Fri, 16 Apr 2004 15:34:44 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i3GMYh4F005724; Fri, 16 Apr 2004 16:34:44 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i3GMYEhf028616; Fri, 16 Apr 2004 17:34:14 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i3GMYENb028615; Fri, 16 Apr 2004 17:34:14 -0500 (CDT) Date: Fri, 16 Apr 2004 17:34:14 -0500 From: Nicolas Williams To: Bill Sommerfeld , Geoffrey Huang , Yoav Nir , Pasi.Eronen@nokia.com, ipsec@ietf.org Subject: Re: [Ipsec] Re: IKEv2 AUTH payload Message-ID: <20040416223414.GH22519@binky.central.sun.com> Mail-Followup-To: Bill Sommerfeld , Geoffrey Huang , Yoav Nir , Pasi.Eronen@nokia.com, ipsec@ietf.org References: <40801AE8.7030207@cisco.com> <200404162151.i3GLpvQU012761@thunk.east.sun.com> <20040416221442.GF22519@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040416221442.GF22519@binky.central.sun.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , On Fri, Apr 16, 2004 at 05:14:42PM -0500, Nicolas Williams wrote: > On Fri, Apr 16, 2004 at 05:51:57PM -0400, Bill Sommerfeld wrote: > > > I'm not too familiar with the various user authentication methods, > > > but do any of these methods support the notion of an authentication > > > lifetime? > > > > Yes. (Kerberos is a notable example). > > And plain old PKI too, since certificates have expiration dates. > > Suppose you're using something like kx509 to get short-lived certs > issued after authenticating with Kerberos V... presumably you'd want > sessions authenticated with such certs to expire when the certs do. And the GSS-API (which allows for non-infinity security context lifetimes). The right way to make use of Kerberos V, in general, is through the GSS-API. I do hope that if and when the IETF goes on to consider how to authenticate IPsec IDs with Kerberos V that the GSS-API will be used instead of raw Kerberos V. Nico -- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri Apr 16 22:00:58 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3H50vFV093291; Fri, 16 Apr 2004 22:00:58 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEhnE-0000DH-0Q; Sat, 17 Apr 2004 00:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEhjv-0007Zs-9J for ipsec@optimus.ietf.org; Sat, 17 Apr 2004 00:47:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05024 for ; Sat, 17 Apr 2004 00:47:34 -0400 (EDT) From: smb@research.att.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEhjr-00010n-Qu for ipsec@ietf.org; Sat, 17 Apr 2004 00:47:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEhiy-0000xs-00 for ipsec@ietf.org; Sat, 17 Apr 2004 00:46:40 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BEhiY-0000up-00 for ipsec@ietf.org; Sat, 17 Apr 2004 00:46:14 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3H4je126648 for ; Sat, 17 Apr 2004 00:45:40 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3H4hper011418 for ; Sat, 17 Apr 2004 00:43:51 -0400 (EDT) Message-Id: <200404170443.i3H4hper011418@nutshell.tislabs.com> Received: from 202.53.88.106.nettlinx.com(202.53.88.106) by nutshell.tislabs.com via csmap (V6.0) id srcAAArNaGnw; Sat, 17 Apr 04 00:43:30 -0400 To: ipsec@lists.tislabs.com Date: Sat, 17 Apr 2004 10:12:28 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0003_00007653.00004C16" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.1 required=5.0 tests=HTML_30_40,HTML_FONTCOLOR_RED, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2,MISSING_MIMEOLE, MSGID_FROM_MTA_HEADER,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [Ipsec] Re: Your picture Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0003_00007653.00004C16 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Here is the file. ------=_NextPart_000_0003_00007653.00004C16 Content-Type: text/html; name="your_picture.pif.htm" Content-Disposition: attachment; filename="your_picture.pif.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: your_picture.pif
Virus name: W32/Netsky.d@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_0003_00007653.00004C16-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Sat Apr 17 07:32:16 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3HEWDpG053285; Sat, 17 Apr 2004 07:32:13 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEqij-0000Aj-BN; Sat, 17 Apr 2004 10:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEqgn-00084f-UF for ipsec@optimus.ietf.org; Sat, 17 Apr 2004 10:21:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12103 for ; Sat, 17 Apr 2004 10:20:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEqgl-0004ik-Ob for ipsec@ietf.org; Sat, 17 Apr 2004 10:20:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEqfy-0004c4-00 for ipsec@ietf.org; Sat, 17 Apr 2004 10:20:10 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx with esmtp (Exim 4.12) id 1BEqfW-0004Rx-00 for ipsec@ietf.org; Sat, 17 Apr 2004 10:19:42 -0400 Received: from sslvpn.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with SMTP id i3HEIw013768; Sat, 17 Apr 2004 17:18:58 +0300 (IDT) Received: from 217.132.141.171 (WebMail Portal authenticated user ynir) by sslvpn.checkpoint.com with HTTP; Sat, 17 Apr 2004 15:17:02 -0000 (UTC) Message-ID: <61444.217.132.141.171.1082215022.squirrel@sslvpn.checkpoint.com> In-Reply-To: <40801AE8.7030207@cisco.com> References: <052E0C61B69C3741AFA5FE88ACC775A61223CC@esebe023.ntc.nokia.com> <6C08C547-8E10-11D8-A925-000A95834BAA@checkpoint.com> <40801AE8.7030207@cisco.com> Date: Sat, 17 Apr 2004 15:17:02 -0000 (UTC) Subject: Re: [Ipsec] Re: IKEv2 AUTH payload From: "Yoav Nir" To: "Geoffrey Huang" Cc: pasi.eronen@nokia.com, ipsec@ietf.org Reply-To: ynir@checkpoint.com User-Agent: WebMail Portal/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Some methods may, and the EAP-success message has optional text which could be something like "User authenticated for 7200 seconds". But neither is generic enough. The difference between re-keying and re-authentication is not nuanced, as re-keying can be initiated by either side, while re-authentication can only be initiated by the user. OTOH it is the server (or gateway) that will have a policy about re-authenticating clients. Unless the gateway passes the information to the client somehow, then there's no way that the client can authenticate in time. Certificates don't have the same problem. Certificates contain their expiration time. If a gateway is presented with a certificate that expires in 5 minutes, it can set a timer to close the IKE SA in 5 minutes. Also, the client also knows about the expiration time, so it can know when to re-authenticate and present a new certificate. This is not available when re-authentication is just a matter of policy. Re-authentication is a requirement for many users. If vendors can't provide it as part of IKE, they will have to do so through other channels, either a private notification or some kind of internal connection. These will be neither standard nor interoperable, and it would mean that when using, say, a Microsoft client with a Cisco access concentrator, the connection would break after some time. In bakeoffs everything would be fine, because everyone would set the re-authentication time to the maximum possible and there won't be any disconnects. In the field, these things will happen. Geoffrey Huang said: > Yoav Nir wrote: > >> It's a pity we haven't thought of it months ago. I think there is a >> general consensus that it is too late now to do anything so radical as >> add new exchange types. >> >> I don't like the idea of the gateway triggering a new authentication >> with a DELETE notification, because a delete notification requires the >> client to delete all the child SAs. If the EAP method requires the user >> to enter a password (or the token card value) this means many seconds >> without an IPSec SA. That could kill an ongoing FTP, Telnet or mail >> download. >> >> A better solution would be a notification within the original IKE_AUTH >> exchange, where the gateway tells the client how long the authentication >> is valid. In essence, the gateway tells the client to re-authenticate >> within 2 hours. A properly designed client will ask the user for a >> password 5 minutes before the deadline, and begin a new initial exchange >> from scratch. This way, the IKE and IPSec SAs can be replaced without a >> loss of connectivity. If the client does not re-authenticate in time, >> then the gateway can send a delete notification. >> >> We could add an AUTH_LIFETIME notification (16395?) with 4 bytes of data >> signifying the time (in seconds) before the authentication expires. If >> it's too late for it to enter the IKEv2 RFC, it can still be used as a >> private notification. In IKEv1 few configure an IKE SA lifetime shorter >> than 2 hours. Many extend it to 24 hours. The worst interoperability >> problem that could happen, is that clients abruptly disconnect after 2 >> hours. >> >> Does that sound reasonable? > > I don't think it does. This idea of an AUTH_LIFETIME goes against the > notion of > enforcing an IKE lifetime as local policy. I understand that the auth > lifetime > is slightly different from an IKE lifetime, but the difference is fairly > nuanced. > > Nonetheless, if we do decide to have such a notification, I object to > using a > private value, as this would only add to interoperability issues. > > I'm not too familiar with the various user authentication methods, but do > any of > these methods support the notion of an authentication lifetime? > > Note that we'll have a similar problem with certificate lifetimes. The > way > IKEv2 is currently written, an entity can present a certificate that > expires in > say, 5 minutes. In the absence of another authentication exchange, the > IKE > peers could rekey indefinitely using the child SA exchange (even though > the > certificate is no longer valid). In this case, as with the authentication > lifetime, the implementation will have to enforce the certificate lifetime > by > deleting the SA(s) when the certificate validity expires. > > -g _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon Apr 19 00:04:46 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3J74jZK003564; Mon, 19 Apr 2004 00:04:45 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFSiE-0008Gy-6o; Mon, 19 Apr 2004 02:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFSd5-00079w-NU for ipsec@optimus.ietf.org; Mon, 19 Apr 2004 02:51:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20888 for ; Mon, 19 Apr 2004 02:51:40 -0400 (EDT) From: paul.hoffman@vpnc.org Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFSd1-0003Js-Rl for ipsec@ietf.org; Mon, 19 Apr 2004 02:51:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFSc6-00036I-00 for ipsec@ietf.org; Mon, 19 Apr 2004 02:50:43 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BFSax-0002i4-00 for ipsec@ietf.org; Mon, 19 Apr 2004 02:49:31 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3J6mr114650 for ; Mon, 19 Apr 2004 02:48:53 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3J6kkG8022176 for ; Mon, 19 Apr 2004 02:46:46 -0400 (EDT) Message-Id: <200404190646.i3J6kkG8022176@nutshell.tislabs.com> Received: from unknown(193.140.74.2) by nutshell.tislabs.com via csmap (V6.0) id srcAAA68a4_Q; Mon, 19 Apr 04 02:45:33 -0400 To: ipsec@lists.tislabs.com Date: Mon, 19 Apr 2004 09:44:38 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0005_000000B7.0000236C" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.0 required=5.0 tests=DATE_IN_FUTURE_06_12, HTML_30_40,HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING, LINES_OF_YELLING_2,MISSING_MIMEOLE,MSGID_FROM_MTA_HEADER,NO_REAL_NAME, PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red * 0.1 LINES_OF_YELLING_2 BODY: 2 WHOLE LINES OF YELLING DETECTED * 1.9 DATE_IN_FUTURE_06_12 Date: is 6 to 12 hours after Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer * 0.8 MSGID_FROM_MTA_HEADER Message-Id was added by a relay Subject: [Ipsec] Re: Your text Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0005_000000B7.0000236C Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Your document is attached. ------=_NextPart_000_0005_000000B7.0000236C Content-Type: text/html; name="your_text.pif.htm" Content-Disposition: attachment; filename="your_text.pif.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: your_text.pif
Virus name: W32/Netsky.d@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_0005_000000B7.0000236C-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon Apr 19 01:34:18 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3J8YFwY036466; Mon, 19 Apr 2004 01:34:17 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFU53-0000dy-PB; Mon, 19 Apr 2004 04:24:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFTEq-00077W-Lo for ipsec@optimus.ietf.org; Mon, 19 Apr 2004 03:30:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22471 for ; Mon, 19 Apr 2004 03:30:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFTEo-0004Ej-6e for ipsec@ietf.org; Mon, 19 Apr 2004 03:30:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFTDt-00042b-00 for ipsec@ietf.org; Mon, 19 Apr 2004 03:29:46 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx with esmtp (Exim 4.12) id 1BFTDa-0003qF-00 for ipsec@ietf.org; Mon, 19 Apr 2004 03:29:26 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i3J7Sju28923; Mon, 19 Apr 2004 10:28:45 +0300 (IDT) In-Reply-To: <16515.31485.122746.321148@fireball.acr.fi> References: <052E0C61B69C3741AFA5FE88ACC775A61223CC@esebe023.ntc.nokia.com> <6C08C547-8E10-11D8-A925-000A95834BAA@checkpoint.com> <40801AE8.7030207@cisco.com> <61444.217.132.141.171.1082215022.squirrel@sslvpn.checkpoint.com> <16515.31485.122746.321148@fireball.acr.fi> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3139C8C4-91D3-11D8-B5D7-000A95834BAA@checkpoint.com> Content-Transfer-Encoding: 7bit Cc: "Geoffrey Huang" , pasi.eronen@nokia.com, ipsec@ietf.org From: Yoav Nir Subject: Re: [Ipsec] Re: IKEv2 AUTH payload Date: Mon, 19 Apr 2004 10:28:45 +0300 To: Tero Kivinen X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , That's about right. Personally, I'd rather see the notification follow the IKE SA setup with a number of seconds (we can call it REAUTHENTICATE_IN or AUTH_LIFETIME), so that the client implementation can decide when to initiate the new Initial exchange. If we send a REAUTHENTICATE_NOW, the gateway has to estimate how long it would take the user to enter the credentials. IMO this estimate is better left to client implementors. So: Client Server ------ ------ << Client will create initial IKE SA and IPsec SA >> 1. HDR, SAi1, KEi, Ni -> 2. <- HDR, SAr1, KEr, Nr 3. HDR, SK { IDi, AUTH, SAi2, TSi, TSr} -> 4. <- HDR, SK { IDr, AUTH, SAr2, TSi, TSr} 5. <- N(AUTH_LIFETIME(n)) 6. ACK -> << Traffic goes on >> << After n - m minutes, the client notices that it needs to do reauthentication now >> 7. HDR, SAi1, KEi, Ni -> 8. <- HDR, SAr1, KEr, Nr 9. HDR, SK { IDi, AUTH, N(REKEY_SA), SAi2, TSi, TSr} -> 10. <- HDR, SK { IDr, AUTH, SAr2, TSi, TSr} << Note, that client will send REKEY_SA notification along with the IPsec SA creation. >> << After the IKE and IPsec SAs are rekeyed, client will delete old IKE SA, and the old IPsec SA (this is sent inside the old IKE SA) >> 11. D -> 12. <- ACK And if the client does not know how to process the AUTH_LIFETIME notification, we get afterm n seconds) 7b. <- D 8b. ACK -> I agree that this can be added as a separate draft. On Apr 19, 2004, at 10:08 AM, Tero Kivinen wrote: > Yoav Nir writes: >> Some methods may, and the EAP-success message has optional text which >> could be something like "User authenticated for 7200 seconds". But >> neither is generic enough. The difference between re-keying and >> re-authentication is not nuanced, as re-keying can be initiated by >> either >> side, while re-authentication can only be initiated by the user. >> OTOH it >> is the server (or gateway) that will have a policy about >> re-authenticating >> clients. Unless the gateway passes the information to the client >> somehow, >> then there's no way that the client can authenticate in time. > > So we need notification REAUTHENTICATE_NOW from the server (gateway) > to the client, which tells that re-authentication is required now. If > the client does not support that notification, and will not > re-authenticate in xxx seconds (configurable, default should be couple > of minutes) then the server will send delete notification to the IKE > SA, forcing the client to re-authenticate. If client does support > REAUTHENTICATE_NOW notifications it will start creating new IKE_SA > re-authenticating at the same time, and after that is finished, it > re-keys all IPsec SAs using that new IKE_SA with REKEY_SA > notification, moving all traffic from old SA to new. After the > re-authentication and rekey is finished, the client will delete the > old IKE_SA (and old IPsec SAs). > > I.e. the protocol will be following (n = re-authenticate interval in > minutes, m = time to give for the client to finish the > re-authentication): > > > Client Server > ------ ------ > > << Client will create initial IKE SA and IPsec SA >> > > 1. HDR, SAi1, KEi, Ni -> > 2. <- HDR, SAr1, KEr, Nr > 3. HDR, SK { IDi, AUTH, > SAi2, TSi, TSr} -> > 4. <- HDR, SK { IDr, AUTH, > SAr2, TSi, TSr} > > > << Traffic goes on >> > > > << After n - m minutes, the server noticies that it will > require the client to do reauthentication now >> > > 5. <- N(REAUTHENTICATE_NOW) > 6. ACK -> > > << Client starts to create new IKE SA >> > > 7. HDR, SAi1, KEi, Ni -> > 8. <- HDR, SAr1, KEr, Nr > 9. HDR, SK { IDi, AUTH, > N(REKEY_SA), SAi2, > TSi, TSr} -> > 10. <- HDR, SK { IDr, AUTH, > SAr2, TSi, TSr} > > << Note, that client will send REKEY_SA notification along > with the IPsec SA creation. >> > > << After the IKE and IPsec SAs are rekeyed, client will > delete old IKE SA, and the old IPsec SA (this is sent > inside the old IKE SA) >> > > 11. D -> > 12. <- ACK > > > Now traffic has moved to the new IPsec SA, and the IKE SA has been > re-authenticated. > > If the client does not support this new REAUTHENTICATE_NOW > notification the processing goes like this (after step 6): > > > << Client simply ignored the REAUTHENTICATE_NOW notification > as it didn't undestand it, or was unwilling (or unable, > because user didn't write in the password in time) to > re-authenticate now >> > > << After m minutes the server decides, that the client is not > going to re-authenticate, so it simply deletes the IKE_SA >> > > 7b. <- D > 8b. ACK -> > > << Now client, will not have IKE_SA, nor IPsec SA, so it needs > to create them again when it needs them next (or when it is > again able to do it, i.e. when the user comes back from > lunch and is able to type in the password again >> > > 9b. HDR, SAi1, KEi, Ni -> > 10b. <- HDR, SAr1, KEr, Nr > 11b. HDR, SK { IDi, AUTH, > SAi2, TSi, TSr} -> > 12b. <- HDR, SK { IDr, AUTH, > SAr2, TSi, TSr} > > << Traffic can continue >> > > That kind of change can be made after the base IKEv2 draft is ready, > as a separate draft and protocol, as it will be interoperable with > base IKEv2 version too. > -- > kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon Apr 19 08:47:45 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3JFliea092774; Mon, 19 Apr 2004 08:47:45 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFarN-0004hh-HS; Mon, 19 Apr 2004 11:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFafu-0002ah-56 for ipsec@optimus.ietf.org; Mon, 19 Apr 2004 11:27:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16847 for ; Mon, 19 Apr 2004 11:27:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFaft-0002LA-4R for ipsec@ietf.org; Mon, 19 Apr 2004 11:27:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFaf3-00027k-00 for ipsec@ietf.org; Mon, 19 Apr 2004 11:26:18 -0400 Received: from wolfe.bbn.com ([128.89.80.22]) by ietf-mx with esmtp (Exim 4.12) id 1BFaeK-0001qp-00 for ipsec@ietf.org; Mon, 19 Apr 2004 11:25:32 -0400 Received: by wolfe.bbn.com (Postfix, from userid 13538) id 597742051E; Mon, 19 Apr 2004 11:25:02 -0400 (EDT) From: Charles Lynn To: ipsec@ietf.org Message-Id: <20040419152502.597742051E@wolfe.bbn.com> Date: Mon, 19 Apr 2004 11:25:02 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Ipsec] Interpretation of ICMP Type and Code Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , IKEv2 specifies how ICMP Type and Code are encoded into a single 16-bit "port" field. For the ICMP protocol, the two one octet fields Type and Code are treated as a single 16 bit integer (with Type in the most significant eight bits and Code in the least significant eight bits) port number for the purposes of filtering based on this field. How are Type and Code to be treated by an implementation? I have not found a clear specification of the semantics. Given a start Type of tstart and an end Type of tend, a start Code of cstart and an end Code of cend, and an ICMP packet with Type t and Code c: Is the test that an implementation MUST make: a) (tstart <= t <= tend) AND (cstart <= c <= cend), or b) tstart*256+cstart <= t*256+c <= tend*256+cend I think that either 2401bis or IKEv2 should state one of the above to make sure that all implementations interpret things the same way. Comments? _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon Apr 19 09:41:22 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3JGfIvg097643; Mon, 19 Apr 2004 09:41:21 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFbfq-00019m-VG; Mon, 19 Apr 2004 12:31:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFbd4-0000K1-VT for ipsec@optimus.ietf.org; Mon, 19 Apr 2004 12:28:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21722 for ; Mon, 19 Apr 2004 12:28:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFbd3-0001vO-Ch for ipsec@ietf.org; Mon, 19 Apr 2004 12:28:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFbcH-0001h2-00 for ipsec@ietf.org; Mon, 19 Apr 2004 12:27:30 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BFbbY-0001RF-00 for ipsec@ietf.org; Mon, 19 Apr 2004 12:26:44 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3JGQ5114747 for ; Mon, 19 Apr 2004 12:26:06 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3JGNw3V005416 for ; Mon, 19 Apr 2004 12:24:01 -0400 (EDT) Received: from email.quarrytech.com(4.17.144.4) by nutshell.tislabs.com via csmap (V6.0) id srcAAAPAaG2j; Mon, 19 Apr 04 12:21:04 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.45]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XT41JG4K; Mon, 19 Apr 2004 12:23:26 -0400 Message-Id: <5.2.0.9.0.20040419120357.0205b710@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 19 Apr 2004 12:23:07 -0400 To: Karen Seo , ipsec@lists.tislabs.com From: Mark Duffy In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Ipsec] Re: 2401bis -- Issue 91 -- handling ICMP error messages Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Hi Karen, sorry for the delayed response. I have no argument with the proposal to follow the second approach. But, I don't see why in this case the receiver would need to do any "special" processing i.e. examining the payload of the icmp packet. Can you please explain the reason for that? If I understand the proposal correctly, the icmp packets will be sent on an SA that is explicitly negotiated for icmp (and maybe other stuff). Why shouldn't the receiver just accept the icmp packets on their own merits? Thanks, Mark P.S. I marked the paragraph below that I am asking about. At 07:54 PM 4/13/2004 -0400, Karen Seo wrote: >Folks, > >Following up on a discussion at the end of February/early March re: how to >handle ICMP traffic... We were talking about how to carry ICMP traffic via >an SA between two IPsec implementations. This did NOT involve ICMP >traffic that might be bypassed or consumed on the ciphertext side of the >IPsec boundary. Also, there are two categories of ICMP traffic -- error >messages (e.g., type = destination unreachable) and non-error messages >(e.g., type = echo). This discussion covered ONLY error >messages. Non-error ICMP messages should be explicitly accounted for in >the SPD. > >Two approaches were discussed: > 1. The sender of ICMP error message uses the (return) SA for the > packet that resulted in the ICMP error message. In this > discussion, the SA was assumed to not be configured to > carry ICMP error messages. > 2. The sender of ICMP error message uses an SA that is configured > to handle ICMP error messages of the relevant type and code. > Note that while this case was viewed in the discussion > as being a different/separate SA from case 1 above, this SA > could be the same as case 1, if that SA were configured to > carry ICMP error taffic (in addition to user traffic). Note > also that the ICMP Type and Code for this SA could be set to > ANY, if there is no need to restrict the type of ICMP traffic > that it is allowed to carry. > >Here's what needs to happen at the sender and receiver, to make each case >work: > For case 1: > a. The sender notices that the packet is an ICMP error > message and diverts it to slow path processing. It > examines the enclosed packet (or portion thereof), > swaps the source and destination addresses and > ports, and performs an SPD lookup to find the SA > to use. Then the ICMP packet is sent via the > the selected SA. > > b. The receiver notices that a packet has failed the > selector check (e.g., the source address or the > protocol does not match). The packet is diverted > to slow path processing where it is observed to be > an ICMP error message and the enclosed packet > is examined. The source and destination addresses > and ports are swapped and matched against the > selectors for the SA via which the ICMP packet was > received. If they match, the ICMP message is passed > on for further processing, e.g., PMTU check. > > This case assumes that no further access control checks > are desired for the ICMP packet. > > For case 2: > a. The sender extracts ICMP type and code and does an > SPD lookup to find an appropriate SA. (The Sender > only does fast path processing.) > b. The receiver processes the ICMP packet on the SA > via which it was received, verifying that the ICMP > type and code of the message match the selectors > for the SA. [md] Why check the icmp payload as stated below? And what does it mean for the enclosed packet to be "consistent with its source"? > If they do, then the receiver passes > the ICMP message to slow path processing. The > selectors of the enclosed packet are extracted > and matched against the SPD-S cache, to ensure > that the enclosed packet is consistent with its > source. If they do, the ICMP message is passed > along for further processing, e.g., PMTU check. > (The receiver does both fast path and slow path > processing.) > > Note that an ICMP packet may arrive on an SA unrelated > to the SA used for the triggering packet. The sender > will use the first SPD or SPD-S cache entry that it > comes to that is configured to carry ICMP traffic of > the given type and code. Even if the SA for the > triggering packet is configured to carry ICMP traffic, > there may be an earlier entry in the SPD that matches > the ICMP message's type and code. So one has > to search the outbound SPD-S cache to verify whether > or not there's an extant SA for the enclosed > (triggering) packet. > >Proposed approach > To simplify the processing done by the Sender (of the ICMP > message) to find the SA to use for sending the ICMP message > and to support access control checks on the ICMP messages > (using ICMP Message Type and Code) by the Receiver, > we propose to use the second approach. > > Note: In the second approach, there is no requirement that > the SA used for the ICMP message be dedicated only to ICMP > messages. To minimize the number of SAs between two IPsec > systems, an administrator may wish to configure the SPD such > that the ICMP messages may be combined with other traffic, > i.e., by specifying SPD entries that carry both normal > traffic and ICMP traffic. > >Comments? Thank you, >Karen _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon Apr 19 09:50:26 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3JGoOvV098652; Mon, 19 Apr 2004 09:50:25 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFbpQ-0003h8-4s; Mon, 19 Apr 2004 12:41:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFbgS-0001Bs-Aq for ipsec@optimus.ietf.org; Mon, 19 Apr 2004 12:31:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21875 for ; Mon, 19 Apr 2004 12:31:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFbgQ-0002kX-Lv for ipsec@ietf.org; Mon, 19 Apr 2004 12:31:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFbf7-0002QC-00 for ipsec@ietf.org; Mon, 19 Apr 2004 12:30:26 -0400 Received: from mail-eur.microsoft.com ([213.199.128.145]) by ietf-mx with esmtp (Exim 4.12) id 1BFbeZ-00029Y-00 for ipsec@ietf.org; Mon, 19 Apr 2004 12:29:51 -0400 Received: from eur-imc-02.europe.corp.microsoft.com ([65.53.196.43]) by mail-eur.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Apr 2004 17:29:12 +0100 Received: from 65.53.196.43 by eur-imc-02.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 19 Apr 2004 17:29:12 +0100 Received: from EUR-MSG-02.europe.corp.microsoft.com ([65.53.192.43]) by eur-imc-02.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Apr 2004 17:29:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Ipsec] Interpretation of ICMP Type and Code Date: Mon, 19 Apr 2004 17:29:19 +0100 Message-ID: <579E83556A36E44EB2945CCE990B31740140B5FB@EUR-MSG-02.europe.corp.microsoft.com> Thread-Topic: [Ipsec] Interpretation of ICMP Type and Code Thread-Index: AcQmJT0IRqjyjAi1RpyJz2Qyb661zgAAt4aA From: "Michael Roe" To: "Charles Lynn" Cc: X-OriginalArrivalTime: 19 Apr 2004 16:29:12.0066 (UTC) FILETIME=[728F4E20:01C4262B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3JGoOvV098652 I had interpreted the text as meaning (b), tstart*256+cstart <= t*256+c <= tend*256+cend But as you say, it's not entirely clear. I think it doesn't matter very much - either option would be OK. Ideally, we ought to specify which it is, or we'll have interoperability problems. On the other hand, we really need to get IKEv2 finished soon, so I'm not too keen on the idea of IKEv2 being delayed by this issue! The architecture document might be the right place for this. Not just because I'd like to avoid delaying IKEv2, but also because this issue is really about which selectors match which packets - and that seems to belong in 2401bis. Mike > From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org] On > Behalf Of Charles Lynn > Sent: 19 April 2004 16:25 > To: ipsec@ietf.org > For the > ICMP protocol, the two one octet fields Type and Code are > treated as a single 16 bit integer (with Type in the most > significant eight bits and Code in the least significant > eight bits) port number for the purposes of filtering based > on this field. > > How are Type and Code to be treated by an implementation? > I have not found a clear specification of the semantics. > > Given a start Type of tstart and an end Type of tend, > a start Code of cstart and an end Code of cend, and > an ICMP packet with Type t and Code c: > > Is the test that an implementation MUST make: > > a) (tstart <= t <= tend) AND (cstart <= c <= cend), > or > b) tstart*256+cstart <= t*256+c <= tend*256+cend > > I think that either 2401bis or IKEv2 should state one of the above to > make sure that all implementations interpret things the same way. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon Apr 19 10:22:25 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3JHMNO4001150; Mon, 19 Apr 2004 10:22:24 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFcMH-00030N-SE; Mon, 19 Apr 2004 13:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFSvd-00030X-R9 for ipsec@optimus.ietf.org; Mon, 19 Apr 2004 03:10:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21645 for ; Mon, 19 Apr 2004 03:10:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFSvZ-0007Yt-BR for ipsec@ietf.org; Mon, 19 Apr 2004 03:10:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFSub-0007Ll-00 for ipsec@ietf.org; Mon, 19 Apr 2004 03:09:50 -0400 Received: from ip212-226-138-153.adsl.kpnqwest.fi ([212.226.138.153] helo=mail.kivinen.iki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BFSu1-00078O-00 for ipsec@ietf.org; Mon, 19 Apr 2004 03:09:14 -0400 Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i3J78kfK005113 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 19 Apr 2004 10:08:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.12.10/8.12.6/Submit) id i3J78k5H005110; Mon, 19 Apr 2004 10:08:46 +0300 (EEST) 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: <16515.31485.122746.321148@fireball.acr.fi> Date: Mon, 19 Apr 2004 10:08:45 +0300 From: Tero Kivinen To: ynir@checkpoint.com Cc: "Geoffrey Huang" , pasi.eronen@nokia.com, ipsec@ietf.org Subject: Re: [Ipsec] Re: IKEv2 AUTH payload In-Reply-To: <61444.217.132.141.171.1082215022.squirrel@sslvpn.checkpoint.com> References: <052E0C61B69C3741AFA5FE88ACC775A61223CC@esebe023.ntc.nokia.com> <6C08C547-8E10-11D8-A925-000A95834BAA@checkpoint.com> <40801AE8.7030207@cisco.com> <61444.217.132.141.171.1082215022.squirrel@sslvpn.checkpoint.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 21 min X-Total-Time: 21 min X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Yoav Nir writes: > Some methods may, and the EAP-success message has optional text which > could be something like "User authenticated for 7200 seconds". But > neither is generic enough. The difference between re-keying and > re-authentication is not nuanced, as re-keying can be initiated by either > side, while re-authentication can only be initiated by the user. OTOH it > is the server (or gateway) that will have a policy about re-authenticating > clients. Unless the gateway passes the information to the client somehow, > then there's no way that the client can authenticate in time. So we need notification REAUTHENTICATE_NOW from the server (gateway) to the client, which tells that re-authentication is required now. If the client does not support that notification, and will not re-authenticate in xxx seconds (configurable, default should be couple of minutes) then the server will send delete notification to the IKE SA, forcing the client to re-authenticate. If client does support REAUTHENTICATE_NOW notifications it will start creating new IKE_SA re-authenticating at the same time, and after that is finished, it re-keys all IPsec SAs using that new IKE_SA with REKEY_SA notification, moving all traffic from old SA to new. After the re-authentication and rekey is finished, the client will delete the old IKE_SA (and old IPsec SAs). I.e. the protocol will be following (n = re-authenticate interval in minutes, m = time to give for the client to finish the re-authentication): Client Server ------ ------ << Client will create initial IKE SA and IPsec SA >> 1. HDR, SAi1, KEi, Ni -> 2. <- HDR, SAr1, KEr, Nr 3. HDR, SK { IDi, AUTH, SAi2, TSi, TSr} -> 4. <- HDR, SK { IDr, AUTH, SAr2, TSi, TSr} << Traffic goes on >> << After n - m minutes, the server noticies that it will require the client to do reauthentication now >> 5. <- N(REAUTHENTICATE_NOW) 6. ACK -> << Client starts to create new IKE SA >> 7. HDR, SAi1, KEi, Ni -> 8. <- HDR, SAr1, KEr, Nr 9. HDR, SK { IDi, AUTH, N(REKEY_SA), SAi2, TSi, TSr} -> 10. <- HDR, SK { IDr, AUTH, SAr2, TSi, TSr} << Note, that client will send REKEY_SA notification along with the IPsec SA creation. >> << After the IKE and IPsec SAs are rekeyed, client will delete old IKE SA, and the old IPsec SA (this is sent inside the old IKE SA) >> 11. D -> 12. <- ACK Now traffic has moved to the new IPsec SA, and the IKE SA has been re-authenticated. If the client does not support this new REAUTHENTICATE_NOW notification the processing goes like this (after step 6): << Client simply ignored the REAUTHENTICATE_NOW notification as it didn't undestand it, or was unwilling (or unable, because user didn't write in the password in time) to re-authenticate now >> << After m minutes the server decides, that the client is not going to re-authenticate, so it simply deletes the IKE_SA >> 7b. <- D 8b. ACK -> << Now client, will not have IKE_SA, nor IPsec SA, so it needs to create them again when it needs them next (or when it is again able to do it, i.e. when the user comes back from lunch and is able to type in the password again >> 9b. HDR, SAi1, KEi, Ni -> 10b. <- HDR, SAr1, KEr, Nr 11b. HDR, SK { IDi, AUTH, SAi2, TSi, TSr} -> 12b. <- HDR, SK { IDr, AUTH, SAr2, TSi, TSr} << Traffic can continue >> That kind of change can be made after the base IKEv2 draft is ready, as a separate draft and protocol, as it will be interoperable with base IKEv2 version too. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon Apr 19 11:48:58 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3JImuG7008353; Mon, 19 Apr 2004 11:48:57 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFdef-00023n-KR; Mon, 19 Apr 2004 14:38:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFdZ2-0000cA-1a for ipsec@optimus.ietf.org; Mon, 19 Apr 2004 14:32:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00026 for ; Mon, 19 Apr 2004 14:32:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFdYz-0001PJ-CS for ipsec@ietf.org; Mon, 19 Apr 2004 14:32:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFdY3-0001BQ-00 for ipsec@ietf.org; Mon, 19 Apr 2004 14:31:16 -0400 Received: from smtp-out1.oct.nac.net ([209.123.233.211]) by ietf-mx with smtp (Exim 4.12) id 1BFdXD-0000xY-00 for ipsec@ietf.org; Mon, 19 Apr 2004 14:30:23 -0400 Received: (qmail 95069 invoked from network); 19 Apr 2004 18:30:23 -0000 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 19 Apr 2004 18:30:23 -0000 Received: (qmail 22951 invoked from network); 19 Apr 2004 14:30:23 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.191) by mail1.oct.nac.net with SMTP; 19 Apr 2004 14:30:23 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id i3JGueN02450; Mon, 19 Apr 2004 12:56:40 -0400 Date: Mon, 19 Apr 2004 12:56:40 -0400 (EDT) From: George Gross To: cc: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Ipsec] multicast group SA directionality Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Hi, While stepping through the RFC2401-bis draft mapping to GSAKMP, I can across a few sections where it talks about SA directionality: 1. section 4.4.1 page 16 says "For traffic protected by IPsec, the source and destination address and port are swapped... consistent with IKE conventions." 2. Section 5.1 step 3 on page 30 also assumes bi-directional SA set up. My question: these passages seem to have assumed IKE bi-directional security associations, correct? would it be reasonable to adjust RFC2401-bis text in these sections to also allow unidirectional SA? As motivation, in some multicast applications the group SA is really unidirectional, as there is one speaker and many receivers. As a reasonable group security policy, the receiver endpoints would have their SPD set up to both receive that speaker's transmission and inhibit their ability to send to the group. In other words, only authorized endpoints send to the group, unauthorized endpoints have their traffic discarded by unidirectional SPD-O entries. tia, George _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon Apr 19 22:54:22 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3K5sKrV075412; Mon, 19 Apr 2004 22:54:21 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFo54-0003QF-R0; Tue, 20 Apr 2004 01:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFo1w-0002Yo-Vi for ipsec@optimus.ietf.org; Tue, 20 Apr 2004 01:42:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10267 for ; Tue, 20 Apr 2004 01:42:47 -0400 (EDT) From: byfraser@cisco.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFo1t-0006mR-Le for ipsec@ietf.org; Tue, 20 Apr 2004 01:42:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFo13-0006XT-00 for ipsec@ietf.org; Tue, 20 Apr 2004 01:41:54 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BFo0B-0006Hw-00 for ipsec@ietf.org; Tue, 20 Apr 2004 01:41:00 -0400 Received: from lists.tislabs.com (fc59.ufro.cl [200.10.17.59]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3K5bg101291 for ; Tue, 20 Apr 2004 01:37:43 -0400 (EDT) Message-Id: <200404200537.i3K5bg101291@lists.tislabs.com> To: ipsec@lists.tislabs.com Date: Tue, 20 Apr 2004 02:41:13 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.4 required=5.0 tests=MIME_BOUND_NEXTPART, MISSING_MIMEOLE,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [Ipsec] Re: List Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_NETSKY.P in file details.txt .pif (in archive_ipsec.zip) The file archive_ipsec.zip is moved to /etc/iscan/virus/virQKAM8aamR. --------------------------------------------------------- ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Here is my icq list. +++ Attachment: No Virus found +++ Bitdefender AntiVirus - www.bitdefender.com ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) archive_ipsec.zip is removed from here because it contains a virus. --------------------------------------------------------- ------=_NextPart_000_0016----=_NextPart_000_0016-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 20 01:57:12 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3K8vBV9041476; Tue, 20 Apr 2004 01:57:12 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFqvC-00056x-9R; Tue, 20 Apr 2004 04:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFqim-0001Is-Lp for ipsec@optimus.ietf.org; Tue, 20 Apr 2004 04:35:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01673 for ; Tue, 20 Apr 2004 04:35:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFqij-0004k8-K0 for ipsec@ietf.org; Tue, 20 Apr 2004 04:35:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFqha-0004RS-00 for ipsec@ietf.org; Tue, 20 Apr 2004 04:33:59 -0400 Received: from ip212-226-138-153.adsl.kpnqwest.fi ([212.226.138.153] helo=mail.kivinen.iki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BFqgs-0004BC-00 for ipsec@ietf.org; Tue, 20 Apr 2004 04:33:14 -0400 Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i3K8WtfK019808 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 20 Apr 2004 11:32:55 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.12.10/8.12.6/Submit) id i3K8Ws9d019805; Tue, 20 Apr 2004 11:32:54 +0300 (EEST) 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: <16516.57398.16635.714183@fireball.acr.fi> Date: Tue, 20 Apr 2004 11:32:54 +0300 From: Tero Kivinen To: "Michael Roe" Cc: "Charles Lynn" , Subject: RE: [Ipsec] Interpretation of ICMP Type and Code In-Reply-To: <579E83556A36E44EB2945CCE990B31740140B5FB@EUR-MSG-02.europe.corp.microsoft.com> References: <579E83556A36E44EB2945CCE990B31740140B5FB@EUR-MSG-02.europe.corp.microsoft.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 3 min X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Michael Roe writes: > I had interpreted the text as meaning (b), > tstart*256+cstart <= t*256+c <= tend*256+cend > But as you say, it's not entirely clear. I think this is the only reasonable interpretation. The codes inside the types do not have such ordering that it would be usefull to say send all types 1, 2, 3 with codes 2, 3 to this SA. On the other hand I think most used features will be where tstart == tend, and cstart and cend specify the part of that ICMP type, or where the tstart and tend have range and cstart = 0, and cend = 255, i.e. all codes for those types. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 20 22:02:12 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3L52Bwk052797; Tue, 20 Apr 2004 22:02:12 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG9kH-0005Go-QJ; Wed, 21 Apr 2004 00:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG9X9-0008L7-K5 for ipsec@optimus.ietf.org; Wed, 21 Apr 2004 00:40:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23209 for ; Wed, 21 Apr 2004 00:40:24 -0400 (EDT) From: tytso@mit.edu Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BG9X6-0001JW-TY for ipsec@ietf.org; Wed, 21 Apr 2004 00:40:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG9W7-0001CM-00 for ipsec@ietf.org; Wed, 21 Apr 2004 00:39:24 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BG9V8-000136-00 for ipsec@ietf.org; Wed, 21 Apr 2004 00:38:22 -0400 Received: from lists.tislabs.com ([213.70.140.9]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3L4bV115104 for ; Wed, 21 Apr 2004 00:37:32 -0400 (EDT) Message-Id: <200404210437.i3L4bV115104@lists.tislabs.com> To: ipsec@lists.tislabs.com Date: Wed, 21 Apr 2004 10:09:16 +0530 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_001B_01C0CA80.6B015D10" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.2 required=5.0 tests=HTML_40_50,HTML_MESSAGE, HTML_RELAYING_FRAME,MICROSOFT_EXECUTABLE,MIME_SUSPECT_NAME, MISSING_MIMEOLE,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [Ipsec] Mail Delivery (failure ipsec@lists.tislabs.com) Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C0CA80.6B015D10 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus HTML_NETSKY.P in file email-body The file email-body is moved to /etc/iscan/virus/virXUD8Hb4nP. --------------------------------------------------------- ------=_NextPart_000_001B_01C0CA80.6B015D10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001C_01C0CA80.6B015D10" ------=_NextPart_001_001C_01C0CA80.6B015D10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_001C_01C0CA80.6B015D10 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) email-body is removed from here because it contains a virus. --------------------------------------------------------- ------=_NextPart_001_001C_01C0CA80.6B015D10-- ------=_NextPart_000_001B_01C0CA80.6B015D10 Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [Filename: message.scr, Content-Type: audio/x-wav] The attachment file in the message has been removed by eManager. ------=_NextPart_000_001B_01C0CA80.6B015D10-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 21 03:48:46 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LAmjFY059315; Wed, 21 Apr 2004 03:48:45 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGF4I-0003up-9j; Wed, 21 Apr 2004 06:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGF23-0002rN-Qi for ipsec@optimus.ietf.org; Wed, 21 Apr 2004 06:32:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09345 for ; Wed, 21 Apr 2004 06:32:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGF1z-0002mE-PI for ipsec@ietf.org; Wed, 21 Apr 2004 06:32:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGF14-0002g0-00 for ipsec@ietf.org; Wed, 21 Apr 2004 06:31:43 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BGF0H-0002ZV-00 for ipsec@ietf.org; Wed, 21 Apr 2004 06:30:53 -0400 Received: from brahma.intotoind.com ([202.125.84.113]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3LAU1127901 for ; Wed, 21 Apr 2004 06:30:03 -0400 (EDT) Received: from i15.intotoinc.com (2mc50.intotoind.com [172.16.2.50]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i3LAVFPN028113 for ; Wed, 21 Apr 2004 16:01:17 +0530 Message-Id: <5.1.0.14.0.20040421161342.027387d0@172.16.1.10> X-Sender: raghava@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 21 Apr 2004 16:13:57 +0530 To: ipsec@lists.tislabs.com From: Raghava Rao Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.41 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Ipsec] Re: Outbound SA Bundle processing Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Hi, Same issue was raised in one of the bakeoff (MAY 1999). Some vendors supported format 2 and some format 1. But most of the vendors supported one TUNNEL IP header for both AH and ESP together. In my view security over head can be reduced in format 1 by avoiding the additional TUNNEL IP header construction in the format 2. -raghava At 11:51 AM 4/6/2004 -0400, Stephen Kent wrote: >At 2:11 PM -0700 4/5/04, suren wrote: >>Hi, >> >>I have two queries regarding SA Bundle processing. >> >>1) If we have two SAs in an outbound SA Bundle as below, >> >> 1st SA : ESP in tunnel mode. >> 2nd SA : AH in tunnel mode. >> >> What should be the correct format of the packet that is >> produced after applying these two SAs? >> >> i) [IP1][AH][ESP][Original_IP] >> Or >> >> ii) [IP2][AH][IP1][ESP][Original_IP] > >since both are described as tunnel mode, the second format is correct. > >> >>2) If we have more than two SAs in an outbound SA Bundle as below, >> >> 1st SA : ESP in tunnel mode, with DES >> 2nd SA : ESP in tunnel mode, with 3DES >> 3rd SA : ESP in tunnel mode, with AES >> 4th SA : AH in tunnel mode. >> >> What should be the correct format of the packet that is >> produced after applying these two SAs? > >note that support for bundles, other than the trivial ones mandated by >2401 use cases, has been problematic and so 2401bis drops the requirement >for such support. your example above is easily rendered into an >appropriate format, but it seems pretty unrealistic. also, you list 4 SAs >in the second example, but then refer to "applying these two SAs?" which >suggests an arithmetic mismatch. > >Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 21 05:21:44 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LCLh4U066435; Wed, 21 Apr 2004 05:21:44 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGGbA-0005qO-6h; Wed, 21 Apr 2004 08:13:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGGWD-0003R5-39 for ipsec@optimus.ietf.org; Wed, 21 Apr 2004 08:07:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15347 for ; Wed, 21 Apr 2004 08:07:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGGWC-0000rH-4A for ipsec@ietf.org; Wed, 21 Apr 2004 08:07:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGGV8-0000hf-00 for ipsec@ietf.org; Wed, 21 Apr 2004 08:06:50 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BGGUJ-0000Yz-00 for ipsec@ietf.org; Wed, 21 Apr 2004 08:05:59 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3LC5F108746 for ; Wed, 21 Apr 2004 08:05:16 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3LC3Q19009833 for ; Wed, 21 Apr 2004 08:03:26 -0400 (EDT) Received: from rs9.luxsci.com(66.216.98.59) by nutshell.tislabs.com via csmap (V6.0) id srcAAAhnay8s; Wed, 21 Apr 04 08:02:42 -0400 Received: from rs9.luxsci.com (localhost [127.0.0.1]) by rs9.luxsci.com (8.12.11/8.12.10) with ESMTP id i3LC50uX017127 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 21 Apr 2004 07:05:00 -0500 Received: (from root@localhost) by rs9.luxsci.com (8.12.11/8.12.10/Submit) id i3LC41HM017020; Wed, 21 Apr 2004 12:04:01 GMT Message-Id: <200404211204.i3LC41HM017020@rs9.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Wed, 21 Apr 2004 12:04:01 +0000 From: "William Dixon" To: Date: Wed, 21 Apr 2004 08:02:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Lux-Comment: LuxSci remailer message ID code - 1082549041-4943397.2570093 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Ipsec] Specification of BGP IPsec policy Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Does anyone have a reference configuration that is proposed for securing BGP TCP connections with IPsec ? Eg. the selector definition, tunnel/transport, hash, key size, lifetimes, etc. I see this draft proposes not using IPsec. So maybe nobody is doing it. http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt Wm _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 21 06:00:59 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LD0xp2069437; Wed, 21 Apr 2004 06:00:59 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGHB0-0002E9-Tz; Wed, 21 Apr 2004 08:50:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGH8y-0000cF-RS for ipsec@optimus.ietf.org; Wed, 21 Apr 2004 08:48:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17564 for ; Wed, 21 Apr 2004 08:47:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGH8x-0006wx-GK for ipsec@ietf.org; Wed, 21 Apr 2004 08:47:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGH89-0006oR-00 for ipsec@ietf.org; Wed, 21 Apr 2004 08:47:10 -0400 Received: from reloaded.enst.fr ([137.194.2.14] helo=smtp2.enst.fr) by ietf-mx with esmtp (Exim 4.12) id 1BGH7e-0006fq-00 for ipsec@ietf.org; Wed, 21 Apr 2004 08:46:38 -0400 Received: from email.enst.fr (muse.enst.fr [137.194.2.33]) by smtp2.enst.fr (Postfix) with ESMTP id CD6883DC; Wed, 21 Apr 2004 14:46:36 +0200 (CEST) Received: from enst.fr (akkar.enst.fr [137.194.162.32]) by email.enst.fr (8.9.3/8.9.3) with ESMTP id OAA09963; Wed, 21 Apr 2004 14:46:36 +0200 (CEST) Message-ID: <40866D50.20309@enst.fr> Date: Wed, 21 Apr 2004 14:47:12 +0200 From: Mohamad Badra User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax; PROMO) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams Cc: Bill Sommerfeld , Geoffrey Huang , Yoav Nir , Pasi.Eronen@nokia.com, ipsec@ietf.org Subject: Re: [Ipsec] Re: IKEv2 AUTH payload References: <40801AE8.7030207@cisco.com> <200404162151.i3GLpvQU012761@thunk.east.sun.com> <20040416221442.GF22519@binky.central.sun.com> In-Reply-To: <20040416221442.GF22519@binky.central.sun.com> Content-Type: multipart/alternative; boundary="------------040902080604050000010204" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=HTML_20_30,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------040902080604050000010204 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit >>>I'm not too familiar with the various user authentication methods, >>>but do any of these methods support the notion of an authentication >>>lifetime? >>> >>> >>Yes. (Kerberos is a notable example). >> >> > >And plain old PKI too, since certificates have expiration dates. > >Suppose you're using something like kx509 to get short-lived certs >issued after authenticating with Kerberos V... > You can also have your x509 Passport-certicate (validate for long-time) and then get Attribute Cetificate to get short-lived Visa-certificate for the autthorisation and/or the authentication. Badra --------------040902080604050000010204 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
I'm not too familiar with the various user authentication methods,
but do any of these methods support the notion of an authentication
lifetime?
      
Yes.  (Kerberos is a notable example).
    

And plain old PKI too, since certificates have expiration dates.

Suppose you're using something like kx509 to get short-lived certs
issued after authenticating with Kerberos V...
You can also have your x509 Passport-certicate (validate for long-time) and then get Attribute Cetificate to get short-lived Visa-certificate for the autthorisation and/or the authentication.

Badra
--------------040902080604050000010204-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 21 14:07:14 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LL7DEZ010153; Wed, 21 Apr 2004 14:07:13 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGOZv-0003Uy-AQ; Wed, 21 Apr 2004 16:44:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGCkm-0007wQ-E3 for ipsec@optimus.ietf.org; Wed, 21 Apr 2004 04:06:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02478 for ; Wed, 21 Apr 2004 04:06:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGCkj-0000nf-PV for ipsec@ietf.org; Wed, 21 Apr 2004 04:06:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGCjj-0000i8-00 for ipsec@ietf.org; Wed, 21 Apr 2004 04:05:40 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BGCjV-0000cl-00 for ipsec@ietf.org; Wed, 21 Apr 2004 04:05:25 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3L84i111082 for ; Wed, 21 Apr 2004 04:04:44 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3L82MrT000447 for ; Wed, 21 Apr 2004 04:02:22 -0400 (EDT) Received: from unknown(202.125.84.113) by nutshell.tislabs.com via csmap (V6.0) id srcAAAiwaaSa; Wed, 21 Apr 04 04:01:48 -0400 Received: from i15.intoto.com (2mc50.intotoind.com [172.16.2.50]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i3L84VBH007171; Wed, 21 Apr 2004 13:34:32 +0530 Message-Id: <5.1.0.14.0.20040421124903.0256cd00@172.16.1.10> X-Sender: raghava@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 21 Apr 2004 13:46:33 +0530 To: Stephen Kent From: Raghava Rao Cc: ipsec@lists.tislabs.com In-Reply-To: References: <1081199470.1273.49.camel@suren> <1081199470.1273.49.camel@suren> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.41 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Ipsec] Re: Outbound SA Bundle processing Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Hi, Same issue was raised in one of the bakeoff (MAY 1999). Some vendors supported format 2 and some format 1. But most of the vendors supported one TUNNEL IP header for both AH and ESP together. In my view security over head can be reduced in format 1 by avoiding the additional TUNNEL IP header construction in the format 2. -raghava At 11:51 AM 4/6/2004 -0400, Stephen Kent wrote: >At 2:11 PM -0700 4/5/04, suren wrote: >>Hi, >> >>I have two queries regarding SA Bundle processing. >> >>1) If we have two SAs in an outbound SA Bundle as below, >> >> 1st SA : ESP in tunnel mode. >> 2nd SA : AH in tunnel mode. >> >> What should be the correct format of the packet that is >> produced after applying these two SAs? >> >> i) [IP1][AH][ESP][Original_IP] >> Or >> >> ii) [IP2][AH][IP1][ESP][Original_IP] > >since both are described as tunnel mode, the second format is correct. > >> >>2) If we have more than two SAs in an outbound SA Bundle as below, >> >> 1st SA : ESP in tunnel mode, with DES >> 2nd SA : ESP in tunnel mode, with 3DES >> 3rd SA : ESP in tunnel mode, with AES >> 4th SA : AH in tunnel mode. >> >> What should be the correct format of the packet that is >> produced after applying these two SAs? > >note that support for bundles, other than the trivial ones mandated by >2401 use cases, has been problematic and so 2401bis drops the requirement >for such support. your example above is easily rendered into an >appropriate format, but it seems pretty unrealistic. also, you list 4 SAs >in the second example, but then refer to "applying these two SAs?" which >suggests an arithmetic mismatch. > >Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 21 14:54:12 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LLsACa013465; Wed, 21 Apr 2004 14:54:10 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGObg-0004Rx-F0; Wed, 21 Apr 2004 16:46:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGNbm-0007C7-AR for ipsec@optimus.ietf.org; Wed, 21 Apr 2004 15:42:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10393 for ; Wed, 21 Apr 2004 15:42:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGNbk-0006Gj-Nw for ipsec@ietf.org; Wed, 21 Apr 2004 15:42:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGNan-000679-00 for ipsec@ietf.org; Wed, 21 Apr 2004 15:41:10 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BGNaD-0005xc-00 for ipsec@ietf.org; Wed, 21 Apr 2004 15:40:33 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3LJdm126082 for ; Wed, 21 Apr 2004 15:39:51 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3LJbKfP028951 for ; Wed, 21 Apr 2004 15:37:20 -0400 (EDT) Received: from odin.ietf.org(132.151.1.176) by nutshell.tislabs.com via csmap (V6.0) id srcAAARNaOv4; Wed, 21 Apr 04 15:36:38 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10102; Wed, 21 Apr 2004 15:37:55 -0400 (EDT) Message-Id: <200404211937.PAA10102@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Date: Wed, 21 Apr 2004 15:37:55 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Subject: [Ipsec] I-D ACTION:draft-ietf-ipsec-ikev2-algorithms-05.txt Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , --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 Algorithms for use in the Internet Key Exchange Version 2 Author(s) : J. Schiller Filename : draft-ietf-ipsec-ikev2-algorithms-05.txt Pages : 6 Date : 2004-4-21 The IPSec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE [RFC2409] and IKEv2 [IKEv2]) provide a mechanism to negotiate which algorithms should be used in any even association. However 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 use of IKEv2 as well as specifying algorithms that should be implemented because they made be promoted to mandatory at some future time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-algorithms-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-algorithms-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-21154718.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-algorithms-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-algorithms-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-21154718.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 21 15:41:35 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LMfYpx017013; Wed, 21 Apr 2004 15:41:34 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQ6F-0008SG-Mc; Wed, 21 Apr 2004 18:21:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPMY-00018g-Cs for ipsec@optimus.ietf.org; Wed, 21 Apr 2004 17:34:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17213 for ; Wed, 21 Apr 2004 17:34:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGPMV-0004VY-Qr for ipsec@ietf.org; Wed, 21 Apr 2004 17:34:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGPKU-0003wp-00 for ipsec@ietf.org; Wed, 21 Apr 2004 17:32:26 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BGPIG-0003KB-00 for ipsec@ietf.org; Wed, 21 Apr 2004 17:30:08 -0400 Received: from rs9.luxsci.com (rs9.luxsci.com [66.216.98.59]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3LLTQ111068 for ; Wed, 21 Apr 2004 17:29:27 -0400 (EDT) Received: from rs9.luxsci.com (localhost [127.0.0.1]) by rs9.luxsci.com (8.12.11/8.12.10) with ESMTP id i3LLU1C0022923 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 21 Apr 2004 16:30:01 -0500 Received: (from root@localhost) by rs9.luxsci.com (8.12.11/8.12.10/Submit) id i3LLS1xe022580; Wed, 21 Apr 2004 21:28:01 GMT Message-Id: <200404212128.i3LLS1xe022580@rs9.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Wed, 21 Apr 2004 21:28:01 +0000 From: "William Dixon" To: Subject: RE: [Ipsec] Specification of BGP IPsec policy Date: Wed, 21 Apr 2004 17:26:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <200404211204.i3LC41HM017020@rs9.luxsci.com> X-Lux-Comment: LuxSci remailer message ID code - 1082582881-3432578.24398646 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , The reason I ask is because the UK NISCC guidance says "use IPsec". http://www.uniras.gov.uk/vuls/2004/236929/index.htm I'm surprised that with such initial coordination, a specification of HOW to use IPsec wasn't offered in the bulletin. > -----Original Message----- > From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org] On > Behalf Of William Dixon > Sent: Wednesday, April 21, 2004 8:03 AM > To: ipsec@lists.tislabs.com > Subject: [Ipsec] Specification of BGP IPsec policy > > Does anyone have a reference configuration that is proposed > for securing BGP TCP connections with IPsec ? Eg. the > selector definition, tunnel/transport, hash, key size, lifetimes, etc. > > I see this draft proposes not using IPsec. So maybe nobody is > doing it. > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt > > Wm > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 21 16:05:54 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LN5quY019008; Wed, 21 Apr 2004 16:05:53 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQWo-0006MB-TS; Wed, 21 Apr 2004 18:49:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQCP-0002HW-Gl for ipsec@optimus.ietf.org; Wed, 21 Apr 2004 18:28:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23984 for ; Wed, 21 Apr 2004 18:28:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGQCM-0000TZ-Dv for ipsec@ietf.org; Wed, 21 Apr 2004 18:28:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGQ6D-000718-00 for ipsec@ietf.org; Wed, 21 Apr 2004 18:21:46 -0400 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx with esmtp (Exim 4.12) id 1BGQ1d-0005pp-00 for ipsec@ietf.org; Wed, 21 Apr 2004 18:17:01 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.45]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XT41JP8F; Wed, 21 Apr 2004 18:16:31 -0400 Message-Id: <5.2.0.9.0.20040421181342.028a7210@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 21 Apr 2004 18:15:55 -0400 To: "Theodore Ts'o" , ipsec@ietf.org From: Mark Duffy Subject: Re: [Ipsec] Moving the IPSEC mailing list In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Hi Ted, Will there be a new archive for the mailing list? The one at ftp.tislabs.com seems to have stopped recording on 14 April. Thanks, Mark At 03:03 PM 4/14/2004 -0400, Theodore Ts'o wrote: >As some of you have no doubt noticed, you recently received a mail >message announcing that you have been subscribed to the mailing list >"ipsec@ietf.org". > >This move of the list from ipsec@lists.tislabs.com was caused by >increasing problems with the list that had caused various complaints >from working group members. Unfortunately, the personnel at >lists.tislabs.com were getting overwhelmed by spam attacks, so the >service had declined to unacceptable levels. > >Some of these problems included tislabs.com ending up on the ORBS lists >temporarily, and various messages (coming from people posting from >non-standard addresses) getting mistaken as SPAM and getting lost. So >we have arranged to moved the ipsec mailing list to the ipsec@ietf.org. > >Please use ipsec@ietf.org for all future ipsec mailing list traffic. >ipsec@lists.tislabs.com will forward to ipsec@ietf.org for a short >while, to aid in the transition. > > - Ted > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 21 17:07:38 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3M07bsf025111; Wed, 21 Apr 2004 17:07:38 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGRQk-00043b-Cw; Wed, 21 Apr 2004 19:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGRLS-0000oO-Cj for ipsec@optimus.ietf.org; Wed, 21 Apr 2004 19:41:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01185 for ; Wed, 21 Apr 2004 19:41:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGRLQ-0001TN-Hz for ipsec@ietf.org; Wed, 21 Apr 2004 19:41:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGRKW-0001Gx-00 for ipsec@ietf.org; Wed, 21 Apr 2004 19:40:37 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BGRJn-00013o-00 for ipsec@ietf.org; Wed, 21 Apr 2004 19:39:51 -0400 Received: from [63.202.92.152] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3LNdiW0022365 for ; Wed, 21 Apr 2004 16:39:45 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <5.2.0.9.0.20040421181342.028a7210@email> References: <5.2.0.9.0.20040421181342.028a7210@email> Date: Wed, 21 Apr 2004 16:39:47 -0700 To: ipsec@ietf.org From: Paul Hoffman / VPNC Subject: Re: [Ipsec] Moving the IPSEC mailing list Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , At 6:15 PM -0400 4/21/04, Mark Duffy wrote: >Will there be a new archive for the mailing list? The one at >ftp.tislabs.com seems to have stopped recording on 14 April. VPNC's archive at made it through the transition fine and is up-to-date. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu Apr 22 15:13:27 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3MMDPgP022410; Thu, 22 Apr 2004 15:13:25 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGm90-0003gF-Cu; Thu, 22 Apr 2004 17:54:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGlrq-00039h-E6 for ipsec@optimus.ietf.org; Thu, 22 Apr 2004 17:36:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02622 for ; Thu, 22 Apr 2004 17:36:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGlrl-0004yg-U1 for ipsec@ietf.org; Thu, 22 Apr 2004 17:36:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGlqh-0004iQ-00 for ipsec@ietf.org; Thu, 22 Apr 2004 17:35:12 -0400 Received: from mail3.panix.com ([166.84.1.74]) by ietf-mx with esmtp (Exim 4.12) id 1BGlpm-0004Rt-00 for ipsec@ietf.org; Thu, 22 Apr 2004 17:34:14 -0400 Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail3.panix.com (Postfix) with ESMTP id 111909829B for ; Thu, 22 Apr 2004 17:34:16 -0400 (EDT) Received: (from tls@localhost) by panix5.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) id i3MLYGu22386 for ipsec@ietf.org; Thu, 22 Apr 2004 17:34:16 -0400 (EDT) Date: Thu, 22 Apr 2004 17:34:16 -0400 From: Thor Lancelot Simon To: ipsec@ietf.org Subject: Re: [Ipsec] Specification of BGP IPsec policy Message-ID: <20040422213415.GA21886@panix.com> Reply-To: tls@rek.tjls.com References: <200404211204.i3LC41HM017020@rs9.luxsci.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404211204.i3LC41HM017020@rs9.luxsci.com> User-Agent: Mutt/1.4.2.1i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , On Wed, Apr 21, 2004 at 08:02:35AM -0400, William Dixon wrote: > Does anyone have a reference configuration that is proposed for securing BGP > TCP connections with IPsec ? Eg. the selector definition, tunnel/transport, > hash, key size, lifetimes, etc. > > I see this draft proposes not using IPsec. So maybe nobody is doing it. > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt Given that even statically-keyed AH would be far more secure than the botch that appears to be Cisco's preferred solution (TCP-MD5), this is really unfortunate -- but it does appear to be the case. I'm seeing a growing trend of security-clued employees of networking company _X_ trying hard to DTRT over here in the relevant working groups, while consultants and "sales engineers" and the like from _X_ go around on the other hand advising customers to DTWT over there in the real world of deployed systems -- even where it would be no more onerous to DTRT, as with statically-keyed AH vs. statically-keyed TCP-MD5, and would reduce the need to maintain fundamentally duplicitave functionality in complicated products. How about it, folks? How about everyone tries, just once or twice a week, to hit other employees of one's employer -- you know, in particular those ones out there in the field telling customers to use the same preshared key with multiple IKE peers and the like -- with the clue stick? We could do a lot of good, and a lot of trouble and embarrassment could be avoided later besides. :-) Thor _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu Apr 22 22:59:06 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3N5x403072815; Thu, 22 Apr 2004 22:59:05 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGtXg-00066d-SW; Fri, 23 Apr 2004 01:48:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGtSg-0004ve-Bo for ipsec@optimus.ietf.org; Fri, 23 Apr 2004 01:42:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01614 for ; Fri, 23 Apr 2004 01:42:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGtSb-00062z-35 for ipsec@ietf.org; Fri, 23 Apr 2004 01:42:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGtRe-0005mf-00 for ipsec@ietf.org; Fri, 23 Apr 2004 01:41:51 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BGtRE-0005VG-00 for ipsec@ietf.org; Fri, 23 Apr 2004 01:41:24 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3N5ef102300 for ; Fri, 23 Apr 2004 01:40:42 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3N5cnIN021279 for ; Fri, 23 Apr 2004 01:38:50 -0400 (EDT) Received: from rs9.luxsci.com(66.216.98.59) by nutshell.tislabs.com via csmap (V6.0) id srcAAAU3aqoP; Fri, 23 Apr 04 01:37:54 -0400 Received: from rs9.luxsci.com (localhost [127.0.0.1]) by rs9.luxsci.com (8.12.11/8.12.10) with ESMTP id i3N5e5Iv017385 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 23 Apr 2004 00:40:05 -0500 Received: (from root@localhost) by rs9.luxsci.com (8.12.11/8.12.10/Submit) id i3N5c15j017108; Fri, 23 Apr 2004 05:38:01 GMT Message-Id: <200404230538.i3N5c15j017108@rs9.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Fri, 23 Apr 2004 05:38:01 +0000 From: "William Dixon" To: , Subject: RE: [Ipsec] Specification of BGP IPsec policy Date: Fri, 23 Apr 2004 01:37:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <200404212128.i3LLS1xe022580@rs9.luxsci.com> X-Lux-Comment: LuxSci remailer message ID code - 1082698681-8905703.73232318 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , FYI. I found David Ward's (Cisco) expired draft from two years ago. David, have you received sufficient interest recently to re-activate this draft ? http://www.watersprings.org/pub/id/draft-ward-bgp-ipsec-00.txt If you do, please review Steve's latest guidelines: http://www.ietf.org/internet-drafts/draft-bellovin-useipsec-03.txt > -----Original Message----- > From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org] On > Behalf Of William Dixon > Sent: Wednesday, April 21, 2004 5:27 PM > To: ipsec@lists.tislabs.com > Subject: RE: [Ipsec] Specification of BGP IPsec policy > > The reason I ask is because the UK NISCC guidance says "use IPsec". > > http://www.uniras.gov.uk/vuls/2004/236929/index.htm > > I'm surprised that with such initial coordination, a > specification of HOW to use IPsec wasn't offered in the bulletin. > > > -----Original Message----- > > From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org] On > Behalf Of > > William Dixon > > Sent: Wednesday, April 21, 2004 8:03 AM > > To: ipsec@lists.tislabs.com > > Subject: [Ipsec] Specification of BGP IPsec policy > > > > Does anyone have a reference configuration that is proposed for > > securing BGP TCP connections with IPsec ? Eg. the selector > definition, > > tunnel/transport, hash, key size, lifetimes, etc. > > > > I see this draft proposes not using IPsec. So maybe nobody is doing > > it. > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt > > > > Wm > > > > > > > > _______________________________________________ > > Ipsec mailing list > > Ipsec@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipsec > > > > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri Apr 23 09:48:43 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3NGmgnU076809; Fri, 23 Apr 2004 09:48:42 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3bw-0003az-QH; Fri, 23 Apr 2004 12:33:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH3XX-0001LT-Hq for ipsec@optimus.ietf.org; Fri, 23 Apr 2004 12:28:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17313 for ; Fri, 23 Apr 2004 12:28:30 -0400 (EDT) From: kivinen@iki.fi Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH3LT-0003fV-Mz for ipsec@ietf.org; Fri, 23 Apr 2004 12:16:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH3IV-0002rp-00 for ipsec@ietf.org; Fri, 23 Apr 2004 12:13:04 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BH3G5-0002Vx-00 for ipsec@ietf.org; Fri, 23 Apr 2004 12:10:33 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3NG9mp24265 for ; Fri, 23 Apr 2004 12:09:48 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3NG8661001460 for ; Fri, 23 Apr 2004 12:08:06 -0400 (EDT) Received: from localhost(203.162.165.215) by nutshell.tislabs.com via csmap (V6.0) id srcAAASPaW0c; Fri, 23 Apr 04 12:07:54 -0400 Date: Fri, 23 Apr 2004 23:08:30 +0700 To: ipsec@lists.tislabs.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------vitnkvbyuvrknspdwpin" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Subject: [Ipsec] ello! =)) Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , ----------vitnkvbyuvrknspdwpin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_FUNBAG.GEN in file Document.zip The file Document.zip is moved to /etc/iscan/virus/virWNDrabG7n. --------------------------------------------------------- ----------vitnkvbyuvrknspdwpin Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Argh, i don't like the plaintext :) password -- 23163 ----------vitnkvbyuvrknspdwpin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Document.zip is removed from here because it contains a virus. --------------------------------------------------------- ----------vitnkvbyuvrknspdwpin-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri Apr 23 11:53:35 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3NIrYG6088170; Fri, 23 Apr 2004 11:53:35 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5NC-0003Gj-Gj; Fri, 23 Apr 2004 14:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5Eo-0000h2-EF for ipsec@optimus.ietf.org; Fri, 23 Apr 2004 14:17:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24666 for ; Fri, 23 Apr 2004 14:17:19 -0400 (EDT) From: ipsec@lists.tislabs.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH5El-0005Oc-V4 for ipsec@ietf.org; Fri, 23 Apr 2004 14:17:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH5E6-00058O-00 for ipsec@ietf.org; Fri, 23 Apr 2004 14:16:39 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BH5DU-0004r5-00 for ipsec@ietf.org; Fri, 23 Apr 2004 14:16:00 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3NIFFp01198 for ; Fri, 23 Apr 2004 14:15:15 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3NIDYWQ018412 for ; Fri, 23 Apr 2004 14:13:34 -0400 (EDT) Message-Id: <200404231813.i3NIDYWQ018412@nutshell.tislabs.com> Received: from unknown(203.129.197.21) by nutshell.tislabs.com via csmap (V6.0) id srcAAA3Xai7J; Fri, 23 Apr 04 14:13:15 -0400 To: ipsec@lists.tislabs.com Date: Tue, 13 Apr 2004 23:45:39 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0009_00005943.00006C93" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.3 required=5.0 tests=DATE_IN_PAST_96_XX,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MISSING_MIMEOLE,MSGID_FROM_MTA_HEADER,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red * 0.1 LINES_OF_YELLING_2 BODY: 2 WHOLE LINES OF YELLING DETECTED * 1.2 DATE_IN_PAST_96_XX Date: is 96 hours or more before Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer * 0.8 MSGID_FROM_MTA_HEADER Message-Id was added by a relay Subject: [Ipsec] Re: Your software Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0009_00005943.00006C93 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Your document is attached. ------=_NextPart_000_0009_00005943.00006C93 Content-Type: text/html; name="application.pif.htm" Content-Disposition: attachment; filename="application.pif.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: application.pif
Virus name: W32/Netsky.d@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_0009_00005943.00006C93-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri Apr 23 14:31:48 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3NLVlpL002102; Fri, 23 Apr 2004 14:31:48 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7vx-0002Uo-5d; Fri, 23 Apr 2004 17:10:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7ei-0008OA-UD for ipsec@optimus.ietf.org; Fri, 23 Apr 2004 16:52:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10531 for ; Fri, 23 Apr 2004 16:52:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH7eg-0004fH-Pa for ipsec@ietf.org; Fri, 23 Apr 2004 16:52:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH7dj-0004ON-00 for ipsec@ietf.org; Fri, 23 Apr 2004 16:51:16 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BH7cm-00047b-00 for ipsec@ietf.org; Fri, 23 Apr 2004 16:50:16 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3NKnVp08539 for ; Fri, 23 Apr 2004 16:49:31 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3NKlpkq006880 for ; Fri, 23 Apr 2004 16:47:51 -0400 (EDT) Received: from rs9.luxsci.com(66.216.98.59) by nutshell.tislabs.com via csmap (V6.0) id srcAAADIaGAn; Fri, 23 Apr 04 16:47:47 -0400 Received: from rs9.luxsci.com (localhost [127.0.0.1]) by rs9.luxsci.com (8.12.11/8.12.10) with ESMTP id i3NKo802015763 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 23 Apr 2004 15:50:08 -0500 Received: (from root@localhost) by rs9.luxsci.com (8.12.11/8.12.10/Submit) id i3NKo1cR015728; Fri, 23 Apr 2004 20:50:01 GMT Message-Id: <200404232050.i3NKo1cR015728@rs9.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Fri, 23 Apr 2004 20:50:01 +0000 From: "William Dixon" To: "'Michael Richardson'" Cc: Subject: RE: [Ipsec] Specification of BGP IPsec policy Date: Fri, 23 Apr 2004 16:49:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <13265.1082741496@marajade.sandelman.ottawa.on.ca> X-Lux-Comment: LuxSci remailer message ID code - 1082753401-6132915.57857226 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , There are many ISPs with hundreds and perhaps thousands of BGP peering partners. So I respectfully disagree that a recommendation is not needed. I'm guessing this is the motivation behind Dave Wood's draft I mentioned earlier. It is important to have recommended defaults that people can apply operationally, and that vendors can support in their products (e.g. ISCSI definition for using IPsec to secure their TCP connections). > -----Original Message----- > From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] > Sent: Friday, April 23, 2004 1:32 PM > To: William Dixon > Cc: ipsec@lists.tislabs.com > Subject: Re: [Ipsec] Specification of BGP IPsec policy > > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "William" == William Dixon writes: > William> The reason I ask is because the UK NISCC > guidance says "use > William> IPsec". > > William> http://www.uniras.gov.uk/vuls/2004/236929/index.htm > > William, to "use IPsec", you have to bilaterally agree to do so. > As such, one can decide about the SPD along with the keying > material or method. If if is all within an enterprise, then > perhaps they can put it into a policy directory of some kind as well. > > One can also say bilaterally agree to "use IPsec > Opportunistic Encryption" (or just let people know your > router supports it on your IX list), in which case, all those > details are *ALSO* already specified. > > William> I'm surprised that with such initial coordination, a > William> specification of HOW to use IPsec wasn't offered in the > William> bulletin. > > Because it isn't necessary. > > - -- > ] 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 > > iQCVAwUBQIlS94qHRg3pndX9AQG2CgQArFV0VOBbCe7jvXMzI52Ii87V4oqso1hk > 6LVC1QDWnWxVzvTW12/KKBkFfZ2koav+WJUKbrETbJEy6c/bQTL/eBEdP+RzlByG > ZZQNMR08hYFI50+TmO2tN5mpuXnosTflWEClHk33QWg76Y1HDBnVYgr/WGKTz4ac > cZcZD5nT3Tk= > =19pA > -----END PGP SIGNATURE----- > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri Apr 23 19:03:14 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3O23C0U019876; Fri, 23 Apr 2004 19:03:12 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHCJr-0003TK-SH; Fri, 23 Apr 2004 21:51:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH7SJ-0003zT-1F for ipsec@optimus.ietf.org; Fri, 23 Apr 2004 16:39:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09732 for ; Fri, 23 Apr 2004 16:39:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH7SH-0001CA-1u for ipsec@ietf.org; Fri, 23 Apr 2004 16:39:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH7RF-0000se-00 for ipsec@ietf.org; Fri, 23 Apr 2004 16:38:22 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BH7QD-0000ZO-00 for ipsec@ietf.org; Fri, 23 Apr 2004 16:37:17 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3NKaWp07808 for ; Fri, 23 Apr 2004 16:36:33 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3NKYpga005303 for ; Fri, 23 Apr 2004 16:34:51 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca(205.150.200.166) by nutshell.tislabs.com via csmap (V6.0) id srcAAA8pairk; Fri, 23 Apr 04 16:34:44 -0400 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i3NKYJT11602 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 23 Apr 2004 16:34:22 -0400 (EDT) Received: from sandelman.ottawa.on.ca (207-232-97-30.ip.van.radiant.net [207.232.97.30]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i3NHvWl14742 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 23 Apr 2004 13:57:48 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3NHq8fJ015440 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 23 Apr 2004 10:52:09 -0700 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3NHVbnC013266; Fri, 23 Apr 2004 10:31:37 -0700 To: "William Dixon" cc: ipsec@lists.tislabs.com Subject: Re: [Ipsec] Specification of BGP IPsec policy In-Reply-To: Message from "William Dixon" of "Wed, 21 Apr 2004 17:26:44 EDT." <200404212128.i3LLS1xe022580@rs9.luxsci.com> References: <200404212128.i3LLS1xe022580@rs9.luxsci.com> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Fri, 23 Apr 2004 10:31:36 -0700 Message-ID: <13265.1082741496@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=LINES_OF_YELLING autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , -----BEGIN PGP SIGNED MESSAGE----- >>>>> "William" == William Dixon writes: William> The reason I ask is because the UK NISCC guidance says "use William> IPsec". William> http://www.uniras.gov.uk/vuls/2004/236929/index.htm William, to "use IPsec", you have to bilaterally agree to do so. As such, one can decide about the SPD along with the keying material or method. If if is all within an enterprise, then perhaps they can put it into a policy directory of some kind as well. One can also say bilaterally agree to "use IPsec Opportunistic Encryption" (or just let people know your router supports it on your IX list), in which case, all those details are *ALSO* already specified. William> I'm surprised that with such initial coordination, a William> specification of HOW to use IPsec wasn't offered in the William> bulletin. Because it isn't necessary. - -- ] 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 iQCVAwUBQIlS94qHRg3pndX9AQG2CgQArFV0VOBbCe7jvXMzI52Ii87V4oqso1hk 6LVC1QDWnWxVzvTW12/KKBkFfZ2koav+WJUKbrETbJEy6c/bQTL/eBEdP+RzlByG ZZQNMR08hYFI50+TmO2tN5mpuXnosTflWEClHk33QWg76Y1HDBnVYgr/WGKTz4ac cZcZD5nT3Tk= =19pA -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri Apr 23 19:57:25 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3O2vOaU022833; Fri, 23 Apr 2004 19:57:25 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHDEw-0002YA-Lt; Fri, 23 Apr 2004 22:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHDCg-0001x3-L1 for ipsec@optimus.ietf.org; Fri, 23 Apr 2004 22:47:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00566 for ; Fri, 23 Apr 2004 22:47:38 -0400 (EDT) From: bart@jukie.net Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHDCd-0005N3-5H for ipsec@ietf.org; Fri, 23 Apr 2004 22:47:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHDBl-00057G-00 for ipsec@ietf.org; Fri, 23 Apr 2004 22:46:45 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BHDB8-0004qp-00 for ipsec@ietf.org; Fri, 23 Apr 2004 22:46:06 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3O2jLp28253 for ; Fri, 23 Apr 2004 22:45:21 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3O2hbBu020075 for ; Fri, 23 Apr 2004 22:43:37 -0400 (EDT) Message-Id: <200404240243.i3O2hbBu020075@nutshell.tislabs.com> Received: from unknown(218.94.19.121) by nutshell.tislabs.com via csmap (V6.0) id srcAAAfeayiN; Fri, 23 Apr 04 22:43:22 -0400 To: ipsec@lists.tislabs.com Date: Sat, 24 Apr 2004 10:45:42 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.2 required=5.0 tests=HTML_30_40,HTML_FONTCOLOR_RED, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2,MIME_BOUND_NEXTPART, MISSING_MIMEOLE,MSGID_FROM_MTA_HEADER,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [Ipsec] Re: Failure Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Protected message is available. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/html; name="readme.pif.htm" Content-Disposition: attachment; filename="readme.pif.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: readme.pif
Virus name: W32/Netsky.p@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_0016----=_NextPart_000_0016-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Sat Apr 24 04:25:58 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3OBPvc9040999; Sat, 24 Apr 2004 04:25:57 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHLBZ-0003Zn-A2; Sat, 24 Apr 2004 07:19:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHL8X-0002gI-Oj for ipsec@optimus.ietf.org; Sat, 24 Apr 2004 07:15:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08412 for ; Sat, 24 Apr 2004 07:15:57 -0400 (EDT) From: jpickering@creeksidenet.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHL8X-0001tX-6O for ipsec@ietf.org; Sat, 24 Apr 2004 07:15:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHL7h-0001dn-00 for ipsec@ietf.org; Sat, 24 Apr 2004 07:15:06 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BHL6q-0001Nh-00 for ipsec@ietf.org; Sat, 24 Apr 2004 07:14:12 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3OBDPp29354 for ; Sat, 24 Apr 2004 07:13:25 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3OBBWUV026607 for ; Sat, 24 Apr 2004 07:11:33 -0400 (EDT) Message-Id: <200404241111.i3OBBWUV026607@nutshell.tislabs.com> Received: from ca-marseille-19-195.w80-8.abo.wanadoo.fr(80.8.146.195) by nutshell.tislabs.com via csmap (V6.0) id srcAAA8QaOGZ; Sat, 24 Apr 04 07:10:17 -0400 To: ipsec@lists.tislabs.com Date: Sat, 24 Apr 2004 13:12:45 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_00001840.0000474F" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.1 required=5.0 tests=HTML_30_40,HTML_FONTCOLOR_RED, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2,MISSING_MIMEOLE, MSGID_FROM_MTA_HEADER,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [Ipsec] Re: Your music Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0007_00001840.0000474F Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Your document is attached. ------=_NextPart_000_0007_00001840.0000474F Content-Type: text/html; name="mp3music.pif.htm" Content-Disposition: attachment; filename="mp3music.pif.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: mp3music.pif
Virus name: W32/Netsky.d@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_0007_00001840.0000474F-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Sat Apr 24 08:34:30 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3OFYTtg055070; Sat, 24 Apr 2004 08:34:30 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHP2Y-0007MN-Ax; Sat, 24 Apr 2004 11:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHOxu-0005yW-51 for ipsec@optimus.ietf.org; Sat, 24 Apr 2004 11:21:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19560 for ; Sat, 24 Apr 2004 11:21:07 -0400 (EDT) From: uri@lucent.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHOxk-0003Qx-8W for ipsec@ietf.org; Sat, 24 Apr 2004 11:21:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHOtM-0002vU-00 for ipsec@ietf.org; Sat, 24 Apr 2004 11:16:33 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BHOrf-0002RP-00 for ipsec@ietf.org; Sat, 24 Apr 2004 11:14:47 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3OFE0p13841 for ; Sat, 24 Apr 2004 11:14:00 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3OFCLWJ001607 for ; Sat, 24 Apr 2004 11:12:21 -0400 (EDT) Received: from va-staff-u1-c5f-78.frbgva.adelphia.net(67.21.59.78) by nutshell.tislabs.com via csmap (V6.0) id srcAAA5PaWid; Sat, 24 Apr 04 11:12:17 -0400 Date: Sat, 24 Apr 2004 11:14:42 -0500 To: ipsec@lists.tislabs.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ivhcuktkigfhuhrqcpuk" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.4 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY,NO_REAL_NAME autolearn=no version=2.60 Subject: [Ipsec] Fax Message Received Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , ----------ivhcuktkigfhuhrqcpuk Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit More info in attach


----------ivhcuktkigfhuhrqcpuk Content-Type: text/html; name="Information.pif.htm" Content-Disposition: attachment; filename="Information.pif.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Information.pif
Virus name: W32/Bagle.n@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------ivhcuktkigfhuhrqcpuk-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Sat Apr 24 21:10:46 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3P4Ah2O009528; Sat, 24 Apr 2004 21:10:44 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHaoE-0002kD-N1; Sun, 25 Apr 2004 00:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHamm-0001dV-W6 for ipsec@optimus.ietf.org; Sat, 24 Apr 2004 23:58:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22930 for ; Sat, 24 Apr 2004 23:58:30 -0400 (EDT) From: kseo@bbn.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHamk-0004HI-LX for ipsec@ietf.org; Sat, 24 Apr 2004 23:58:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHall-00042h-00 for ipsec@ietf.org; Sat, 24 Apr 2004 23:57:30 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BHakj-0003dI-00 for ipsec@ietf.org; Sat, 24 Apr 2004 23:56:25 -0400 Received: from po2.bbn.com (po2.bbn.com [128.33.0.56]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i3P3tp7W025843; Sat, 24 Apr 2004 23:55:51 -0400 (EDT) Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by po2.bbn.com (8.10.2+Sun/8.10.2) with ESMTP id i3P3to600516; Sat, 24 Apr 2004 23:55:51 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: <5.2.0.9.0.20040419120357.0205b710@email> References: <5.2.0.9.0.20040419120357.0205b710@email> Date: Sun, 25 Apr 2004 00:02:57 -0400 To: Mark Duffy Subject: [Ipsec] Re: 2401bis -- Issue 91 -- handling ICMP error messages Cc: ipsec@ietf.org, kseo@po2.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.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Hi Mark, My apologies for the delay in replying.... >I have no argument with the proposal to follow the second approach. >But, I don't see why in this case the receiver would need to do any >"special" processing i.e. examining the payload of the icmp packet. >Can you please explain the reason for that? > >If I understand the proposal correctly, the icmp packets will be >sent on an SA that is explicitly negotiated for icmp (and maybe >other stuff). Why shouldn't the receiver just accept the icmp >packets on their own merits? I believe there was a concern that the sender of the ICMP packet could send it to an entity (behind the local IPsec implementation) that could not legitimately have sent the triggering packet contained in the ICMP packet. This could be by error or as a DoS attack. By checking the contents of the ICMP packet, the IPsec implementation can at least ensure that the triggering packet came from an entity on its protected side that has an existing SA that matches the triggering packet. Since this special checking is a local matter, not negotiated, we could make it optional for a vendor who wants to provide additional protection. Would making this additional checking a SHOULD or a MAY address your concern? Thank you, Karen > >Thanks, Mark > >P.S. I marked the paragraph below that I am asking about. > > >At 07:54 PM 4/13/2004 -0400, Karen Seo wrote: >>Folks, >> >>Following up on a discussion at the end of February/early March re: >>how to handle ICMP traffic... We were talking about how to carry >>ICMP traffic via an SA between two IPsec implementations. This did >>NOT involve ICMP traffic that might be bypassed or consumed on the >>ciphertext side of the IPsec boundary. Also, there are two >>categories of ICMP traffic -- error messages (e.g., type = >>destination unreachable) and non-error messages (e.g., type = >>echo). This discussion covered ONLY error messages. Non-error ICMP >>messages should be explicitly accounted for in the SPD. >> >>Two approaches were discussed: >> 1. The sender of ICMP error message uses the (return) SA for the >> packet that resulted in the ICMP error message. In this >> discussion, the SA was assumed to not be configured to >> carry ICMP error messages. >> 2. The sender of ICMP error message uses an SA that is configured >> to handle ICMP error messages of the relevant type and code. >> Note that while this case was viewed in the discussion >> as being a different/separate SA from case 1 above, this SA >> could be the same as case 1, if that SA were configured to >> carry ICMP error taffic (in addition to user traffic). Note >> also that the ICMP Type and Code for this SA could be set to >> ANY, if there is no need to restrict the type of ICMP traffic >> that it is allowed to carry. >> >>Here's what needs to happen at the sender and receiver, to make >>each case work: >> For case 1: >> a. The sender notices that the packet is an ICMP error >> message and diverts it to slow path processing. It >> examines the enclosed packet (or portion thereof), >> swaps the source and destination addresses and >> ports, and performs an SPD lookup to find the SA >> to use. Then the ICMP packet is sent via the >> the selected SA. >> >> b. The receiver notices that a packet has failed the >> selector check (e.g., the source address or the >> protocol does not match). The packet is diverted >> to slow path processing where it is observed to be >> an ICMP error message and the enclosed packet >> is examined. The source and destination addresses >> and ports are swapped and matched against the >> selectors for the SA via which the ICMP packet was >> received. If they match, the ICMP message is passed >> on for further processing, e.g., PMTU check. >> >> This case assumes that no further access control checks >> are desired for the ICMP packet. >> >> For case 2: >> a. The sender extracts ICMP type and code and does an >> SPD lookup to find an appropriate SA. (The Sender >> only does fast path processing.) >> b. The receiver processes the ICMP packet on the SA >> via which it was received, verifying that the ICMP >> type and code of the message match the selectors >> for the SA. > >[md] Why check the icmp payload as stated below? And what does it >mean for the enclosed packet to be "consistent with its source"? > >> If they do, then the receiver passes >> the ICMP message to slow path processing. The >> selectors of the enclosed packet are extracted >> and matched against the SPD-S cache, to ensure >> that the enclosed packet is consistent with its >> source. If they do, the ICMP message is passed >> along for further processing, e.g., PMTU check. >> (The receiver does both fast path and slow path >> processing.) >> >> Note that an ICMP packet may arrive on an SA unrelated >> to the SA used for the triggering packet. The sender >> will use the first SPD or SPD-S cache entry that it >> comes to that is configured to carry ICMP traffic of >> the given type and code. Even if the SA for the >> triggering packet is configured to carry ICMP traffic, >> there may be an earlier entry in the SPD that matches >> the ICMP message's type and code. So one has >> to search the outbound SPD-S cache to verify whether >> or not there's an extant SA for the enclosed >> (triggering) packet. >> >>Proposed approach >> To simplify the processing done by the Sender (of the ICMP >> message) to find the SA to use for sending the ICMP message >> and to support access control checks on the ICMP messages >> (using ICMP Message Type and Code) by the Receiver, >> we propose to use the second approach. >> >> Note: In the second approach, there is no requirement that >> the SA used for the ICMP message be dedicated only to ICMP >> messages. To minimize the number of SAs between two IPsec >> systems, an administrator may wish to configure the SPD such >> that the ICMP messages may be combined with other traffic, >> i.e., by specifying SPD entries that carry both normal >> traffic and ICMP traffic. >> >>Comments? Thank you, >>Karen > > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Sat Apr 24 21:26:41 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3P4Qdc0010306; Sat, 24 Apr 2004 21:26:39 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHb3i-00005Q-Lt; Sun, 25 Apr 2004 00:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHava-0004xH-7p for ipsec@optimus.ietf.org; Sun, 25 Apr 2004 00:07:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23349 for ; Sun, 25 Apr 2004 00:07:34 -0400 (EDT) From: kseo@bbn.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHavX-0006Yl-Il for ipsec@ietf.org; Sun, 25 Apr 2004 00:07:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHauf-0006KV-00 for ipsec@ietf.org; Sun, 25 Apr 2004 00:06:41 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BHau3-00064g-00 for ipsec@ietf.org; Sun, 25 Apr 2004 00:06:03 -0400 Received: from po2.bbn.com (po2.bbn.com [128.33.0.56]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i3P45Y7W026057 for ; Sun, 25 Apr 2004 00:05:34 -0400 (EDT) Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by po2.bbn.com (8.10.2+Sun/8.10.2) with ESMTP id i3P45X601242; Sun, 25 Apr 2004 00:05:33 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Sun, 25 Apr 2004 00:12:40 -0400 To: ipsec@ietf.org Cc: kseo@po2.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.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Subject: [Ipsec] IPsec AH and ESP -- changes Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Folks, We would like to make the following changes to the AH and ESP specs... Comments and questions are requested by 5/5/04. Thank you, Karen 1. ESP -- Thanks go to Abhijit Choudhury for catching a discrepancy in ESP. Several versions ago of ESPv2, we removed the default padding algorithm from Section 2.4 of RFC 2406, but inadvertently left in a sentence in Section 3.4.4.1 that refers to the default algorithm. Also, Tero Kivinen pointed out that a number of the ESP algorithm specs refer to this default padding. So we propose to put the original text back as follows (The ESPv2 padding text (Section 2.4) will otherwise remain unchanged.): "If Padding bytes are needed but the encryption algorithm does not specify the padding contents, then the following default processing MUST be used. The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... When this padding scheme is employed, the receiver SHOULD inspect the Padding field. (This scheme was selected because of its relative simplicity, ease of implementation in hardware, and because it offers limited protection against certain forms of "cut and paste" attacks in the absence of other integrity measures, if the receiver checks the padding values upon decryption.)" 2. AH and ESP (and 2401bis)-- Thanks go to Suman Sharma and George Gross for their input re: SAD entry lookup for inbound traffic in the presence of multicast SAs. Also, thanks go to George for draft text. We propose to replace the current text re: multicast lookup in o AH Section 2.4 "Security Parameters Index (SPI)", paragraph 2 o ESP Section 2.1 "Security Parameters Index (SPI)", paragraph 2 with the following text: "If an IPsec implementation supports multicast, then it MUST support multicast SAs using the algorithm below for mapping inbound IPsec datagrams to SAs. Implementations that support only unicast traffic need not implement this demultiplexing algorithm. In many secure multicast architectures, e.g., [RFC3740], a central Group Controller/Key Server unilaterally assigns the group security association's SPI. This SPI assignment is not negotiated or coordinated with the key management (e.g., IKE) subsystems that reside in the individual end systems that compromise the group. Consequently, it is possible that a group security association and a unicast security association can simultaneously use the same SPI. A multicast-capable IPsec implementation MUST correctly de-multiplex inbound traffic even in the context of SPI collisions. Each entry in the Security Association Database (SAD) [Ken-Arch] must indicate whether the SA lookup makes use of the destination, or destination and source, IP addresses, in addition to the SPI. For multicast SAs, the protocol field is not employed for SA lookups. For each inbound, IPsec-protected packet, an implementation must conduct its search of the SAD such that it finds the entry that matches the "longest" SA identifier. In this context, if two or more SAD entries match based on the SPI value, then the entry that also matches based on destination, or destination and source, address comparison (as indicated in the SAD entry) is the "longest" match. This implies a logical ordering of the SAD search as follows: 1. Search the SAD for a match on {SPI, destination multicast address, source address}. If a SAD entry matches then process the inbound ESP packet with that matching SAD entry. Otherwise, proceed to step 2. 2. Search the SAD for a match on {SPI, destination multicast address}. If the SAD entry matches then process the inbound ESP packet with that matching SAD entry. Otherwise, proceed to step 3. 3. Search the SAD for a match on only {SPI}. If an SAD entry matches then process the inbound ESP packet with that matching SAD entry. Otherwise, discard the packet and log an auditable event. In practice, an implementation MAY choose any method to accelerate this search, although its externally visible behavior MUST be functionally equivalent to having searched the SAD in the above order. For example, a software-based implementation could index into a hash table by the SPI. The SAD entries in each hash table bucket's linked list are kept sorted to have those SAD entries with the longest SA identifiers first in that linked list. Those SAD entries having the shortest SA identifiers are sorted so that they are the last entries in the linked list. A hardware-based implementation may be able to effect the longest match search intrinsically, using commonly available TCAM features. The indication of whether source and destination address matching is required to map inbound IPsec traffic to SAs MUST be set either as a side effect of manual SA configuration or via negotiation using an SA management protocol, e.g., IKE or GDOI [RFC3547]. Typically, Source-Specific Multicast (SSM) [HC03] groups use a 3-tuple SA identifier composed of an SPI, a destination multicast address, and source address. An Any-Source Multicast group SA requires only an SPI and a destination multicast address as an identifier. References will be updated with: [RFC3547] Baugher, M., Weis, B., Hardjono, T., Harney, H., "The Group Domain of Interpretation", RFC 3547, July 2003. [RFC3740] Hardjono, T., Weis, B., "The Multicast Group Security Architecture", RFC 3740, March 2004. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Sun Apr 25 09:21:14 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3PGLCCd035044; Sun, 25 Apr 2004 09:21:13 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHmFa-0001UW-8A; Sun, 25 Apr 2004 12:13:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHm6w-0006Ot-1o for ipsec@optimus.ietf.org; Sun, 25 Apr 2004 12:04:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03752 for ; Sun, 25 Apr 2004 12:04:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHm6u-0006SD-L6 for ipsec@ietf.org; Sun, 25 Apr 2004 12:04:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHm5w-0006GO-00 for ipsec@ietf.org; Sun, 25 Apr 2004 12:03:05 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BHm5Z-00064q-00 for ipsec@ietf.org; Sun, 25 Apr 2004 12:02:42 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3PG1pp02844 for ; Sun, 25 Apr 2004 12:01:51 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3PG0Dos022472 for ; Sun, 25 Apr 2004 12:00:13 -0400 (EDT) Received: from oetest.freeswan.org(205.150.200.166) by nutshell.tislabs.com via csmap (V6.0) id srcAAAJ_aq3R; Sun, 25 Apr 04 12:00:11 -0400 Received: from sandelman.ottawa.on.ca (wlan237.sandelman.ca [205.150.200.237]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i3PG2OP27995 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Sun, 25 Apr 2004 12:02:24 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3PG2MsG030651 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 25 Apr 2004 12:02:23 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3PG2MRX030648; Sun, 25 Apr 2004 12:02:22 -0400 To: "William Dixon" cc: ipsec@lists.tislabs.com Subject: Re: [Ipsec] Specification of BGP IPsec policy In-Reply-To: Message from "William Dixon" of "Fri, 23 Apr 2004 16:49:27 EDT." <200404232050.i3NKo1cR015728@rs9.luxsci.com> References: <200404232050.i3NKo1cR015728@rs9.luxsci.com> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Sun, 25 Apr 2004 12:02:22 -0400 Message-ID: <30647.1082908942@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , -----BEGIN PGP SIGNED MESSAGE----- >>>>> "William" == William Dixon writes: William> There are many ISPs with hundreds and perhaps thousands of William> BGP peering partners. So I respectfully disagree that a William> recommendation is not needed. I'm guessing this is the Okay, let's start at the top. which authentication mechanism scales to thousands of BGP peering partners? and if you say X.509, then please let us know which CA to buy. - -- ] 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 iQCVAwUBQIvhDIqHRg3pndX9AQGnUQQAmXkD67JTLRWMSm4dU4iCIoC/YzhUU6eL YTKwLU5ALjbZkUpn+GdGme4nSIXdBF1qfJXqECsovkt1HNvvkmXkESnj/5eTWL+m bkPIqwX/Emzxz0Gf7Sh3/npCnLrtK7wntYtPs55gqdenXoTVhBi6JLtyDlZAWPbU VUgHJD6Ag7s= =lJze -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Sun Apr 25 09:52:01 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3PGq01M037343; Sun, 25 Apr 2004 09:52:00 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHmmT-0003i7-Ns; Sun, 25 Apr 2004 12:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHmgk-0001wf-Rc for ipsec@optimus.ietf.org; Sun, 25 Apr 2004 12:41:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04947 for ; Sun, 25 Apr 2004 12:41:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHmgj-0006M4-5K for ipsec@ietf.org; Sun, 25 Apr 2004 12:41:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHmfs-0006AA-00 for ipsec@ietf.org; Sun, 25 Apr 2004 12:40:12 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BHmfA-0005yG-00 for ipsec@ietf.org; Sun, 25 Apr 2004 12:39:28 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3PGcap04584 for ; Sun, 25 Apr 2004 12:38:36 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3PGavmQ026274 for ; Sun, 25 Apr 2004 12:36:57 -0400 (EDT) Received: from above.proper.com(208.184.76.39) by nutshell.tislabs.com via csmap (V6.0) id srcAAA4eaqtZ; Sun, 25 Apr 04 12:36:55 -0400 Received: from [63.202.92.148] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3PGdFQa036295 for ; Sun, 25 Apr 2004 09:39:16 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <30647.1082908942@marajade.sandelman.ottawa.on.ca> References: <200404232050.i3NKo1cR015728@rs9.luxsci.com> <30647.1082908942@marajade.sandelman.ottawa.on.ca> Date: Sun, 25 Apr 2004 09:39:18 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: [Ipsec] Specification of BGP IPsec policy Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , At 12:02 PM -0400 4/25/04, Michael Richardson wrote: > >>>>> "William" == William Dixon writes: > William> There are many ISPs with hundreds and perhaps thousands of > William> BGP peering partners. So I respectfully disagree that a > William> recommendation is not needed. I'm guessing this is the > > Okay, let's start at the top. > > which authentication mechanism scales to thousands of BGP peering >partners? and if you say X.509, then please let us know which CA to buy. One doesn't need to "buy" CAs; for example, there is SimpleCA from the VPN Consortium which is freeware (see ). Other freeware CAs exist as well. The problem is not in issuing the certs, it is in getting the authorization policies into the IPsec systems. Some IPsec implementations have a "accept anyone who has a cert issued by this particular CA into this this policy" setting, but many don't. In the latter case, you need to create a policy for each partner based on the exact contents of some field in the cert, which makes using certs much more of a hassle. These topics are being discussed (not terribly actively) in the PKI4IPSEC WG. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Sun Apr 25 10:25:29 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3PHPSX7040988; Sun, 25 Apr 2004 10:25:29 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHnHR-0005nA-SZ; Sun, 25 Apr 2004 13:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHnFe-0005Co-LT for ipsec@optimus.ietf.org; Sun, 25 Apr 2004 13:17:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06186 for ; Sun, 25 Apr 2004 13:17:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHnFc-0005zA-Nr for ipsec@ietf.org; Sun, 25 Apr 2004 13:17:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHnEo-0005mC-00 for ipsec@ietf.org; Sun, 25 Apr 2004 13:16:19 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BHnDw-0005Wd-00 for ipsec@ietf.org; Sun, 25 Apr 2004 13:15:25 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3PHEVp06415 for ; Sun, 25 Apr 2004 13:14:31 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3PHCqKY000354 for ; Sun, 25 Apr 2004 13:12:52 -0400 (EDT) Received: from rs9.luxsci.com(66.216.98.59) by nutshell.tislabs.com via csmap (V6.0) id srcAAA9haqQa; Sun, 25 Apr 04 13:12:45 -0400 Received: from rs9.luxsci.com (localhost [127.0.0.1]) by rs9.luxsci.com (8.12.11/8.12.10) with ESMTP id i3PHF9g8013445 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sun, 25 Apr 2004 12:15:10 -0500 Received: (from root@localhost) by rs9.luxsci.com (8.12.11/8.12.10/Submit) id i3PHC28c013055; Sun, 25 Apr 2004 17:12:02 GMT Message-Id: <200404251712.i3PHC28c013055@rs9.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Sun, 25 Apr 2004 17:12:02 +0000 From: "William Dixon" To: "'Michael Richardson'" Cc: Subject: RE: [Ipsec] Specification of BGP IPsec policy Date: Sun, 25 Apr 2004 13:10:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <30647.1082908942@marajade.sandelman.ottawa.on.ca> X-Lux-Comment: LuxSci remailer message ID code - 1082913122-2961902.81888389 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , I don't argue that the deployability of an authentication scheme is difficult. However, the recommended BGP over TCP-MD5 auth uses a "password" between peers - no worse of an authentication deployment issue than IKE with pre-shared key. This post was originally just to find the config guidance from those who were using IPsec to secure BGP, as it was one of several recommended practices, me figuring someone on the IPsec list was involved in this latest BGP security alert/response. In any case, the lack of any specific guidance and finding Dave Ward's draft is what I was looking for. Apparently Dave is reviewing the BGP community's interest in using IPsec vs. other mechanisms and no further help is needed right now. Though I'm sure he'll appreciate comments on his draft. Thanks, Wm > -----Original Message----- > From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org] On > Behalf Of Michael Richardson > Sent: Sunday, April 25, 2004 12:02 PM > To: William Dixon > Cc: ipsec@lists.tislabs.com > Subject: Re: [Ipsec] Specification of BGP IPsec policy > > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "William" == William Dixon writes: > William> There are many ISPs with hundreds and perhaps > thousands of > William> BGP peering partners. So I respectfully disagree that a > William> recommendation is not needed. I'm guessing this is the > > Okay, let's start at the top. > > which authentication mechanism scales to thousands of BGP > peering partners? and if you say X.509, then please let us > know which CA to buy. > > - -- > ] 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 > > iQCVAwUBQIvhDIqHRg3pndX9AQGnUQQAmXkD67JTLRWMSm4dU4iCIoC/YzhUU6eL > YTKwLU5ALjbZkUpn+GdGme4nSIXdBF1qfJXqECsovkt1HNvvkmXkESnj/5eTWL+m > bkPIqwX/Emzxz0Gf7Sh3/npCnLrtK7wntYtPs55gqdenXoTVhBi6JLtyDlZAWPbU > VUgHJD6Ag7s= > =lJze > -----END PGP SIGNATURE----- > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Sun Apr 25 16:13:12 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3PNDA9A069024; Sun, 25 Apr 2004 16:13:10 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHsfK-0002Bc-IH; Sun, 25 Apr 2004 19:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHsXz-0007yG-BJ for ipsec@optimus.ietf.org; Sun, 25 Apr 2004 18:56:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22662 for ; Sun, 25 Apr 2004 18:56:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHsXw-0005OW-4e for ipsec@ietf.org; Sun, 25 Apr 2004 18:56:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHsWy-0005DD-00 for ipsec@ietf.org; Sun, 25 Apr 2004 18:55:24 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BHsWP-000520-00 for ipsec@ietf.org; Sun, 25 Apr 2004 18:54:50 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3PMs0p24277 for ; Sun, 25 Apr 2004 18:54:01 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3PMqH5N011035 for ; Sun, 25 Apr 2004 18:52:17 -0400 (EDT) Received: from oetest.freeswan.org(205.150.200.166) by nutshell.tislabs.com via csmap (V6.0) id srcAAA0iaWIv; Sun, 25 Apr 04 18:52:15 -0400 Received: from sandelman.ottawa.on.ca (wlan237.sandelman.ca [205.150.200.237]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i3PMsQP00759 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Sun, 25 Apr 2004 18:54:26 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3PMsQsG013128 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 25 Apr 2004 18:54:26 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3PMsPR2013125; Sun, 25 Apr 2004 18:54:25 -0400 To: "William Dixon" cc: ipsec@lists.tislabs.com Subject: Re: [Ipsec] Specification of BGP IPsec policy In-Reply-To: Message from "William Dixon" of "Sun, 25 Apr 2004 13:10:26 EDT." <200404251712.i3PHC28c013055@rs9.luxsci.com> References: <200404251712.i3PHC28c013055@rs9.luxsci.com> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Sun, 25 Apr 2004 18:54:25 -0400 Message-ID: <13123.1082933665@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , -----BEGIN PGP SIGNED MESSAGE----- >>>>> "William" == William Dixon writes: William> I don't argue that the deployability of an authentication William> scheme is difficult. However, the recommended BGP over William> TCP-MD5 auth uses a "password" between peers - no worse of William> an authentication deployment issue than IKE with pre-shared William> key. That's right. Also, no better. (Note that we must recommend against using manually keyed IPsec connections due to lack of replay protection, and the length that the keys would be used) So, PSK must be communicated bilaterally, so once they are on the phone, they can come to any agreement they like about other parameters. William> one of several recommended practices, me figuring someone William> on the IPsec list was involved in this latest BGP security William> alert/response. I am. As an IPsec person. As a person who runs a small co-lo which does multihop BGP. I also saw the CanSecWest presentation, and the Cisco "response". - -- ] 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 iQCVAwUBQIxBn4qHRg3pndX9AQH+4wQArmOW/Rx4bXPY/1HJGbTM9JVyogHr1z/2 0ETPLUAvJWLag75JcyPrLIhuuxyxZn7v372a7Ge+ttqFKw3xdkRIs3t6+liAapxY BKlgZXBlPJTYrJLYGKIrxleUuDcjkyNbPmQaXg+1FgKdns5HtcI0Mt+O52YdvPDb 2MZHE1cqLdI= =vnqA -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Sun Apr 25 17:50:31 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3Q0oUWZ077651; Sun, 25 Apr 2004 17:50:30 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHuE5-0006qP-TZ; Sun, 25 Apr 2004 20:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHuAg-0005hz-8Q for ipsec@optimus.ietf.org; Sun, 25 Apr 2004 20:40:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26678 for ; Sun, 25 Apr 2004 20:40:27 -0400 (EDT) From: kseo@bbn.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHuAd-0002kX-Sd for ipsec@ietf.org; Sun, 25 Apr 2004 20:40:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHu9j-0002ZD-00 for ipsec@ietf.org; Sun, 25 Apr 2004 20:39:32 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BHu9P-0002N1-00 for ipsec@ietf.org; Sun, 25 Apr 2004 20:39:11 -0400 Received: from po2.bbn.com (po2.bbn.com [128.33.0.56]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i3Q0cb7W017179 for ; Sun, 25 Apr 2004 20:38:37 -0400 (EDT) Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by po2.bbn.com (8.10.2+Sun/8.10.2) with ESMTP id i3Q0ca624812; Sun, 25 Apr 2004 20:38:36 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Sun, 25 Apr 2004 20:45:42 -0400 To: ipsec@ietf.org Cc: kseo@po2.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.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Subject: [Ipsec] Correction re: IPsec AH and ESP -- changes Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Re: lookup in the presence of multicast SAs... Thanks go to Miles Nordin for catching the following error. Paragraph 2, 2nd sentence "This SPI assignment is not negotiated or coordinated with the key management (e.g., IKE) subsystems that reside in the individual end systems that compromise the group" "compromise" should be "comprise". Sorry about this. I must have been asleep ... _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon Apr 26 02:09:51 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3Q99oJO098403; Mon, 26 Apr 2004 02:09:50 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1z3-0005bk-QH; Mon, 26 Apr 2004 05:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1tz-0004KA-MQ for ipsec@optimus.ietf.org; Mon, 26 Apr 2004 04:55:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05004 for ; Mon, 26 Apr 2004 04:55:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI1tw-0002i3-Jd for ipsec@ietf.org; Mon, 26 Apr 2004 04:55:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI1sz-0002VO-00 for ipsec@ietf.org; Mon, 26 Apr 2004 04:54:46 -0400 Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BI1s1-0002Gs-00 for ipsec@ietf.org; Mon, 26 Apr 2004 04:53:45 -0400 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-3) with ESMTP id i3Q8rUNG003096; Mon, 26 Apr 2004 11:53:30 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-3) id i3Q8rTou003093; Mon, 26 Apr 2004 11:53:29 +0300 Date: Mon, 26 Apr 2004 11:53:29 +0300 Message-Id: <200404260853.i3Q8rTou003093@burp.tkv.asdf.org> From: Markku Savela To: kseo@bbn.com CC: ipsec@ietf.org, kseo@po2.bbn.com In-reply-to: (kseo@bbn.com) Subject: Re: [Ipsec] IPsec AH and ESP -- changes References: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , I'm wondering about one minor detail in the changed text... > From: kseo@bbn.com > 2. AH and ESP (and 2401bis)-- Thanks go to Suman Sharma and George > Gross for their input re: SAD entry lookup for inbound traffic in the > presence of multicast SAs. Also, thanks go to George for draft text. > We propose to replace the current text re: multicast lookup in > o AH Section 2.4 "Security Parameters Index (SPI)", paragraph 2 > o ESP Section 2.1 "Security Parameters Index (SPI)", paragraph 2 > > with the following text: > > "If an IPsec implementation supports multicast, then it MUST > support multicast SAs using the algorithm below for mapping > inbound IPsec datagrams to SAs. Implementations that support > only unicast traffic need not implement this demultiplexing > algorithm. > > In many secure multicast architectures, e.g., [RFC3740], a > central Group Controller/Key Server unilaterally assigns the > group security association's SPI. This SPI assignment is not > negotiated or coordinated with the key management (e.g., IKE) > subsystems that reside in the individual end systems that > compromise the group. Consequently, it is possible that a > group security association and a unicast security association > can simultaneously use the same SPI. A multicast-capable IPsec > implementation MUST correctly de-multiplex inbound traffic > even in the context of SPI collisions. > > Each entry in the Security Association Database (SAD) > [Ken-Arch] must indicate whether the SA lookup makes use of > the destination, or destination and source, IP addresses, in > addition to the SPI. For multicast SAs, the protocol field is > not employed for SA lookups. .... Why is protocol not employed? Protocol is either AH or ESP, and that has always been a part of the SA identification. Why make an unnecessary special case for multicast SA here? Or, did I misunderstood something? _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon Apr 26 02:47:55 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3Q9lr5O007668; Mon, 26 Apr 2004 02:47:54 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI2Zr-0006WW-Nx; Mon, 26 Apr 2004 05:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI2Wh-0005Hv-P7 for ipsec@optimus.ietf.org; Mon, 26 Apr 2004 05:35:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07055 for ; Mon, 26 Apr 2004 05:35:43 -0400 (EDT) From: kent@bbn.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI2We-0003ZX-9y for ipsec@ietf.org; Mon, 26 Apr 2004 05:35:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI2Ve-0003Nv-00 for ipsec@ietf.org; Mon, 26 Apr 2004 05:34:43 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BI2Ui-0003C3-00 for ipsec@ietf.org; Mon, 26 Apr 2004 05:33:44 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3Q9Wup14339 for ; Mon, 26 Apr 2004 05:32:56 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3Q9VDHQ001899 for ; Mon, 26 Apr 2004 05:31:14 -0400 (EDT) Message-Id: <200404260931.i3Q9VDHQ001899@nutshell.tislabs.com> Received: from unknown(218.72.23.155) by nutshell.tislabs.com via csmap (V6.0) id srcAAAWfaWrd; Mon, 26 Apr 04 05:30:00 -0400 To: ipsec@lists.tislabs.com Date: Mon, 26 Apr 2004 17:31:17 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.2 required=5.0 tests=HTML_30_40,HTML_FONTCOLOR_RED, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2,MIME_BOUND_NEXTPART, MISSING_MIMEOLE,MSGID_FROM_MTA_HEADER,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [Ipsec] Re: my data Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit See the file. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/html; name="data.pif.htm" Content-Disposition: attachment; filename="data.pif.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: data.pif
Virus name: W32/Netsky.p@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_0016----=_NextPart_000_0016-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon Apr 26 10:47:12 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QHlAws050861; Mon, 26 Apr 2004 10:47:11 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9wf-0008Mg-G6; Mon, 26 Apr 2004 13:31:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9nx-0005JI-Pp for ipsec@optimus.ietf.org; Mon, 26 Apr 2004 13:22:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04199 for ; Mon, 26 Apr 2004 13:22:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI9nv-0007Xh-St for ipsec@ietf.org; Mon, 26 Apr 2004 13:22:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9mx-0007U3-00 for ipsec@ietf.org; Mon, 26 Apr 2004 13:21:04 -0400 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx with esmtp (Exim 4.12) id 1BI9m6-0007Mi-00 for ipsec@ietf.org; Mon, 26 Apr 2004 13:20:10 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.181]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XT41K1DG; Mon, 26 Apr 2004 13:19:39 -0400 Message-Id: <5.2.0.9.0.20040426124209.020d5968@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 26 Apr 2004 13:19:29 -0400 To: kseo@bbn.com From: Mark Duffy Subject: Re: [Ipsec] Re: 2401bis -- Issue 91 -- handling ICMP error messages Cc: ipsec@ietf.org, kseo@po2.bbn.com In-Reply-To: References: <5.2.0.9.0.20040419120357.0205b710@email> <5.2.0.9.0.20040419120357.0205b710@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , At 12:02 AM 4/25/2004 -0400, kseo@bbn.com wrote: >Hi Mark, > >My apologies for the delay in replying.... > >>I have no argument with the proposal to follow the second approach. But, >>I don't see why in this case the receiver would need to do any "special" >>processing i.e. examining the payload of the icmp packet. Can you please >>explain the reason for that? >> >>If I understand the proposal correctly, the icmp packets will be sent on >>an SA that is explicitly negotiated for icmp (and maybe other >>stuff). Why shouldn't the receiver just accept the icmp packets on their >>own merits? > > I believe there was a concern that the sender of the ICMP > packet could send it to an entity (behind the local IPsec > implementation) that could not legitimately have sent > the triggering packet contained in the ICMP packet. This > could be by error or as a DoS attack. By checking the > contents of the ICMP packet, the IPsec implementation can > at least ensure that the triggering packet came from > an entity on its protected side that has an existing SA > that matches the triggering packet. Since this special > checking is a local matter, not negotiated, we could make > it optional for a vendor who wants to provide additional > protection. Would making this additional checking a SHOULD > or a MAY address your concern? > >Thank you, >Karen Hi Karen, I understand how, as you describe, this processing of icmp error messages might protect against certain DOS attacks. But it seems to me to be overzealous in your approach #2. In your approach #1 the icmp error message is being sent on an SA pair implied by the enclosed packet in the icmp payload. In that case I think it makes perfect sense for both IPsec devices to evaluate the SPD policy for that enclosed packet. But in #2 the icmp error message is being sent on an SA negotiated for protocol=icmp, type= and code=. It seems to me to be an impropriety for the IPsec implementation to check the enclosed packet. This would be checking that goes beyond the negotiated selectors -- AFAIK there is no other comparable thing done elsewhere in IPsec. Should an IPsec implementation also check for invalid combinations of control bits in a tcp header? Or for packets with src addr == dest addr? These are also checks that could protect against attacks but they oughtn't IMO to be part of the *IPsec* processing. --Mark P.S. Comments on the wording: - Regardless of what behavior is chosen, it would be better if the text does not describe a fast path and a slow path, and what is done in each. I don't think there is anything gained by including such implementation assumptions. - The phrase "to ensure that the enclosed packet is consistent with its source" could use some elaboration. >>Thanks, Mark >> >>P.S. I marked the paragraph below that I am asking about. >> >> >>At 07:54 PM 4/13/2004 -0400, Karen Seo wrote: >>>Folks, >>> >>>Following up on a discussion at the end of February/early March re: how >>>to handle ICMP traffic... We were talking about how to carry ICMP >>>traffic via an SA between two IPsec implementations. This did NOT >>>involve ICMP traffic that might be bypassed or consumed on the >>>ciphertext side of the IPsec boundary. Also, there are two categories >>>of ICMP traffic -- error messages (e.g., type = destination unreachable) >>>and non-error messages (e.g., type = echo). This discussion covered ONLY >>>error messages. Non-error ICMP messages should be explicitly accounted >>>for in the SPD. >>> >>>Two approaches were discussed: >>> 1. The sender of ICMP error message uses the (return) SA for the >>> packet that resulted in the ICMP error message. In this >>> discussion, the SA was assumed to not be configured to >>> carry ICMP error messages. >>> 2. The sender of ICMP error message uses an SA that is configured >>> to handle ICMP error messages of the relevant type and code. >>> Note that while this case was viewed in the discussion >>> as being a different/separate SA from case 1 above, this SA >>> could be the same as case 1, if that SA were configured to >>> carry ICMP error taffic (in addition to user traffic). Note >>> also that the ICMP Type and Code for this SA could be set to >>> ANY, if there is no need to restrict the type of ICMP traffic >>> that it is allowed to carry. >>> >>>Here's what needs to happen at the sender and receiver, to make each >>>case work: >>> For case 1: >>> a. The sender notices that the packet is an ICMP error >>> message and diverts it to slow path processing. It >>> examines the enclosed packet (or portion thereof), >>> swaps the source and destination addresses and >>> ports, and performs an SPD lookup to find the SA >>> to use. Then the ICMP packet is sent via the >>> the selected SA. >>> >>> b. The receiver notices that a packet has failed the >>> selector check (e.g., the source address or the >>> protocol does not match). The packet is diverted >>> to slow path processing where it is observed to be >>> an ICMP error message and the enclosed packet >>> is examined. The source and destination addresses >>> and ports are swapped and matched against the >>> selectors for the SA via which the ICMP packet was >>> received. If they match, the ICMP message is passed >>> on for further processing, e.g., PMTU check. >>> >>> This case assumes that no further access control checks >>> are desired for the ICMP packet. >>> >>> For case 2: >>> a. The sender extracts ICMP type and code and does an >>> SPD lookup to find an appropriate SA. (The Sender >>> only does fast path processing.) >>> b. The receiver processes the ICMP packet on the SA >>> via which it was received, verifying that the ICMP >>> type and code of the message match the selectors >>> for the SA. >> >>[md] Why check the icmp payload as stated below? And what does it mean >>for the enclosed packet to be "consistent with its source"? >> >>> If they do, then the receiver passes >>> the ICMP message to slow path processing. The >>> selectors of the enclosed packet are extracted >>> and matched against the SPD-S cache, to ensure >>> that the enclosed packet is consistent with its >>> source. If they do, the ICMP message is passed >>> along for further processing, e.g., PMTU check. >>> (The receiver does both fast path and slow path >>> processing.) >>> >>> Note that an ICMP packet may arrive on an SA unrelated >>> to the SA used for the triggering packet. The sender >>> will use the first SPD or SPD-S cache entry that it >>> comes to that is configured to carry ICMP traffic of >>> the given type and code. Even if the SA for the >>> triggering packet is configured to carry ICMP traffic, >>> there may be an earlier entry in the SPD that matches >>> the ICMP message's type and code. So one has >>> to search the outbound SPD-S cache to verify whether >>> or not there's an extant SA for the enclosed >>> (triggering) packet. >>> >>>Proposed approach >>> To simplify the processing done by the Sender (of the ICMP >>> message) to find the SA to use for sending the ICMP message >>> and to support access control checks on the ICMP messages >>> (using ICMP Message Type and Code) by the Receiver, >>> we propose to use the second approach. >>> >>> Note: In the second approach, there is no requirement that >>> the SA used for the ICMP message be dedicated only to ICMP >>> messages. To minimize the number of SAs between two IPsec >>> systems, an administrator may wish to configure the SPD such >>> that the ICMP messages may be combined with other traffic, >>> i.e., by specifying SPD entries that carry both normal >>> traffic and ICMP traffic. >>> >>>Comments? Thank you, >>>Karen _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon Apr 26 11:44:00 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QIhwrg055749; Mon, 26 Apr 2004 11:43:59 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAvZ-0006K8-KL; Mon, 26 Apr 2004 14:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAms-0003tF-Kt for ipsec@optimus.ietf.org; Mon, 26 Apr 2004 14:25:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07878 for ; Mon, 26 Apr 2004 14:24:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIAmq-0004hB-2u for ipsec@ietf.org; Mon, 26 Apr 2004 14:25:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIAls-0004be-00 for ipsec@ietf.org; Mon, 26 Apr 2004 14:24:00 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BIAkt-0004Ni-00 for ipsec@ietf.org; Mon, 26 Apr 2004 14:22:59 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2004 10:35:13 +0000 Received: from cisco.com ([128.107.177.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3QIMHW9013929; Mon, 26 Apr 2004 11:22:22 -0700 (PDT) Message-ID: <408D53B3.6040405@cisco.com> Date: Mon, 26 Apr 2004 11:23:47 -0700 From: Brian Weis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markku Savela CC: kseo@bbn.com, ipsec@ietf.org Subject: Re: [Ipsec] IPsec AH and ESP -- changes References: <200404260853.i3Q8rTou003093@burp.tkv.asdf.org> In-Reply-To: <200404260853.i3Q8rTou003093@burp.tkv.asdf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-from-outside-Cisco-experimental-header: [128.107.177.14] X-PMX-Version: 4.5.0.92886 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Markku Savela wrote: >I'm wondering about one minor detail in the changed text... > > > >>From: kseo@bbn.com >> >> > > > >>2. AH and ESP (and 2401bis)-- Thanks go to Suman Sharma and George >>Gross for their input re: SAD entry lookup for inbound traffic in the >>presence of multicast SAs. Also, thanks go to George for draft text. >>We propose to replace the current text re: multicast lookup in >> o AH Section 2.4 "Security Parameters Index (SPI)", paragraph 2 >> o ESP Section 2.1 "Security Parameters Index (SPI)", paragraph 2 >> >>with the following text: >> >> "If an IPsec implementation supports multicast, then it MUST >> support multicast SAs using the algorithm below for mapping >> inbound IPsec datagrams to SAs. Implementations that support >> only unicast traffic need not implement this demultiplexing >> algorithm. >> >> In many secure multicast architectures, e.g., [RFC3740], a >> central Group Controller/Key Server unilaterally assigns the >> group security association's SPI. This SPI assignment is not >> negotiated or coordinated with the key management (e.g., IKE) >> subsystems that reside in the individual end systems that >> compromise the group. Consequently, it is possible that a >> group security association and a unicast security association >> can simultaneously use the same SPI. A multicast-capable IPsec >> implementation MUST correctly de-multiplex inbound traffic >> even in the context of SPI collisions. >> >> Each entry in the Security Association Database (SAD) >> [Ken-Arch] must indicate whether the SA lookup makes use of >> the destination, or destination and source, IP addresses, in >> addition to the SPI. For multicast SAs, the protocol field is >> not employed for SA lookups. .... >> >> > >Why is protocol not employed? Protocol is either AH or ESP, and that >has always been a part of the SA identification. Why make an >unnecessary special case for multicast SA here? > > From my recollection, the rationale was that a single key server would likely be choosing SPIs for a single {source addr, destination addr} pair. That key server could probably be trusted to not choose the same SPI for both an AH and ESP SA matching that flow. Therefore keeping the protocol in the SA lookup was seen as unnecessary. You're right though, it does special case the SA lookup logic. If the protocol were optionally included in the multicast SA lookup as well as the unicast SA lookup, the semantics would be consistent. This might simplify the implementation of an SA lookup. I.e., unicast: {SPI, [protocol]} ASM multicast: {SPI, destination, [protocol]} SSM multicast: {SPI, destination, source, [protocol]} With today's drafts, we have: unicast: {SPI, [protocol]} ASM multicast: {SPI, destination} SSM multicast: {SPI, destination, source} Brian >Or, did I misunderstood something? > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec > > > -- Brian Weis Advanced Security Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Mon Apr 26 11:57:42 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3QIva96056801; Mon, 26 Apr 2004 11:57:41 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIB8A-0001C5-VA; Mon, 26 Apr 2004 14:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIAzT-0007Up-8z for ipsec@optimus.ietf.org; Mon, 26 Apr 2004 14:38:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08893 for ; Mon, 26 Apr 2004 14:37:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIAzQ-0005lH-ED for ipsec@ietf.org; Mon, 26 Apr 2004 14:38:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIAyT-0005i6-00 for ipsec@ietf.org; Mon, 26 Apr 2004 14:37:01 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BIAxY-0005c6-00 for ipsec@ietf.org; Mon, 26 Apr 2004 14:36:04 -0400 Received: from cisco.com ([128.107.177.14]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i3QIZM0Q003780; Mon, 26 Apr 2004 11:35:27 -0700 (PDT) Message-ID: <408D56BF.20601@cisco.com> Date: Mon, 26 Apr 2004 11:36:47 -0700 From: Brian Weis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kseo@bbn.com CC: ipsec@ietf.org Subject: Re: [Ipsec] IPsec AH and ESP -- changes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-from-outside-Cisco-experimental-header: [128.107.177.14] X-PMX-Version: 4.5.0.92886 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Karen, The multicast changes look good to me. Just a couple of comments inline below: kseo@bbn.com wrote: > > 2. AH and ESP (and 2401bis)-- Thanks go to Suman Sharma and George > Gross for their input re: SAD entry lookup for inbound traffic in the > presence of multicast SAs. Also, thanks go to George for draft text. > We propose to replace the current text re: multicast lookup in > o AH Section 2.4 "Security Parameters Index (SPI)", paragraph 2 > o ESP Section 2.1 "Security Parameters Index (SPI)", paragraph 2 > > with the following text: > > "If an IPsec implementation supports multicast, then it MUST > support multicast SAs using the algorithm below for mapping > inbound IPsec datagrams to SAs. Implementations that support > only unicast traffic need not implement this demultiplexing > algorithm. > > In many secure multicast architectures, e.g., [RFC3740], a > central Group Controller/Key Server unilaterally assigns the > group security association's SPI. This SPI assignment is not > negotiated or coordinated with the key management (e.g., IKE) > subsystems that reside in the individual end systems that > compromise the group. Consequently, it is possible that a > group security association and a unicast security association > can simultaneously use the same SPI. A multicast-capable IPsec > implementation MUST correctly de-multiplex inbound traffic > even in the context of SPI collisions. > > Each entry in the Security Association Database (SAD) > [Ken-Arch] must indicate whether the SA lookup makes use of > the destination, or destination and source, IP addresses, in > addition to the SPI. For multicast SAs, the protocol field is > not employed for SA lookups. For each inbound, IPsec-protected > packet, an implementation must conduct its search of the SAD > such that it finds the entry that matches the "longest" SA > identifier. In this context, if two or more SAD entries match > based on the SPI value, then the entry that also matches based > on destination, or destination and source, address comparison > (as indicated in the SAD entry) is the "longest" match. This > implies a logical ordering of the SAD search as follows: > > 1. Search the SAD for a match on {SPI, destination > multicast address, source address}. If a SAD entry > matches then process the inbound ESP packet with that > matching SAD entry. Otherwise, proceed to step 2. > > 2. Search the SAD for a match on {SPI, destination > multicast address}. If the SAD entry matches then > process the inbound ESP packet with that matching SAD > entry. Otherwise, proceed to step 3. > For 1. and 2., it would be better to state "destination address" rather than "destination multicast address". The current drafts (discussing this process in terms of "bits") don't limit these bits to be applied to multicast. These semantics are suitable for broadcast and anycast as well as multicast, and these documents should continue to implicitly support them in the SA lookup rules. > 3. Search the SAD for a match on only {SPI}. If an SAD > entry matches then process the inbound ESP packet with > that matching SAD entry. Otherwise, discard the packet > and log an auditable event. > To be consistent, the optional protocol 3. should be mentioned. E.g., "Search the SAD for a match on only {SPI}, or optionally {SPI, protocol}". Thanks, Brian > In practice, an implementation MAY choose any method to > accelerate this search, although its externally visible > behavior MUST be functionally equivalent to having searched > the SAD in the above order. For example, a software-based > implementation could index into a hash table by the SPI. The > SAD entries in each hash table bucket's linked list are kept > sorted to have those SAD entries with the longest SA > identifiers first in that linked list. Those SAD entries > having the shortest SA identifiers are sorted so that they > are the last entries in the linked list. A hardware-based > implementation may be able to effect the longest match > search intrinsically, using commonly available TCAM features. > > The indication of whether source and destination address > matching is required to map inbound IPsec traffic to SAs MUST > be set either as a side effect of manual SA configuration or > via negotiation using an SA management protocol, e.g., IKE or > GDOI [RFC3547]. Typically, Source-Specific Multicast (SSM) > [HC03] groups use a 3-tuple SA identifier composed of an SPI, > a destination multicast address, and source address. An > Any-Source Multicast group SA requires only an SPI and a > destination multicast address as an identifier. > > References will be updated with: > > [RFC3547] Baugher, M., Weis, B., Hardjono, T., Harney, H., > "The Group Domain of Interpretation", RFC 3547, July 2003. > > [RFC3740] Hardjono, T., Weis, B., "The Multicast Group > Security Architecture", RFC 3740, March 2004. > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > -- Brian Weis Advanced Security Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 27 01:15:47 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3R8Fk8P074103; Tue, 27 Apr 2004 01:15:46 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BINbN-0004Cv-TT; Tue, 27 Apr 2004 04:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BINZD-0003tL-TI for ipsec@optimus.ietf.org; Tue, 27 Apr 2004 04:03:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12568 for ; Tue, 27 Apr 2004 04:03:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BINZB-0006ns-9W for ipsec@ietf.org; Tue, 27 Apr 2004 04:03:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BINYF-0006e4-00 for ipsec@ietf.org; Tue, 27 Apr 2004 04:02:47 -0400 Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BINXh-0006Tj-00 for ipsec@ietf.org; Tue, 27 Apr 2004 04:02:13 -0400 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-3) with ESMTP id i3R81xAe014971; Tue, 27 Apr 2004 11:01:59 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-3) id i3R81xsg014968; Tue, 27 Apr 2004 11:01:59 +0300 Date: Tue, 27 Apr 2004 11:01:59 +0300 Message-Id: <200404270801.i3R81xsg014968@burp.tkv.asdf.org> From: Markku Savela To: bew@cisco.com CC: kseo@bbn.com, ipsec@ietf.org In-reply-to: <408D53B3.6040405@cisco.com> (message from Brian Weis on Mon, 26 Apr 2004 11:23:47 -0700) Subject: Re: [Ipsec] IPsec AH and ESP -- changes References: <200404260853.i3Q8rTou003093@burp.tkv.asdf.org> <408D53B3.6040405@cisco.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , > From: Brian Weis > From my recollection, the rationale was that a single key server would > likely be choosing SPIs for a single {source addr, destination addr} > pair. That key server could probably be trusted to not choose the same > SPI for both an AH and ESP SA matching that flow. Therefore keeping the > protocol in the SA lookup was seen as unnecessary. > > You're right though, it does special case the SA lookup logic. If the > protocol were optionally included in the multicast SA lookup as well as > the unicast SA lookup, the semantics would be consistent. This might > simplify the implementation of an SA lookup. I.e., > > unicast: {SPI, [protocol]} > ASM multicast: {SPI, destination, [protocol]} > SSM multicast: {SPI, destination, source, [protocol]} There is no point in talking about "optional protocol". You MUST check the protocol anyway, as you are ALWAYS looking either AH or ESP. If you have AH header at hand, and look for SA using SPI only, it is not very helpful, if you find ESP SA. Multicast does not change this in any way. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 27 01:37:49 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3R8bliS083297; Tue, 27 Apr 2004 01:37:48 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BINwk-0006ph-Gs; Tue, 27 Apr 2004 04:28:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BINql-0006DW-Ti for ipsec@optimus.ietf.org; Tue, 27 Apr 2004 04:21:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13413 for ; Tue, 27 Apr 2004 04:21:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BINqj-0002RA-4S for ipsec@ietf.org; Tue, 27 Apr 2004 04:21:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BINpz-0002FN-00 for ipsec@ietf.org; Tue, 27 Apr 2004 04:21:08 -0400 Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BINpC-00022Q-00 for ipsec@ietf.org; Tue, 27 Apr 2004 04:20:18 -0400 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-3) with ESMTP id i3R8KDJL015338; Tue, 27 Apr 2004 11:20:13 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-3) id i3R8KCjg015335; Tue, 27 Apr 2004 11:20:12 +0300 Date: Tue, 27 Apr 2004 11:20:12 +0300 Message-Id: <200404270820.i3R8KCjg015335@burp.tkv.asdf.org> From: Markku Savela To: kseo@bbn.com CC: ipsec@ietf.org In-reply-to: (kseo@bbn.com) Subject: Re: [Ipsec] IPsec AH and ESP -- changes References: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , I've some doubt, perhaps clarification is needed? > From: kseo@bbn.com > 2. AH and ESP (and 2401bis) ... > Each entry in the Security Association Database (SAD) > [Ken-Arch] must indicate whether the SA lookup makes use of > the destination, or destination and source, IP addresses, in > addition to the SPI. ... > 2. Search the SAD for a match on {SPI, destination > multicast address}. If the SAD entry matches then > process the inbound ESP packet with that matching SAD > entry. Otherwise, proceed to step 3. I assume this will match *only* SA's, that indicate that source address is not used? > 3. Search the SAD for a match on only {SPI}. If an SAD > entry matches then process the inbound ESP packet with > that matching SAD entry. Otherwise, discard the packet > and log an auditable event. ...and, this matches *only* SA's, that indicate that neither source nor destination is used? _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 27 05:47:04 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RCl3nF020000; Tue, 27 Apr 2004 05:47:03 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIRkn-0007e2-N9; Tue, 27 Apr 2004 08:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIRbG-0003kA-QJ for ipsec@optimus.ietf.org; Tue, 27 Apr 2004 08:22:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26160 for ; Tue, 27 Apr 2004 08:22:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIRbB-0006kG-RU for ipsec@ietf.org; Tue, 27 Apr 2004 08:22:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIRaD-0006V9-00 for ipsec@ietf.org; Tue, 27 Apr 2004 08:21:06 -0400 Received: from smtp-out2.oct.nac.net ([209.123.233.212]) by ietf-mx with smtp (Exim 4.12) id 1BIRZV-0006Ge-00 for ipsec@ietf.org; Tue, 27 Apr 2004 08:20:21 -0400 Received: (qmail 68626 invoked from network); 27 Apr 2004 08:20:23 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 27 Apr 2004 08:20:23 -0400 Received: (qmail 72470 invoked from network); 27 Apr 2004 08:20:22 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.33) by mail1.oct.nac.net with SMTP; 27 Apr 2004 08:20:22 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id i3RAjHZ24052; Tue, 27 Apr 2004 06:45:17 -0400 Date: Tue, 27 Apr 2004 06:45:17 -0400 (EDT) From: George Gross To: Markku Savela cc: , Subject: Re: [Ipsec] IPsec AH and ESP -- changes In-Reply-To: <200404270820.i3R8KCjg015335@burp.tkv.asdf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Hi Markku, On Tue, 27 Apr 2004, Markku Savela wrote: > I've some doubt, perhaps clarification is needed? I'm trying to understand what is not clear to you, as I'm not sure I understand your question. > > > From: kseo@bbn.com > > > 2. AH and ESP (and 2401bis) > > ... > > Each entry in the Security Association Database (SAD) > > [Ken-Arch] must indicate whether the SA lookup makes use of > > the destination, or destination and source, IP addresses, in > > addition to the SPI. > > ... > > 2. Search the SAD for a match on {SPI, destination > > multicast address}. If the SAD entry matches then > > process the inbound ESP packet with that matching SAD > > entry. Otherwise, proceed to step 3. > > I assume this will match *only* SA's, that indicate that source address > is not used? The direct answer to your question is "yes". Of course, this procedural step is being interpreted in the context of a preceding text that discusses SAD search using the longest matching identifiers before the shorter identifiers. It does make the reasonable assumption that the IPsec implementation keeps the SAD entries sorted correctly. > > > 3. Search the SAD for a match on only {SPI}. If an SAD > > entry matches then process the inbound ESP packet with > > that matching SAD entry. Otherwise, discard the packet > > and log an auditable event. > > ...and, this matches *only* SA's, that indicate that neither source nor > destination is used? Again "yes", but with the understanding that it is part of a sorted search procedure. hth, George > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 27 06:44:13 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RDiCLl025514; Tue, 27 Apr 2004 06:44:12 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISjp-0002aI-8i; Tue, 27 Apr 2004 09:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BISfr-0001vw-S6 for ipsec@optimus.ietf.org; Tue, 27 Apr 2004 09:31:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00020 for ; Tue, 27 Apr 2004 09:30:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BISfm-0007Rd-7e for ipsec@ietf.org; Tue, 27 Apr 2004 09:30:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BISf1-0007Nx-00 for ipsec@ietf.org; Tue, 27 Apr 2004 09:30:07 -0400 Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BISeR-0007Jj-00 for ipsec@ietf.org; Tue, 27 Apr 2004 09:29:31 -0400 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-3) with ESMTP id i3RDTV7B017689; Tue, 27 Apr 2004 16:29:31 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-3) id i3RDTVPM017686; Tue, 27 Apr 2004 16:29:31 +0300 Date: Tue, 27 Apr 2004 16:29:31 +0300 Message-Id: <200404271329.i3RDTVPM017686@burp.tkv.asdf.org> From: Markku Savela To: gmgross@nac.net CC: ipsec@ietf.org In-reply-to: (message from George Gross on Tue, 27 Apr 2004 06:45:17 -0400 (EDT)) Subject: Re: [Ipsec] IPsec AH and ESP -- changes References: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , > From: George Gross > > > 3. Search the SAD for a match on only {SPI}. If an SAD > > > entry matches then process the inbound ESP packet with > > > that matching SAD entry. Otherwise, discard the packet > > > and log an auditable event. > > > > ...and, this matches *only* SA's, that indicate that neither source nor > > destination is used? > > Again "yes", but with the understanding that it is part of a sorted search > procedure. My misunderstanding, not reading the text carefully enough. It's clear now. [ I trying to clarify that, for example, case (3) is not in any way a "wild card search". It searches exact SA with src=unspecified and dst=unspecified, and will not match any other SA with src or dst specified. However, after reading the text again, this is actually what it says.] _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 27 08:59:48 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RFxl8O035249; Tue, 27 Apr 2004 08:59:48 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUpU-0000Uk-JO; Tue, 27 Apr 2004 11:49:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIUjb-0007m2-5g for ipsec@optimus.ietf.org; Tue, 27 Apr 2004 11:42:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07811 for ; Tue, 27 Apr 2004 11:42:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIUjY-0006i3-1L for ipsec@ietf.org; Tue, 27 Apr 2004 11:42:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIUgi-0006Uf-00 for ipsec@ietf.org; Tue, 27 Apr 2004 11:40:01 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1BIUeX-0006Jk-00 for ipsec@ietf.org; Tue, 27 Apr 2004 11:37:45 -0400 Received: from jurassic.eng.sun.com ([129.146.81.36]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3RFahms001926 for ; Tue, 27 Apr 2004 08:36:43 -0700 (PDT) Received: from jurassic.eng.sun.com (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i3RFah1J658134 for ; Tue, 27 Apr 2004 08:36:43 -0700 (PDT) Received: (from stillson@localhost) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id i3RFagr6658129 for ipsec@ietf.org; Tue, 27 Apr 2004 08:36:42 -0700 (PDT) Date: Tue, 27 Apr 2004 08:36:41 -0700 From: Chris Stillson To: ipsec@ietf.org Message-ID: <20040427153641.GA657975@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Ipsec] VID for nat traversal Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Just wondering what different implementations use for the VID to signify an implementation supports nat-t (since there is no rfc # yet) By my calculations the md5 hash of "RFC XXXX" is 810fa565f8ab14369105d706fbd57279, which seems to make as much sense as anything at this point. But, other people may have a different solution which will make interoperability tricky :) So, before releasing anything to the public, I would like to get this issue sorted out. chris stillson IPSEC crypto monkey x82477 Note: Preceding comments written by an engineer. There is nothing to read into them. He really has no hidden motives or agendas. 1.Right Understanding 2.Right Thoughts 3.Right Speech 4.Right Action 5.Right Livelihood 6.Right Effort 7.Right Mindfulness 8.Right Concentration --Please inform author if he has forgotten about any of these _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 27 09:45:18 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RGjIYL037846; Tue, 27 Apr 2004 09:45:18 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVRE-0002Lf-PN; Tue, 27 Apr 2004 12:28:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVCb-0006Qr-LF for ipsec@optimus.ietf.org; Tue, 27 Apr 2004 12:12:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09684 for ; Tue, 27 Apr 2004 12:12:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIVCY-0001Dv-4s for ipsec@ietf.org; Tue, 27 Apr 2004 12:12:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIVBe-0001B9-00 for ipsec@ietf.org; Tue, 27 Apr 2004 12:11:58 -0400 Received: from fsmail-out.f-secure.com ([193.110.109.20]) by ietf-mx with esmtp (Exim 4.12) id 1BIVAo-00015S-00 for ipsec@ietf.org; Tue, 27 Apr 2004 12:11:06 -0400 Received: from fsav4im2 (fsav4im2.f-secure.com [193.110.108.82]) by fsmail-out.f-secure.com (Postfix) with SMTP id E52D35B859 for ; Tue, 27 Apr 2004 19:09:56 +0300 (EEST) Received: from [10.128.128.81]:52075 (HELO dfintra.f-secure.com) by fsav4im2.f-secure.com ([193.110.108.82]:25) (F-Secure Anti-Virus for Internet Mail 6.30.25 Release) with SMTP; Tue, 27 Apr 2004 16:10:34 -0000 Received: (qmail 2544 invoked from network); 27 Apr 2004 16:10:34 -0000 Received: from unknown (HELO fsecure-joern1.f-secure.com) (10.128.150.1) by dfintra.f-secure.com with SMTP; 27 Apr 2004 16:10:34 -0000 Message-Id: <5.2.1.1.0.20040427180915.05837bc0@dfintra.f-secure.com> X-Sender: joern@dfintra.f-secure.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 27 Apr 2004 18:11:30 +0200 To: Chris Stillson , ipsec@ietf.org From: Joern Sierwald Subject: Re: [Ipsec] VID for nat traversal In-Reply-To: <20040427153641.GA657975@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3RGjIYL037846 At 08:36 27.04.2004 -0700, Chris Stillson wrote: >Just wondering what different implementations use for the VID to >signify an implementation supports nat-t (since there is no rfc # yet) > >By my calculations the md5 hash of "RFC XXXX" is >810fa565f8ab14369105d706fbd57279, which seems to make as much sense as >anything at this point. But, other people may have a different >solution which will make interoperability tricky :) So, before >releasing anything to the public, I would like to get this issue >sorted out. > > >chris stillson >IPSEC crypto monkey >x82477 8a:8f:e1:12:55:30:4d:3b:0a:ee:ba:b8:24:da:90:f6 for "draft-ietf-ipsec-nat-t-ike-05" I don't know any other solution. And this one will certainly stay in even when the RFC is released. Jörn _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 27 09:52:31 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RGqTeG038281; Tue, 27 Apr 2004 09:52:29 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVdn-0005KB-49; Tue, 27 Apr 2004 12:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVQH-00026Z-FY for ipsec@optimus.ietf.org; Tue, 27 Apr 2004 12:27:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10382 for ; Tue, 27 Apr 2004 12:27:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIVQD-0001xT-U0 for ipsec@ietf.org; Tue, 27 Apr 2004 12:27:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIVPE-0001uX-00 for ipsec@ietf.org; Tue, 27 Apr 2004 12:26:01 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BIVOM-0001oI-00 for ipsec@ietf.org; Tue, 27 Apr 2004 12:25:06 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 27 Apr 2004 08:36:20 +0000 Received: from cisco.com (dhcp-128-107-163-236.cisco.com [128.107.163.236]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3RGOZC1003170; Tue, 27 Apr 2004 09:24:36 -0700 (PDT) Message-ID: <408E899B.8080708@cisco.com> Date: Tue, 27 Apr 2004 09:26:03 -0700 From: Brian Weis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markku Savela CC: kseo@bbn.com, ipsec@ietf.org Subject: Re: [Ipsec] IPsec AH and ESP -- changes References: <200404260853.i3Q8rTou003093@burp.tkv.asdf.org> <408D53B3.6040405@cisco.com> <200404270801.i3R81xsg014968@burp.tkv.asdf.org> In-Reply-To: <200404270801.i3R81xsg014968@burp.tkv.asdf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Markku Savela wrote: >>From: Brian Weis >> >> > > > >> From my recollection, the rationale was that a single key server would >>likely be choosing SPIs for a single {source addr, destination addr} >>pair. That key server could probably be trusted to not choose the same >>SPI for both an AH and ESP SA matching that flow. Therefore keeping the >>protocol in the SA lookup was seen as unnecessary. >> >>You're right though, it does special case the SA lookup logic. If the >>protocol were optionally included in the multicast SA lookup as well as >>the unicast SA lookup, the semantics would be consistent. This might >>simplify the implementation of an SA lookup. I.e., >> >> unicast: {SPI, [protocol]} >> ASM multicast: {SPI, destination, [protocol]} >> SSM multicast: {SPI, destination, source, [protocol]} >> >> > >There is no point in talking about "optional protocol". You MUST check >the protocol anyway, as you are ALWAYS looking either AH or ESP. > > > Recall that with unicast SAs (negotiated with IKE) IPsec chooses the SPIs for incoming SAs. Some IPsec implementations have been careful to choose unique SPIs for all SAs, so that in no case will they have an AH and ESP SA with the same SPI. They then simplified their SA lookup to use just the SPI. In the new ESP and AH drafts the authors recognized this, and made the protocol an optional part of the lookup for unicast SAs. Brian >If you have AH header at hand, and look for SA using SPI only, it is >not very helpful, if you find ESP SA. Multicast does not change this >in any way. > > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec > > > -- Brian Weis Advanced Security Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 27 10:08:51 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RH8oYh039217; Tue, 27 Apr 2004 10:08:51 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVpf-0000r0-A5; Tue, 27 Apr 2004 12:53:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVhf-00069h-5L for ipsec@optimus.ietf.org; Tue, 27 Apr 2004 12:45:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11932 for ; Tue, 27 Apr 2004 12:44:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIVhb-0003hn-Dh for ipsec@ietf.org; Tue, 27 Apr 2004 12:44:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIVfp-0003Mg-00 for ipsec@ietf.org; Tue, 27 Apr 2004 12:43:11 -0400 Received: from rs9.luxsci.com ([66.216.98.59]) by ietf-mx with esmtp (Exim 4.12) id 1BIVdT-0002nx-00 for ipsec@ietf.org; Tue, 27 Apr 2004 12:40:43 -0400 Received: from rs9.luxsci.com (localhost [127.0.0.1]) by rs9.luxsci.com (8.12.11/8.12.10) with ESMTP id i3RGe9WB015465 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 27 Apr 2004 11:40:09 -0500 Received: (from root@localhost) by rs9.luxsci.com (8.12.11/8.12.10/Submit) id i3RGa3Ut012669; Tue, 27 Apr 2004 16:36:03 GMT Message-Id: <200404271636.i3RGa3Ut012669@rs9.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Tue, 27 Apr 2004 16:36:03 +0000 From: "William Dixon" To: "'Chris Stillson'" , Subject: RE: [Ipsec] VID for nat traversal Date: Tue, 27 Apr 2004 12:35:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <20040427153641.GA657975@jurassic.eng.sun.com> X-Lux-Comment: LuxSci remailer message ID code - 1083083763-6526989.52468188 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Chris, the earlier drafts provided the vendor ID being MD5 of the draft name. If you support multiple versions, you include multiple vendor IDs. >From draft-ietf-ipsec-nat-t-ike-02.txt: "the vendor id payload for this specification of NAT-Traversal (MD5 hash of "draft- ietf-ipsec-nat-t-ike-02" - ["90cb8091 3ebb696e 086381b5 ec427b1f"])" Windows NAT-T implementation so far uses draft-02 vendor ID. Here is the Win2k & XP NAT-T update info. http://support.microsoft.com/default.aspx?scid=kb;en-us;818043 > -----Original Message----- > From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org] On > Behalf Of Chris Stillson > Sent: Tuesday, April 27, 2004 11:37 AM > To: ipsec@ietf.org > Subject: [Ipsec] VID for nat traversal > > Just wondering what different implementations use for the VID > to signify an implementation supports nat-t (since there is > no rfc # yet) > > By my calculations the md5 hash of "RFC XXXX" is > 810fa565f8ab14369105d706fbd57279, which seems to make as much > sense as anything at this point. But, other people may have a > different solution which will make interoperability tricky :) > So, before releasing anything to the public, I would like to > get this issue sorted out. > > > chris stillson > IPSEC crypto monkey > x82477 > > Note: Preceding comments written by an engineer. There is > nothing to read into them. He really has no hidden motives or agendas. > > 1.Right Understanding 2.Right Thoughts 3.Right Speech 4.Right > Action 5.Right Livelihood 6.Right Effort 7.Right Mindfulness > 8.Right Concentration --Please inform author if he has > forgotten about any of these > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 27 10:09:15 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RH9DkW039245; Tue, 27 Apr 2004 10:09:14 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVpg-0000rL-MX; Tue, 27 Apr 2004 12:53:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIVhx-0006H6-NP for ipsec@optimus.ietf.org; Tue, 27 Apr 2004 12:45:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11961 for ; Tue, 27 Apr 2004 12:45:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIVht-0003lF-Tb for ipsec@ietf.org; Tue, 27 Apr 2004 12:45:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIVgW-0003SV-00 for ipsec@ietf.org; Tue, 27 Apr 2004 12:43:53 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1BIVeF-000331-00 for ipsec@ietf.org; Tue, 27 Apr 2004 12:41:31 -0400 Received: from jurassic.eng.sun.com ([129.146.81.144]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i3RGfU4U024559; Tue, 27 Apr 2004 10:41:31 -0600 (MDT) Received: from jurassic.eng.sun.com (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i3RGfUvo682511; Tue, 27 Apr 2004 09:41:30 -0700 (PDT) Received: (from stillson@localhost) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id i3RGfU3S682508; Tue, 27 Apr 2004 09:41:30 -0700 (PDT) Date: Tue, 27 Apr 2004 09:41:30 -0700 From: Chris Stillson To: ipsec@ietf.org Cc: Joern Sierwald Subject: Re: [Ipsec] VID for nat traversal Message-ID: <20040427164130.GA679606@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , >Joern Sierwald wrote: >8a:8f:e1:12:55:30:4d:3b:0a:ee:ba:b8:24:da:90:f6 >for "draft-ietf-ipsec-nat-t-ike-05" >I don't know any other solution. And this one will certainly stay in >even when the RFC is released. >Joern That sounds very reasonable to me. Except that that current draft if revison 8, giving 8f8d83826d246b6fc7a8a6a428c11de8, although I come up with 80d0bb3def54565ee84645d4c85ce3ee for revision 5.... Maybe the easiest thing to do now is to just get everyone to tell the list what they are using so we can all just recognize each others vid's and work together. Although, hopefully, this point will soon be moot. chris stillson IPSEC crypto monkey x82477 Note: Preceding comments written by an engineer. There is nothing to read into them. He really has no hidden motives or agendas. 1.Right Understanding 2.Right Thoughts 3.Right Speech 4.Right Action 5.Right Livelihood 6.Right Effort 7.Right Mindfulness 8.Right Concentration --Please inform author if he has forgotten about any of these _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 27 12:10:20 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RJAIiZ047826; Tue, 27 Apr 2004 12:10:19 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIXlP-0006Hj-Fj; Tue, 27 Apr 2004 14:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIXjb-00061R-5y for ipsec@optimus.ietf.org; Tue, 27 Apr 2004 14:55:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19980 for ; Tue, 27 Apr 2004 14:55:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIXjW-00011Z-Bu for ipsec@ietf.org; Tue, 27 Apr 2004 14:55:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIXic-0000wl-00 for ipsec@ietf.org; Tue, 27 Apr 2004 14:54:10 -0400 Received: from fsmail-out.f-secure.com ([193.110.109.20]) by ietf-mx with esmtp (Exim 4.12) id 1BIXi5-0000rM-00 for ipsec@ietf.org; Tue, 27 Apr 2004 14:53:37 -0400 Received: from fsav4im2 (fsav4im2.f-secure.com [193.110.108.82]) by fsmail-out.f-secure.com (Postfix) with SMTP id B22CD5B7C5 for ; Tue, 27 Apr 2004 21:52:27 +0300 (EEST) Received: from [10.128.128.81]:33735 (HELO dfintra.f-secure.com) by fsav4im2.f-secure.com ([193.110.108.82]:25) (F-Secure Anti-Virus for Internet Mail 6.30.25 Release) with SMTP; Tue, 27 Apr 2004 18:53:06 -0000 Received: (qmail 2210 invoked from network); 27 Apr 2004 18:53:06 -0000 Received: from unknown (HELO fsecure-joern1.f-secure.com) (10.128.150.1) by dfintra.f-secure.com with SMTP; 27 Apr 2004 18:53:06 -0000 Message-Id: <5.2.1.1.0.20040427201855.02bf95c0@dfintra.f-secure.com> X-Sender: joern@dfintra.f-secure.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 27 Apr 2004 20:54:03 +0200 To: Chris Stillson , ipsec@ietf.org From: Joern Sierwald Subject: Re: [Ipsec] VID for nat traversal In-Reply-To: <20040427164130.GA679606@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3RJAIiZ047826 At 09:41 27.04.2004 -0700, Chris Stillson wrote: > >Joern Sierwald wrote: > > >8a:8f:e1:12:55:30:4d:3b:0a:ee:ba:b8:24:da:90:f6 > >for "draft-ietf-ipsec-nat-t-ike-05" > > >I don't know any other solution. And this one will certainly stay in > >even when the RFC is released. > > >Joern > >That sounds very reasonable to me. Except that that current draft if >revison 8, giving >8f8d83826d246b6fc7a8a6a428c11de8, although I come up with >80d0bb3def54565ee84645d4c85ce3ee for revision 5.... > >Maybe the easiest thing to do now is to just get everyone to tell the >list what they are using so we can all just recognize each others vid's >and work together. Although, hopefully, this point will soon be moot. > > >chris stillson >IPSEC crypto monkey >x82477 > >Note: Preceding comments written by an engineer. There is nothing >to read into them. He really has no hidden motives or agendas. > >1.Right Understanding 2.Right Thoughts 3.Right Speech 4.Right Action >5.Right Livelihood 6.Right Effort 7.Right Mindfulness 8.Right Concentration >--Please inform author if he has forgotten about any of these > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec Interestingly, we're not using the hash of "draft-ietf-ipsec-nat-t-ike-05" but the hash of "draft-ietf-ipsec-nat-t-ike-05.txt". I checked the cvs to find the reason. I blame myself. oh dear. I guess I have to fix something. Now if only I'd know what other value I should add. This thread is quite an eye-opener for me, so could we settle on something? As far as I see it the thing might never go RFC and stay in an endless draft-update-loop. So. What was the last draft version that actually changed something? 05? Jörn _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 27 12:41:59 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RJfv7C050382; Tue, 27 Apr 2004 12:41:58 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIYKD-0005TC-Tt; Tue, 27 Apr 2004 15:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIYFc-0004bP-AO for ipsec@optimus.ietf.org; Tue, 27 Apr 2004 15:28:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23723 for ; Tue, 27 Apr 2004 15:28:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIYFZ-0004q6-0Q for ipsec@ietf.org; Tue, 27 Apr 2004 15:28:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIYDX-0004Wd-00 for ipsec@ietf.org; Tue, 27 Apr 2004 15:26:08 -0400 Received: from rs9.luxsci.com ([66.216.98.59]) by ietf-mx with esmtp (Exim 4.12) id 1BIYD5-0004Rm-00 for ipsec@ietf.org; Tue, 27 Apr 2004 15:25:40 -0400 Received: from rs9.luxsci.com (localhost [127.0.0.1]) by rs9.luxsci.com (8.12.11/8.12.10) with ESMTP id i3RJP9Pm031679 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 27 Apr 2004 14:25:09 -0500 Received: (from root@localhost) by rs9.luxsci.com (8.12.11/8.12.10/Submit) id i3RJM24h030995; Tue, 27 Apr 2004 19:22:02 GMT Message-Id: <200404271922.i3RJM24h030995@rs9.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Tue, 27 Apr 2004 19:22:01 +0000 From: "William Dixon" To: "'Joern Sierwald'" , "'Chris Stillson'" , Subject: RE: [Ipsec] VID for nat traversal Date: Tue, 27 Apr 2004 15:21:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" In-Reply-To: <5.2.1.1.0.20040427201855.02bf95c0@dfintra.f-secure.com> X-Lux-Comment: LuxSci remailer message ID code - 1083093721-987392.691681683 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3RJfv7C050382 Joern, I guess you'd have to verify interop with other products for each vendor ID you send to know whether you should send it. The last draft with a specific VID is -03. "the vendor id payload for this specification of NAT-Traversal (MD5 hash of "draft- ietf-ipsec-nat-t-ike-03" - ["7d9419a6 5310ca6f 2c179d92 15529d56"])" draft-ietf-ipsec-nat-t-ike-04.txt starts with MD5 hash of RFC XXXX. You can look at all of the draft versions on one of the public archives, such as: http://www.watersprings.org/pub/id/index-wgi.html > -----Original Message----- > From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org] On > Behalf Of Joern Sierwald > Sent: Tuesday, April 27, 2004 2:54 PM > To: Chris Stillson; ipsec@ietf.org > Subject: Re: [Ipsec] VID for nat traversal > > At 09:41 27.04.2004 -0700, Chris Stillson wrote: > > >Joern Sierwald wrote: > > > > >8a:8f:e1:12:55:30:4d:3b:0a:ee:ba:b8:24:da:90:f6 > > >for "draft-ietf-ipsec-nat-t-ike-05" > > > > >I don't know any other solution. And this one will > certainly stay in > > >even when the RFC is released. > > > > >Joern > > > >That sounds very reasonable to me. Except that that current draft if > >revison 8, giving 8f8d83826d246b6fc7a8a6a428c11de8, although > I come up > >with 80d0bb3def54565ee84645d4c85ce3ee for revision 5.... > > > >Maybe the easiest thing to do now is to just get everyone to > tell the > >list what they are using so we can all just recognize each > others vid's > >and work together. Although, hopefully, this point will soon be moot. > > > > > >chris stillson > >IPSEC crypto monkey > >x82477 > > > >Note: Preceding comments written by an engineer. There is nothing to > >read into them. He really has no hidden motives or agendas. > > > >1.Right Understanding 2.Right Thoughts 3.Right Speech 4.Right Action > >5.Right Livelihood 6.Right Effort 7.Right Mindfulness 8.Right > >Concentration --Please inform author if he has forgotten > about any of > >these > > > >_______________________________________________ > >Ipsec mailing list > >Ipsec@ietf.org > >https://www1.ietf.org/mailman/listinfo/ipsec > > > Interestingly, we're not using the hash of > "draft-ietf-ipsec-nat-t-ike-05" but the hash of > "draft-ietf-ipsec-nat-t-ike-05.txt". I checked the cvs to > find the reason. > > I blame myself. > > oh dear. I guess I have to fix something. Now if only I'd > know what other value I should add. > > This thread is quite an eye-opener for me, so could we settle > on something? > As far as I see it > the thing might never go RFC and stay in an endless > draft-update-loop. So. > What was the last draft version that actually changed something? 05? > > Jörn > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 27 12:46:48 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RJklto050763; Tue, 27 Apr 2004 12:46:48 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIYR0-0006kp-ML; Tue, 27 Apr 2004 15:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIYHQ-0004wN-68 for ipsec@optimus.ietf.org; Tue, 27 Apr 2004 15:30:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24154 for ; Tue, 27 Apr 2004 15:30:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIYHM-0005Ea-Pf for ipsec@ietf.org; Tue, 27 Apr 2004 15:30:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIYGa-00054n-00 for ipsec@ietf.org; Tue, 27 Apr 2004 15:29:18 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1BIYFH-0004kp-00 for ipsec@ietf.org; Tue, 27 Apr 2004 15:27:55 -0400 Received: from jurassic.eng.sun.com ([129.146.82.37]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i3RJRv4U022499 for ; Tue, 27 Apr 2004 13:27:57 -0600 (MDT) Received: from jurassic.eng.sun.com (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i3RJRvXi760846 for ; Tue, 27 Apr 2004 12:27:57 -0700 (PDT) Received: (from stillson@localhost) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id i3RJRvuR760845 for ipsec@ietf.org; Tue, 27 Apr 2004 12:27:57 -0700 (PDT) Date: Tue, 27 Apr 2004 12:27:57 -0700 From: Chris Stillson To: ipsec@ietf.org Subject: Re: [Ipsec] VID for nat traversal Message-ID: <20040427192757.GA760706@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Joern Sierwald writes: > Interestingly, we're not using the hash of "draft-ietf-ipsec-nat-t-ike-05" but > the hash of "draft-ietf-ipsec-nat-t-ike-05.txt". I checked the cvs to find the > reason. > > I blame myself. > > oh dear. I guess I have to fix something. Now if only I'd know what other > value I should add. > > This thread is quite an eye-opener for me, so could we settle on something? > As far as I see it > the thing might never go RFC and stay in an endless draft-update-loop. So. > What was the last draft version that actually changed something? 05? The one thing that bothers me is that I started my implementation of of draft 6 or 7, and there was no mention of using a hash of the draft, just RFC XXXX to be replaced the actual number. So all of a sudden, we are using drafts that shouldn't be used as any kind of standard. No big deal, but maybe that language should not have been removed from the later drafts. Also, it seems to be kind of anti-interoperability to work that way, i.e. only accepting a certain draft. Ideally, this will be an RFC sometime soon, and we won't have to worry about it. If not, we need to decide here and now what to use. And to encourage vendors to keep their code to the latest draft to cut down on interop problem. As I see it we have 3 choices for vendor id 1)"draft-ietf-ipsec-nat-t-ike-02" - ["90cb8091 3ebb696e 086381b5 ec427b1f"])" Windows clients will dominate this space. We should probably make sure that we work with windows, although I am not too sure how compatible draft 2 is with draft 8 2)md5("draft-ietf-ipsec-nat-t-ike-05") or md5("draft-ietf-ipsec-nat-t-ike-08") that would seem to be logical for anyone who's implementation is up to date with the spec 3) md5("RFC XXXX") for the overly literal (myself :) ) or perhaps something different? md5("RFC NATT") for example. If we can't agree now, we will all have to have a fairly large table of every vendor id that we think works.... chris stillson IPSEC crypto monkey x82477 Note: Preceding comments written by an engineer. There is nothing to read into them. He really has no hidden motives or agendas. 1.Right Understanding 2.Right Thoughts 3.Right Speech 4.Right Action 5.Right Livelihood 6.Right Effort 7.Right Mindfulness 8.Right Concentration --Please inform author if he has forgotten about any of these _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 27 13:40:39 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RKeajr055074; Tue, 27 Apr 2004 13:40:37 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIYpC-0002bW-TO; Tue, 27 Apr 2004 16:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIYeh-0000ir-C4 for ipsec@optimus.ietf.org; Tue, 27 Apr 2004 15:54:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25530 for ; Tue, 27 Apr 2004 15:54:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIYed-0007dg-RD for ipsec@ietf.org; Tue, 27 Apr 2004 15:54:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIYdl-0007YZ-00 for ipsec@ietf.org; Tue, 27 Apr 2004 15:53:13 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BIYdH-0007TK-00 for ipsec@ietf.org; Tue, 27 Apr 2004 15:52:43 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3RJpmp00335 for ; Tue, 27 Apr 2004 15:51:52 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3RJnsEa024369 for ; Tue, 27 Apr 2004 15:49:55 -0400 (EDT) Received: from odin.ietf.org(132.151.1.176) by nutshell.tislabs.com via csmap (V6.0) id srcAAAN5aqzV; Tue, 27 Apr 04 15:49:06 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25379; Tue, 27 Apr 2004 15:51:23 -0400 (EDT) Message-Id: <200404271951.PAA25379@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Date: Tue, 27 Apr 2004 15:51:23 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Subject: [Ipsec] I-D ACTION:draft-ietf-ipsec-ciph-aes-gcm-00.txt Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , --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 : The Use of Galois/Counter Mode (GCM) in IPsec ESP Author(s) : D. McGrew, J. Viega. Filename : draft-ietf-ipsec-ciph-aes-gcm-00.txt Pages : 21 Date : 2004-4-27 This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality and data origin authentication. This method can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-gcm-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ciph-aes-gcm-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-gcm-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-27161200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-gcm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-aes-gcm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-27161200.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 27 14:30:26 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RLUOgK058458; Tue, 27 Apr 2004 14:30:25 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIZvu-0005Dd-C1; Tue, 27 Apr 2004 17:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIZol-0003zx-Eg for ipsec@optimus.ietf.org; Tue, 27 Apr 2004 17:08:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02092 for ; Tue, 27 Apr 2004 17:08:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIZoh-0002zy-77 for ipsec@ietf.org; Tue, 27 Apr 2004 17:08:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIZni-0002nj-00 for ipsec@ietf.org; Tue, 27 Apr 2004 17:07:34 -0400 Received: from noxmail.sandelman.ottawa.on.ca ([205.150.200.166]) by ietf-mx with esmtp (Exim 4.12) id 1BIZm4-0002Vn-00 for ipsec@ietf.org; Tue, 27 Apr 2004 17:05:52 -0400 Received: from sandelman.ottawa.on.ca (wlan237.sandelman.ca [205.150.200.237]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i3RL5iP21295 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Tue, 27 Apr 2004 17:05:44 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3RL5hsG024896 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 27 Apr 2004 17:05:43 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3RL5hdt024893; Tue, 27 Apr 2004 17:05:43 -0400 To: Chris Stillson cc: ipsec@ietf.org Subject: Re: [Ipsec] VID for nat traversal In-Reply-To: Message from Chris Stillson of "Tue, 27 Apr 2004 12:27:57 PDT." <20040427192757.GA760706@jurassic.eng.sun.com> References: <20040427192757.GA760706@jurassic.eng.sun.com> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Tue, 27 Apr 2004 17:05:43 -0400 Message-ID: <24892.1083099943@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Chris" == Chris Stillson writes: Chris> As I see it we have 3 choices for vendor id Chris> 1)"draft-ietf-ipsec-nat-t-ike-02" - ["90cb8091 3ebb696e Chris> 086381b5 ec427b1f"])" It is my understanding that an implementation of -02 will interop with anything larger, so one should use the above until RFC time. -00/-01 is a different story. This is what Openswan does. Chris> Windows clients will dominate this space. We should probably Chris> make sure that we work with windows, although I am not too Chris> sure how compatible draft 2 is with draft 8 We interop with windows clients all the time. We have seen them all send the -02 VID. I don't know if there is newer code for any of them. Chris> 2)md5("draft-ietf-ipsec-nat-t-ike-05") or Chris> md5("draft-ietf-ipsec-nat-t-ike-08") Chris> that would seem to be logical for anyone who's implementation Chris> is up to date with the spec I guess I should diff the specs. - -- ] 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 iQCVAwUBQI7LJoqHRg3pndX9AQE6sQP/V8lx5/bD32Oo4iF4RSs6sNczAPtASDB6 GgwTJdFqkSHNXCo0Fkiq3S/8x58xEUW+fZNcTPt/RcHJi+on5IQp+oINEWukmZqK z+c3W28zoVRj/5NOjZqqeiPusEA1Y20qpuFKjjzmS953TZb6hYt/dzVJNqi5zPUw KFpHXMOCWR4= =48I8 -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 27 14:43:20 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RLhJog059274; Tue, 27 Apr 2004 14:43:20 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIaFH-0007Oo-Ro; Tue, 27 Apr 2004 17:36:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIa5z-0006SU-UM for ipsec@optimus.ietf.org; Tue, 27 Apr 2004 17:26:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02951 for ; Tue, 27 Apr 2004 17:26:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIa5v-00058G-Iz for ipsec@ietf.org; Tue, 27 Apr 2004 17:26:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIa4r-00050H-00 for ipsec@ietf.org; Tue, 27 Apr 2004 17:25:18 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BIa3x-0004mj-00 for ipsec@ietf.org; Tue, 27 Apr 2004 17:24:21 -0400 Received: from po2.bbn.com (po2.bbn.com [128.33.0.56]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i3RLNm7W028533; Tue, 27 Apr 2004 17:23:48 -0400 (EDT) Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by po2.bbn.com (8.10.2+Sun/8.10.2) with ESMTP id i3RLNm602417; Tue, 27 Apr 2004 17:23:48 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: <5.2.0.9.0.20040426124209.020d5968@email> References: <5.2.0.9.0.20040419120357.0205b710@email> <5.2.0.9.0.20040419120357.0205b710@email> <5.2.0.9.0.20040426124209.020d5968@email> Date: Tue, 27 Apr 2004 17:31:02 -0400 To: Mark Duffy From: Karen Seo Subject: Re: [Ipsec] Re: 2401bis -- Issue 91 -- handling ICMP error messages Cc: ipsec@ietf.org, kseo@po2.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.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Hi Mark, >I understand how, as you describe, this processing of icmp error >messages might protect against certain DOS attacks. But it seems to >me to be overzealous in your approach #2. > >In your approach #1 the icmp error message is being sent on an SA >pair implied by the enclosed packet in the icmp payload. In that >case I think it makes perfect sense for both IPsec devices to >evaluate the SPD policy for that enclosed packet. > >But in #2 the icmp error message is being sent on an SA negotiated >for protocol=icmp, type= and code=. It seems to me >to be an impropriety for the IPsec implementation to check the >enclosed packet. This would be checking that goes beyond the >negotiated selectors -- AFAIK there is no other comparable thing >done elsewhere in IPsec. Hmmm... ICMP messages can more directly cause problems than regular data traffic. They could be used to redirect traffic, change the PMTU, etc. So it seemed to us that additional checking was warranted. > Should an IPsec implementation also check for invalid combinations >of control bits in a tcp header? Or for packets with src addr == >dest addr? These are also checks that could protect against attacks >but they oughtn't IMO to be part of the *IPsec* processing. I think I understand what you're saying but verifying that the packet enclosed in an ICMP message could have legitimately come from an entity behind the local IPsec implementation seems appropriate given the risks. I would like to at least leave this check in as a note with a MAY. What do you think? Do you want this check removed entirely? >P.S. Comments on the wording: > - Regardless of what behavior is chosen, it would be better if the >text does not describe a fast path and a slow path, and what is done >in each. I don't think there is anything gained by including such >implementation assumptions. OK. Will do. > - The phrase "to ensure that the enclosed packet is consistent >with its source" could use some elaboration. Good point. Consistent --> the selector fields in the enclosed packet match the selector fields for an existing SA. Karen _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 27 14:58:54 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RLwpsR060035; Tue, 27 Apr 2004 14:58:52 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIaRs-0001dx-AA; Tue, 27 Apr 2004 17:49:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIaMA-0000XV-7M for ipsec@optimus.ietf.org; Tue, 27 Apr 2004 17:43:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03709 for ; Tue, 27 Apr 2004 17:43:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIaM5-0006xh-N6 for ipsec@ietf.org; Tue, 27 Apr 2004 17:43:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIaL8-0006qT-00 for ipsec@ietf.org; Tue, 27 Apr 2004 17:42:07 -0400 Received: from fsmail-out.f-secure.com ([193.110.109.20]) by ietf-mx with esmtp (Exim 4.12) id 1BIaKB-0006cp-00 for ipsec@ietf.org; Tue, 27 Apr 2004 17:41:08 -0400 Received: from fsav4im2 (fsav4im2.f-secure.com [193.110.108.82]) by fsmail-out.f-secure.com (Postfix) with SMTP id 8B1595B8B3 for ; Wed, 28 Apr 2004 00:39:58 +0300 (EEST) Received: from [10.128.128.81]:41451 (HELO dfintra.f-secure.com) by fsav4im2.f-secure.com ([193.110.108.82]:25) (F-Secure Anti-Virus for Internet Mail 6.30.25 Release) with SMTP; Tue, 27 Apr 2004 21:40:38 -0000 Received: (qmail 14417 invoked from network); 27 Apr 2004 21:40:37 -0000 Received: from unknown (HELO fsecure-joern1.f-secure.com) (10.128.150.1) by dfintra.f-secure.com with SMTP; 27 Apr 2004 21:40:37 -0000 Message-Id: <5.2.1.1.0.20040427232844.02bc5d30@dfintra.f-secure.com> X-Sender: joern@dfintra.f-secure.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 27 Apr 2004 23:41:34 +0200 To: Chris Stillson , ipsec@ietf.org From: Joern Sierwald Subject: Re: [Ipsec] VID for nat traversal In-Reply-To: <20040427192757.GA760706@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3RLwpsR060035 At 12:27 27.04.2004 -0700, Chris Stillson wrote: [snip] >As I see it we have 3 choices for vendor id >1)"draft-ietf-ipsec-nat-t-ike-02" - >["90cb8091 3ebb696e 086381b5 ec427b1f"])" > >Windows clients will dominate this space. We should probably make sure >that we work with windows, although I am not too sure how compatible >draft 2 is with draft 8 > >2)md5("draft-ietf-ipsec-nat-t-ike-05") or > md5("draft-ietf-ipsec-nat-t-ike-08") > >that would seem to be logical for anyone who's implementation is up to >date with the spec > >3) md5("RFC XXXX") for the overly literal (myself :) ) or perhaps >something different? > >md5("RFC NATT") for example. > > >If we can't agree now, we will all have to have a fairly large table >of every vendor id that we think works.... > >chris stillson >IPSEC crypto monkey >x82477 > >Note: Preceding comments written by an engineer. There is nothing >to read into them. He really has no hidden motives or agendas. > >1.Right Understanding 2.Right Thoughts 3.Right Speech 4.Right Action >5.Right Livelihood 6.Right Effort 7.Right Mindfulness 8.Right Concentration >--Please inform author if he has forgotten about any of these > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec overview: -00 initial release does not float to port 4500, ESP uses port 500 as well one OA payload NAT-D 130, NAT-OA 131, UDP-Tunnel 61443, UDP-Transport 61443 VID: MD5 hash of "draft-ietf-ipsec-nat-t-ike-00" - ["4485152d 18b6bbcd 0be8a846 9579ddcc"] -01 editorial changes to -00 VID: MD5 hash of "draft-ietf-ipsec-nat-t-ike-00" - ["4485152d 18b6bbcd 0be8a846 9579ddcc"] (sic!) -02 floats to port 4500 one OA payload NAT-D 130, NAT-OA 131, UDP-Tunnel 61443, UDP-Transport 61443 VID: MD5 hash of "draft-ietf-ipsec-nat-t-ike-02" - ["90cb8091 3ebb696e 086381b5 ec427b1f"] -03 same as -02, repost, VID changes. VID: MD5 hash of "draft-ietf-ipsec-nat-t-ike-03" - ["7d9419a6 5310ca6f 2c179d92 15529d56"] -04 floats to port 4500 one OA payload NAT-D 15, NAT-OA 16, UDP-Tunnel 3, UDP-Transport 4 VID of unknown value -05 floats to port 4500 two OA payloads NAT-D 15, NAT-OA 16, UDP-Tunnel 3, UDP-Transport 4 VID of unknown value -06, -07, -08 I have read them and found only editorial changes. Your plan >1)"draft-ietf-ipsec-nat-t-ike-02" - >["90cb8091 3ebb696e 086381b5 ec427b1f"])" can't work, as draft -02 is not compatible with drafts -04 and higher at all. Assuming you implement the -08. >md5("draft-ietf-ipsec-nat-t-ike-08") will be a problem after 10 July 2004 when -09 will be released, as a repost. Then people with md5("draft-ietf-ipsec-nat-t-ike-09") won't interoperate with your md5("draft-ietf-ipsec-nat-t-ike-08") md5("draft-ietf-ipsec-nat-t-ike-05") seems practical to me, but not "good". I will include that in our product anyway. I still hate myself for the ".txt" incident. For the record, that'd be 80d0bb3def54565ee84645d4c85ce3ee md5("RFC NATT"). I like that one. or md5("RFC NAT-T"). or md5("draft-ietf-ipsec-nat-t-ike"). Will be a big problem if somebody DOES change the draft again, obviously. Jörn Sierwald _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 27 15:00:40 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RM0cFx060113; Tue, 27 Apr 2004 15:00:38 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIaSp-0001j7-6z; Tue, 27 Apr 2004 17:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIaRF-0001Tq-KF for ipsec@optimus.ietf.org; Tue, 27 Apr 2004 17:48:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03993 for ; Tue, 27 Apr 2004 17:48:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIaRB-0007XL-2k for ipsec@ietf.org; Tue, 27 Apr 2004 17:48:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIaQO-0007Pi-00 for ipsec@ietf.org; Tue, 27 Apr 2004 17:47:32 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BIaPT-0007F4-00 for ipsec@ietf.org; Tue, 27 Apr 2004 17:46:35 -0400 Received: from po2.bbn.com (po2.bbn.com [128.33.0.56]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i3RLhc7W029374; Tue, 27 Apr 2004 17:43:38 -0400 (EDT) Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by po2.bbn.com (8.10.2+Sun/8.10.2) with ESMTP id i3RLhc605834; Tue, 27 Apr 2004 17:43:38 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: <408D56BF.20601@cisco.com> References: <408D56BF.20601@cisco.com> Date: Tue, 27 Apr 2004 17:50:52 -0400 To: Brian Weis , Markku Savela From: Karen Seo Subject: Re: [Ipsec] IPsec AH and ESP -- changes Cc: kseo@bbn.com, ipsec@ietf.org 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.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Brian, Markku, George, Thank you for the comments. Is the following a correct summary? 1. It's OK for Searches (1) and (2) to NOT use protocol (AH or ESP). With unicast SAs, the receiver chooses the SPI and can have separate SPI spaces for AH and ESP if it wishes; but for multicast/etc SAs, a central Group Controller/Key server is assigning the SPIs and will ensure that there is no overlap between AH SPIs and ESP SPIs. 2. Searches (1) and (2) will be changed from "destination multicast address" to "destination address". 3. Search (3) will be changed to "Search the SAD for a match on only {SPI}, or optionally {SPI, protocol}". Thank you, Karen _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 27 15:05:26 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RM5Ojx060465; Tue, 27 Apr 2004 15:05:25 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIacV-00039f-QE; Tue, 27 Apr 2004 18:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIaSI-0001ek-FP for ipsec@optimus.ietf.org; Tue, 27 Apr 2004 17:49:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04040 for ; Tue, 27 Apr 2004 17:49:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIaSD-0007gR-QT for ipsec@ietf.org; Tue, 27 Apr 2004 17:49:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIaRG-0007YF-00 for ipsec@ietf.org; Tue, 27 Apr 2004 17:48:27 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BIaQe-0007Qa-00 for ipsec@ietf.org; Tue, 27 Apr 2004 17:47:48 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3RLkSp14275 for ; Tue, 27 Apr 2004 17:46:55 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3RJ2G9Z016815 for ; Tue, 27 Apr 2004 15:02:16 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca(205.150.200.166) by nutshell.tislabs.com via csmap (V6.0) id srcAAAhYa4NG; Tue, 27 Apr 04 15:01:47 -0400 Received: from sandelman.ottawa.on.ca (wlan237.sandelman.ca [205.150.200.237]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i3RJ3aP20383 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Tue, 27 Apr 2004 15:03:36 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3RJ3asG019968 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 27 Apr 2004 15:03:36 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3RJ3Y0J019965; Tue, 27 Apr 2004 15:03:35 -0400 To: Paul Hoffman / VPNC cc: ipsec@lists.tislabs.com Subject: Re: [Ipsec] Specification of BGP IPsec policy In-Reply-To: Message from Paul Hoffman / VPNC of "Sun, 25 Apr 2004 09:39:18 PDT." References: <200404232050.i3NKo1cR015728@rs9.luxsci.com> <30647.1082908942@marajade.sandelman.ottawa.on.ca> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Tue, 27 Apr 2004 15:03:34 -0400 Message-ID: <19963.1083092614@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , -----BEGIN PGP SIGNED MESSAGE----- >>>>> "VPNC" == VPNC writes: >> Okay, let's start at the top. >> >> which authentication mechanism scales to thousands of BGP peering >> partners? and if you say X.509, then please let us know which CA >> to buy. VPNC> One doesn't need to "buy" CAs; for example, there is SimpleCA VPNC> from the VPN Consortium which is freeware (see VPNC> ). Other freeware CAs exist as VPNC> well. Paul, you missed the point. It isn't the software. Which *certificate* authority should all BGP speaking organizations sign up for? In a well top-down ordered Internet everyone would peer at IXs, and it would be clear that the IX could be the CA. Life isn't so simple. VPNC> The problem is not in issuing the certs, it is in getting the VPNC> authorization policies into the IPsec systems. Some IPsec VPNC> implementations have a "accept anyone who has a cert issued by VPNC> this particular CA into this this policy" setting, but many right, so assume that that this policy exists everywhere. (If Cisco and Juniper had such a policy, then that would be 99% of BGP speakers. A Linux router running Openswan can deal with such a policy too) It still doesn't answer the question of which root certificate will work. - -- ] 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 iQCVAwUBQI6uhIqHRg3pndX9AQEe4AQAukF4nTeDmQ50esyJz7nlcXFhTJ0saY4S NBB0pf2wKUPxN3FdVK9NQHlsB+WKSYQPx/qWC9wOU0fU/SVvL8zbrFkkKzjt5n1H E9ljKu/ZOKgv4GG8AiWijI129K+PH15VHNkl7qYQ2Sa4fbcCMsfiTFZicAzcNGwG wbFLQS/Jsiw= =AI0S -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 27 15:26:11 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3RMQA8N061459; Tue, 27 Apr 2004 15:26:11 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIapA-0002SY-7j; Tue, 27 Apr 2004 18:13:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIajg-0007si-PV for ipsec@optimus.ietf.org; Tue, 27 Apr 2004 18:07:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05339 for ; Tue, 27 Apr 2004 18:07:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIajc-00022C-0b for ipsec@ietf.org; Tue, 27 Apr 2004 18:07:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIaik-0001ux-00 for ipsec@ietf.org; Tue, 27 Apr 2004 18:06:31 -0400 Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx with smtp (Exim 4.12) id 1BIahu-0001ei-00 for ipsec@ietf.org; Tue, 27 Apr 2004 18:05:38 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i3RM56xo020691 for ; Tue, 27 Apr 2004 18:05:07 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id i3RM56JY020686; Tue, 27 Apr 2004 18:05:06 -0400 Received: from pkoning.equallogic.com ([172.16.1.103]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Apr 2004 18:05:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16526.55573.84822.45654@gargle.gargle.HOWL> Date: Tue, 27 Apr 2004 18:05:09 -0400 From: Paul Koning To: kseo@bbn.com Cc: ipsec@ietf.org Subject: Re: [Ipsec] IPsec AH and ESP -- changes References: <408D56BF.20601@cisco.com> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 27 Apr 2004 22:05:10.0084 (UTC) FILETIME=[B4FAC040:01C42CA3] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , >>>>> "Karen" == Karen Seo writes: Karen> Brian, Markku, George, Thank you for the comments. Is the Karen> following a correct summary? Karen> 1. It's OK for Searches (1) and (2) to NOT use protocol (AH or Karen> ESP). With unicast SAs, the receiver chooses the SPI and can Karen> have separate SPI spaces for AH and ESP if it wishes; but for Karen> multicast/etc SAs, a central Group Controller/Key server is Karen> assigning the SPIs and will ensure that there is no overlap Karen> between AH SPIs and ESP SPIs. Karen> 2. Searches (1) and (2) will be changed from "destination Karen> multicast address" to "destination address". Karen> 3. Search (3) will be changed to "Search the SAD for a match Karen> on only {SPI}, or optionally {SPI, protocol}". Perhaps more accurate would be "on only {SPI} if the receiver has chosen the SPI to maintain separate SPI spaces for AH and EPS, and on {SPI, protocol} otherwise". That makes the dependency with the implementation choice described under item 1 explicit. paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 27 18:23:58 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3S1NuuA074419; Tue, 27 Apr 2004 18:23:57 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIdfD-0004hS-JD; Tue, 27 Apr 2004 21:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIddD-0004MN-0U for ipsec@optimus.ietf.org; Tue, 27 Apr 2004 21:12:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15258 for ; Tue, 27 Apr 2004 21:12:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIdd8-0000QF-EH for ipsec@ietf.org; Tue, 27 Apr 2004 21:12:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIdc4-0000Dj-00 for ipsec@ietf.org; Tue, 27 Apr 2004 21:11:48 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIdap-00000t-00 for ipsec@ietf.org; Tue, 27 Apr 2004 21:10:31 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIdOD-0005JK-FH for ipsec@ietf.org; Tue, 27 Apr 2004 20:57:29 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 27 Apr 2004 17:57:56 -0700 Received: from cisco.com (dhcp-128-107-163-236.cisco.com [128.107.163.236]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i3S0uejO014957; Tue, 27 Apr 2004 17:56:41 -0700 (PDT) Message-ID: <408F01A4.4090809@cisco.com> Date: Tue, 27 Apr 2004 17:58:12 -0700 From: Brian Weis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Koning CC: kseo@bbn.com, ipsec@ietf.org Subject: Re: [Ipsec] IPsec AH and ESP -- changes References: <408D56BF.20601@cisco.com> <16526.55573.84822.45654@gargle.gargle.HOWL> In-Reply-To: <16526.55573.84822.45654@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Paul Koning wrote: >>>>>>"Karen" == Karen Seo writes: >>>>>> >>>>>> > > Karen> Brian, Markku, George, Thank you for the comments. Is the > Karen> following a correct summary? > > > It looks right to me. > Karen> 1. It's OK for Searches (1) and (2) to NOT use protocol (AH or > Karen> ESP). With unicast SAs, the receiver chooses the SPI and can > Karen> have separate SPI spaces for AH and ESP if it wishes; but for > Karen> multicast/etc SAs, a central Group Controller/Key server is > Karen> assigning the SPIs and will ensure that there is no overlap > Karen> between AH SPIs and ESP SPIs. > > Karen> 2. Searches (1) and (2) will be changed from "destination > Karen> multicast address" to "destination address". > > Karen> 3. Search (3) will be changed to "Search the SAD for a match > Karen> on only {SPI}, or optionally {SPI, protocol}". > >Perhaps more accurate would be "on only {SPI} if the receiver has >chosen the SPI to maintain separate SPI spaces for AH and EPS, and on >{SPI, protocol} otherwise". That makes the dependency with the >implementation choice described under item 1 explicit. > > > That should really be "on only {SPI} if the receiver has chosen to maintain a single SPI space for AH and ESP, and on {SPI, protocol} otherwise". Thanks, Brian > paul > > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec > > > -- Brian Weis Advanced Security Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 27 21:01:29 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3S41Slk085132; Tue, 27 Apr 2004 21:01:28 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIgAz-0006GH-AO; Tue, 27 Apr 2004 23:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIfrG-00041i-3N for ipsec@optimus.ietf.org; Tue, 27 Apr 2004 23:35:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21307 for ; Tue, 27 Apr 2004 23:35:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIfrC-0005Up-1J for ipsec@ietf.org; Tue, 27 Apr 2004 23:35:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIfqA-0005IM-00 for ipsec@ietf.org; Tue, 27 Apr 2004 23:34:31 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BIfpC-00055a-00 for ipsec@ietf.org; Tue, 27 Apr 2004 23:33:30 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3S3Wdp24989 for ; Tue, 27 Apr 2004 23:32:39 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3S0RPHe008011 for ; Tue, 27 Apr 2004 20:27:26 -0400 (EDT) Received: from nwkea-mail-2.sun.com(192.18.42.14) by nutshell.tislabs.com via csmap (V6.0) id srcAAANnaqCp; Tue, 27 Apr 04 20:26:34 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3S0Soms002236; Tue, 27 Apr 2004 17:28:51 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i3S0Socc029430; Tue, 27 Apr 2004 20:28:50 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i3S0Sn7K018192; Tue, 27 Apr 2004 20:28:50 -0400 (EDT) Message-Id: <200404280028.i3S0Sn7K018192@thunk.east.sun.com> From: Bill Sommerfeld To: Michael Richardson cc: Paul Hoffman / VPNC , ipsec@lists.tislabs.com Subject: Re: [Ipsec] Specification of BGP IPsec policy In-Reply-To: Your message of "Tue, 27 Apr 2004 15:03:34 EDT." <19963.1083092614@marajade.sandelman.ottawa.on.ca> Reply-to: sommerfeld@east.sun.com Date: Tue, 27 Apr 2004 20:28:49 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , > VPNC> One doesn't need to "buy" CAs; for example, there is SimpleCA > VPNC> from the VPN Consortium which is freeware (see > VPNC> ). Other freeware CAs exist as > VPNC> well. > > Paul, you missed the point. It isn't the software. > > Which *certificate* authority should all BGP speaking organizations > sign up for? In a well top-down ordered Internet everyone would peer > at IXs, and it would be clear that the IX could be the CA. Life isn't > so simple. What are the identifiers you're binding to the key with this CA? IP addresses? Then the CA delegation hierarchy should follow the address-delegation hierarchy.. IANA to regional registries to ISP's. Observation for the certificate-format-agnostic: Deploy DNSSEC covering in-addr.arpa and you might get this delegation hierarchy "for free". - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Tue Apr 27 22:45:24 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3S5jMor007638; Tue, 27 Apr 2004 22:45:23 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIhhI-0002TQ-FO; Wed, 28 Apr 2004 01:33:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIhFL-0007P6-Ph for ipsec@optimus.ietf.org; Wed, 28 Apr 2004 01:04:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25245 for ; Wed, 28 Apr 2004 01:04:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIhFG-0006ls-UD for ipsec@ietf.org; Wed, 28 Apr 2004 01:04:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIhED-0006a8-00 for ipsec@ietf.org; Wed, 28 Apr 2004 01:03:26 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BIhDG-0006F8-00 for ipsec@ietf.org; Wed, 28 Apr 2004 01:02:26 -0400 Received: from po2.bbn.com (po2.bbn.com [128.33.0.56]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i3S51x7W012220; Wed, 28 Apr 2004 01:01:59 -0400 (EDT) Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by po2.bbn.com (8.10.2+Sun/8.10.2) with ESMTP id i3S51x628681; Wed, 28 Apr 2004 01:01:59 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Wed, 28 Apr 2004 01:09:09 -0400 To: ipsec@ietf.org From: Karen Seo Cc: 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.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Ipsec] revised IPsec Architecture draft (2401bis) Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Folks, We just submitted 2401bis-02 to the IETF publications folks. I went ahead and put in the proposed mod (for AH, ESP, and 2401bis drafts) re: how to do SAD lookup in the presence of multicast SAs and incorporated the latest feedback. Several other items remain unfinished: a. Resolution on how to handle fragments on the protected side of the IPsec boundary -- We put in the proposed 3 approaches but left the MAY/SHOULD question for approaches 2 and 3 open. b. Addition of an Appendix with the rationale for (a) -- This will be based on Steve's email and the subsequent list discussion c. Resolution on how to handle ICMP -- did not put anything in in this section yet d. Completion of the Appendix with the ASN.1 for an SPD entry -- mostly done, but a few things need to be added. Please note that while Steve provided input on most of the revisions, he once again has maintained plausible deniability by going away on travel/vacation. So he did not get to review this draft. (Of course, if I'd gotten all the editing/nroffing done when I was supposed to, he'd have had a chance to review it. So this is really my fault.) Thank you, Karen _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 28 04:59:14 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SBxDlx003040; Wed, 28 Apr 2004 04:59:14 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInMn-0007mD-Dc; Wed, 28 Apr 2004 07:36:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIjw3-0002h9-QO for ipsec@optimus.ietf.org; Wed, 28 Apr 2004 03:56:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29758 for ; Wed, 28 Apr 2004 03:56:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIjvz-0004YS-3t for ipsec@ietf.org; Wed, 28 Apr 2004 03:56:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIjvM-0004F9-00 for ipsec@ietf.org; Wed, 28 Apr 2004 03:56:09 -0400 Received: from guard.arkoon.net ([62.161.237.193] helo=akguard.arkoon.net) by ietf-mx with esmtp (Exim 4.12) id 1BIjtV-0003qS-00 for ipsec@ietf.org; Wed, 28 Apr 2004 03:54:18 -0400 Received: (from uucp@localhost) by akguard.arkoon.net (8.12.8p1/8.12.8) id i3S7roYT012652; Wed, 28 Apr 2004 09:53:50 +0200 Received: from A by B ; Wed, 28 Apr 2004 09:53:49 +0200 In-Reply-To: <24892.1083099943@marajade.sandelman.ottawa.on.ca> To: Michael Richardson Cc: ipsec@ietf.org Subject: Re: [Ipsec] VID for nat traversal MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: "Mathieu Lafon" Date: Wed, 28 Apr 2004 09:53:46 +0200 X-MIMETrack: S/MIME Sign by Notes Client on mathieu lafon/Arkoon(Release 6.0.2CF1|June 9, 2003) at 28/04/2004 09:53:57, Serialize by Notes Client on mathieu lafon/Arkoon(Release 6.0.2CF1|June 9, 2003) at 28/04/2004 09:53:57, Serialize complete at 28/04/2004 09:53:58, S/MIME Sign failed at 28/04/2004 09:53:58: Cl? chiffr?e introuvable, Serialize by Router on arkoon-mail.arkoon.net/Arkoon(Release 6.0.2CF1|June 9, 2003) at 28/04/2004 09:53:49, Serialize complete at 28/04/2004 09:53:49 Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Openswan (and others FreeS/WAN forks) support following VIDs : md5("draft-ietf-ipsec-nat-t-ike-00") md5("draft-ietf-ipsec-nat-t-ike-01") no port floating NAT-D 130, NAT-OA 131, UDP-Tunnel 61443, UDP-Transport 61443 md5("draft-ietf-ipsec-nat-t-ike-02") md5("draft-ietf-ipsec-nat-t-ike-02\n") [1] md5("draft-ietf-ipsec-nat-t-ike-03") port floating (udp/4500) NAT-D 130, NAT-OA 131, UDP-Tunnel 61443, UDP-Transport 61443 The code for following drafts (NAT-D 15, NAT-OA 16, UDP-Tunnel 3, UDP-Transport 4) is in the code but not enabled by default because we have no official VID to negociate it. I use md5("Testing NAT-T RFC") to test it but it's not sent during negociation. [1]: http://www.sandelman.ottawa.on.ca/ipsec/2002/04/msg00233.html -- Mathieu Lafon - Arkoon Network Security _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 28 05:05:18 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SC5Dmx004225; Wed, 28 Apr 2004 05:05:14 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInNQ-00083j-Hd; Wed, 28 Apr 2004 07:37:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIlJ8-0002ps-Kc for ipsec@optimus.ietf.org; Wed, 28 Apr 2004 05:24:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02321 for ; Wed, 28 Apr 2004 05:24:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIlJ3-0001CX-73 for ipsec@ietf.org; Wed, 28 Apr 2004 05:24:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIlI7-0000yM-00 for ipsec@ietf.org; Wed, 28 Apr 2004 05:23:44 -0400 Received: from smtp2.completel.net ([195.167.195.197]) by ietf-mx with esmtp (Exim 4.12) id 1BIlHH-0000Wb-00 for ipsec@ietf.org; Wed, 28 Apr 2004 05:22:51 -0400 Received: from smtp.netasq.com (netasq.netasq.com [213.30.137.178] (may be forged)) by smtp2.completel.net (8.12.8/8.12.8) with ESMTP id i3S9MPPf006530 for ; Wed, 28 Apr 2004 11:22:25 +0200 Received: from netasq.com by netasq.com (8.12.11/8.12.3) id i3S9MKbh021647 for ipsec@ietf.org; Wed, 28 Apr 2004 11:22:20 +0200 (CEST) Date: Wed, 28 Apr 2004 11:22:20 +0200 From: VANHULLEBUS Yvan To: ipsec@ietf.org Subject: Re: [Ipsec] VID for nat traversal Message-ID: <20040428092220.GA19717@yvan.netasq.int> References: <20040427192757.GA760706@jurassic.eng.sun.com> <5.2.1.1.0.20040427232844.02bc5d30@dfintra.f-secure.com> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline In-Reply-To: <5.2.1.1.0.20040427232844.02bc5d30@dfintra.f-secure.com> User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. I worked on this problem on Apple's implementation of NAT-T for KAME stack, here are comments based on my work: On Tue, Apr 27, 2004 at 11:41:34PM +0200, Joern Sierwald wrote: > overview: >=20 > -00 [...] >=20 > -01 >=20 > editorial changes to -00 > VID: MD5 hash of "draft-ietf-ipsec-nat-t-ike-00" - ["4485152d 18b6bbcd=20 > 0be8a846 9579ddcc"] (sic!) First version, with two matching hashes. > -02 >=20 > floats to port 4500 > one OA payload > NAT-D 130, NAT-OA 131, UDP-Tunnel 61443, UDP-Transport 61443 > VID: MD5 hash of "draft-ietf-ipsec-nat-t-ike-02" - ["90cb8091 3ebb696e=20 > 086381b5 ec427b1f"] >=20 > -03 >=20 > same as -02, repost, VID changes. > VID: MD5 hash of "draft-ietf-ipsec-nat-t-ike-03" - ["7d9419a6 5310ca6f=20 > 2c179d92 15529d56"] Second version, also with two matching hashes....=20 > -04 [....] >=20 > -05 [....] >=20 > -06, -07, -08 >=20 > I have read them and found only editorial changes. Third version (well, version 04 is not exactly the same, but I guess an implementation of this version should work with an implementation of 05-08 versions...), with hashes problems..... > Your plan > >1)"draft-ietf-ipsec-nat-t-ike-02" - > >["90cb8091 3ebb696e 086381b5 ec427b1f"])" > can't work, as draft -02 is not compatible with drafts -04 and higher at= =20 > all. > Assuming you implement the -08. It is necessary to know which ones of the three "major versions" are implemented, and to use only the corresponding Vid hashes. If an implementation only support 05-08 drafts, it MUST NOT send/matches Vids for older drafts !!! > >md5("draft-ietf-ipsec-nat-t-ike-08") > will be a problem after 10 July 2004 when -09 will be released, as a repo= st. > Then people with md5("draft-ietf-ipsec-nat-t-ike-09") won't interoperate= =20 > with your > md5("draft-ietf-ipsec-nat-t-ike-08") They may: On my modified racoon, I added all hashes of versions which are supported, including olders. Let's says my modified racoon (patches avaiable on kame's mailing list, if someone is interested....), which supports all drafts (so =66rom 00 to 08 today) negociates with an implementation which implemented draft 07. As an responder, racoon will match md5("draft-ietf-ipsec-nat-t-ike-07"), will "know" that hash refers to the "third major implementation", will send back the same VId, and everything will work ok. As an initiator, racoon will send all NATT VIds it has (so from md5("draft-ietf-ipsec-nat-t-ike-00") to md5("draft-ietf-ipsec-nat-t-ike-08"), and also md5("draft-ietf-ipsec-nat-t-ike")). The remote IKE daemon will match md5("draft-ietf-ipsec-nat-t-ike-07"), will just discard others unknown VIds, will send the same hash, and it will work. So if another implementation is released tomorrow which support draft 09, it "just" has to also know Vids for drafts 04-08 (older drafts is another problem).... The only remaining problem is when both initiator and responder supports various drafts. My solution was to send the latest one first, and to select the first received if more than one matches.... > md5("draft-ietf-ipsec-nat-t-ike-05") seems practical to me, but not "good= ". > I will include that in our product anyway. I still hate myself for the=20 > ".txt" incident. > For the record, that'd be 80d0bb3def54565ee84645d4c85ce3ee Is that '.txt' version released in a "public" version ? (Well, my real question is: shall we add this VId to other products, for compatibility reasons ?) > md5("RFC NATT"). I like that one. or md5("RFC NAT-T"). or=20 > md5("draft-ietf-ipsec-nat-t-ike"). > Will be a big problem if somebody DOES change the draft again, obviously. Yes.... I wasn't sure to use md5("draft-ietf-ipsec-nat-t-ike"), I must have found it in another implementation (but I don't remember which one !). md5("RFC XXXX") would also be a big problem if another extension uses the same VId mechanism to negociate and comes to the same statement of "waiting for an RFC number"..... Regards, VANHULLEBUS Yvan. --17pEHd4RhPHOinZp Content-Type: application/pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIJNwYJKoZIhvcNAQcCoIIJKDCCCSQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BoMwggZ/MIIFZ6ADAgECAgpwxrFIFmvykFnxMA0GCSqGSIb3DQEBBAUAMIGRMQswCQYDVQQG EwJGUjENMAsGA1UECBMETm9yZDEaMBgGA1UEBxMRVmlsbGVuZXV2ZSBkJ0FzY3ExLjAsBgNV BAoTJU5FVEFTUSAtIFNlY3VyZSBJbnRlcm5ldCBDb25uZWN0aXZpdHkxJzAlBgNVBAsTHk5F VEFTUSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDAzMjUwODU3NDlaFw0wNjAzMjUw ODU3NDlaMIHYMQswCQYDVQQGEwJGUjENMAsGA1UECBMETm9yZDEuMCwGA1UEChMlTkVUQVNR IC0gU2VjdXJlIEludGVybmV0IENvbm5lY3Rpdml0eTEnMCUGA1UECxMeTkVUQVNRIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MRowGAYDVQQHExFWaWxsZW5ldXZlIGQnQXNjcTEZMBcGA1UE AxMQeXZhbiBWQU5IVUxMRUJVUzEqMCgGCSqGSIb3DQEJARYbeXZhbi52YW5odWxsZWJ1c0Bu ZXRhc3EuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuNS8o61MnCJitTjl /bXnu0RRS3oer9xzJmStIVuL9CN1+44K4lbiiq6UPirD8QmBrfQILctm+dzADDjFWBSyVyEG nXRnwFkyRkbn1oT1E31GoDF6k4p6l7d1/d6ppvNVN1lX7bCriTPv3CIuoXkwkKgDc2caZdlO fFXKIP5bR+gBjsDl4qhRU0vQkPEVPvlBxf50kjNHwi0Ha3jJ58NCrY1qFRPReUfWBCbTnv63 BRkUjsQHItuPzM68j8v3z2vXr9C88Vg+reBJY2E6kJO5i1aDBaY8WC2w8onVwTsB2xaBiWik QZCqXuvgGyMNfZxIu1lEFsrDDpJJmWlUJhYIcwIDAQABo4ICjjCCAoowDAYDVR0TAQH/BAIw ADAdBgNVHQ4EFgQUKiRG/TTaJ1HQAyaP8MWoo3Xq6S8wgb4GA1UdIwSBtjCBs4AUJyrrHdlE 2joXc2oJICDJJaj5f7KhgZekgZQwgZExCzAJBgNVBAYTAkZSMQ0wCwYDVQQIEwROb3JkMRow GAYDVQQHExFWaWxsZW5ldXZlIGQnQXNjcTEuMCwGA1UEChMlTkVUQVNRIC0gU2VjdXJlIElu dGVybmV0IENvbm5lY3Rpdml0eTEnMCUGA1UECxMeTkVUQVNRIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5ggEAMA4GA1UdDwEB/wQEAwIF4DARBglghkgBhvhCAQEEBAMCBaAwKwYJKwYBBAGC NxQCBB4eHABTAG0AYQByAHQAYwBhAHIAZABMAG8AZwBvAG4wLAYDVR0lAQH/BCIwIAYIKwYB BQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3FAICMCsGA1UdEQQkMCKgIAYKKwYBBAGCNxQCA6AS DBB5dmFudkBuZXRhc3EuY29tMIHNBgNVHR8EgcUwgcIwWqBYoFaGVGxkYXA6Ly9wa2kubmV0 YXNxLmNvbS9jbj1md2NhLG91PWNhcyxvPW5ldGFzcSxkYz1mcj9jZXJ0aWZpY2F0ZVJldm9j YXRpb25MaXN0O2JpbmFyeTA4oDagNIYyaHR0cDovL2ludHJhbmV0Lm5ldGFzcS5jb20vaW50 cmFuZXQvcGtpL25ldGFzcS5jcmwwKqAooCaGJGh0dHA6Ly93d3cubmV0YXNxLmNvbS9wa2kv bmV0YXNxLmNybDAfBglghkgBhvhCAQ0EEhYQVXNlciBDZXJ0aWZpY2F0ZTANBgkqhkiG9w0B AQQFAAOCAQEAeG8YJRX/hhS/PpAtfmJ3ftfZYaYNIahbrJhKlGrM8xk78lpdwpPEexoMCd2h qoF4MAP3Ixnfx4CuDw4YDUPa6+NtJ8xPl/n4/1IieEgY2RUNrTM1lTc227L5VzkgwIIzVrDV 75utFlmDlZMXGKB6sr1CJuxy/OIDMfV2SpwWsJQ0vliAoPKQpx0FpKEBqnidN9RPjTClIp6w m7VqV/pxwulrC0DYwIagveEtTKOBvHiZ1v09Qz+gbEa35A+HXKKui2h6gwSUAaMOD6AJbwPC OksjXxPYas1eBUu0RXPhZu5LqWvk8DUDO4MI0Repws9G21PLe1QTBPfAgxRNJ6pEATGCAnww ggJ4AgEBMIGgMIGRMQswCQYDVQQGEwJGUjENMAsGA1UECBMETm9yZDEaMBgGA1UEBxMRVmls bGVuZXV2ZSBkJ0FzY3ExLjAsBgNVBAoTJU5FVEFTUSAtIFNlY3VyZSBJbnRlcm5ldCBDb25u ZWN0aXZpdHkxJzAlBgNVBAsTHk5FVEFTUSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIKcMax SBZr8pBZ8TAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA0MDQyODA5MjIyMFowIwYJKoZIhvcNAQkEMRYEFKEUKvH+8sp0AbeLe5u8 sc5BA92GMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIB ABd4Ciuh/bUxmEG8H9cQPeAa5NuqRgY/b7nLwGh2a8jj79G9Szsq1WEf1zqC5SNSXs1VLGut TPlai24hXQShqymIoH6nYTGmZENj/6kmbpCjn2k4DyYWRntq/1eNELD3Qw8sz7qv6DfO/zx5 No2VBYS/2+XJdU8u6KU5YepBoYaknlm/XL4qwz36+ADZBgsobzgviOaqHHc7C2mvN7QtU+qj A5VMV1GWF9BIQppKSnscckZIdE3BLWM6dxjnu4EjguJpDwvXD9cf3UaLQYU8jzx1HVaCBKq3 0Rw9yi4huURJ/c1HPOZTG6MAxbEwNWBco/O/CJSgIP1ZHf+Tsw3CpUI= --17pEHd4RhPHOinZp-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 28 06:10:29 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SDASh2007806; Wed, 28 Apr 2004 06:10:29 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIoap-0006mC-3p; Wed, 28 Apr 2004 08:55:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInnn-0005G0-HF for ipsec@optimus.ietf.org; Wed, 28 Apr 2004 08:04:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09584 for ; Wed, 28 Apr 2004 08:04:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BInnm-0003zo-JP for ipsec@ietf.org; Wed, 28 Apr 2004 08:04:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BInmd-0003cH-00 for ipsec@ietf.org; Wed, 28 Apr 2004 08:03:24 -0400 Received: from ip212-226-138-153.adsl.kpnqwest.fi ([212.226.138.153] helo=mail.kivinen.iki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BInlt-0003H3-00 for ipsec@ietf.org; Wed, 28 Apr 2004 08:02:37 -0400 Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i3SC2VfK005244 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 28 Apr 2004 15:02:31 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.12.10/8.12.6/Submit) id i3SC2UiH005241; Wed, 28 Apr 2004 15:02:30 +0300 (EEST) 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: <16527.40278.446526.972317@fireball.acr.fi> Date: Wed, 28 Apr 2004 15:02:30 +0300 From: Tero Kivinen To: Chris Stillson Cc: ipsec@ietf.org Subject: Re: [Ipsec] VID for nat traversal In-Reply-To: <20040427192757.GA760706@jurassic.eng.sun.com> References: <20040427192757.GA760706@jurassic.eng.sun.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 14 min X-Total-Time: 93 min X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Chris Stillson writes: > The one thing that bothers me is that I started my implementation of > of draft 6 or 7, and there was no mention of using a hash of the > draft, just RFC XXXX to be replaced the actual number. So all of a > sudden, we are using drafts that shouldn't be used as any kind of > standard. No big deal, but maybe that language should not have been > removed from the later drafts. The reason why there was no VID was that NOBODY WAS SUPPOSED TO IMPLEMENT THAT DRAFT. The numbers mentioned in the draft was not yet officially allocated from the IANA, but was simply next available numbers at that time. The numbers WILL change when they are officially allocated, as those numbers have already been reserved, thus we cannot use the same numbers. I made mistake and added the official numbers and removed the VID because I tought that this is going to be the last version and it will be out as an RFC soon, thus we will get the proper VID and official numbers soon. That didn't happen, thus this problem come up. Anyways if you want to implement the NAT-T now, implement it as specified in the draft-ietf-ipsec-nat-t-ike-03.txt along with the VID found there, and with the private address space numbers. There should not be any real changes to the protocol since. The final payload etc numbers will be different, and the VID will be different, but 03 is the version you should be using. > As I see it we have 3 choices for vendor id > 1)"draft-ietf-ipsec-nat-t-ike-02" - > ["90cb8091 3ebb696e 086381b5 ec427b1f"])" > Windows clients will dominate this space. We should probably make sure > that we work with windows, although I am not too sure how compatible > draft 2 is with draft 8 You should also understand 03 VID: "draft-ietf-ipsec-nat-t-ike-03" "7d9419a6 5310ca6f 2c179d92 15529d56" If I remember correctly the protocols are still same. > 2)md5("draft-ietf-ipsec-nat-t-ike-05") or > md5("draft-ietf-ipsec-nat-t-ike-08") > that would seem to be logical for anyone who's implementation is up to > date with the spec No, you SHOULD NOT use those numbers, nor those drafts as the numbers currently defined there overlaps some other use. > 3) md5("RFC XXXX") for the overly literal (myself :) ) or perhaps > something different? No. Should wait until we really have the RFC number available and official numbers allocated. It should now be so far in the RFC process, that it shouldn't take that long anymore. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 28 06:12:54 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SDCrX1008066; Wed, 28 Apr 2004 06:12:54 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIoav-0006o6-IX; Wed, 28 Apr 2004 08:55:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInrP-0006O1-TQ for ipsec@optimus.ietf.org; Wed, 28 Apr 2004 08:08:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09932 for ; Wed, 28 Apr 2004 08:08:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BInrO-0005Ip-Ui for ipsec@ietf.org; Wed, 28 Apr 2004 08:08:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BInqI-0004we-00 for ipsec@ietf.org; Wed, 28 Apr 2004 08:07:10 -0400 Received: from ip212-226-138-153.adsl.kpnqwest.fi ([212.226.138.153] helo=mail.kivinen.iki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BInpL-0004dG-00 for ipsec@ietf.org; Wed, 28 Apr 2004 08:06:11 -0400 Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i3SC65fK005276 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 28 Apr 2004 15:06:05 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.12.10/8.12.6/Submit) id i3SC64qr005273; Wed, 28 Apr 2004 15:06:04 +0300 (EEST) 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: <16527.40492.492637.72108@fireball.acr.fi> Date: Wed, 28 Apr 2004 15:06:04 +0300 From: Tero Kivinen To: Joern Sierwald Cc: Chris Stillson , ipsec@ietf.org Subject: Re: [Ipsec] VID for nat traversal In-Reply-To: <5.2.1.1.0.20040427232844.02bc5d30@dfintra.f-secure.com> References: <20040427192757.GA760706@jurassic.eng.sun.com> <5.2.1.1.0.20040427232844.02bc5d30@dfintra.f-secure.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 2 min X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Joern Sierwald writes: > floats to port 4500 > two OA payloads > NAT-D 15, NAT-OA 16, UDP-Tunnel 3, UDP-Transport 4 > VID of unknown value Forgot that second OA payload, so there is some changes in the protocol. > md5("RFC NATT"). I like that one. or md5("RFC NAT-T"). or > md5("draft-ietf-ipsec-nat-t-ike"). > Will be a big problem if somebody DOES change the draft again, obviously. DO NOT use the numbers specified in the drafts from the IANA allocated area. The NAT-D and NAT-OA payload numbers WILL change, as the payload number 15 and 16 are already taken by RFC 3547. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 28 08:36:18 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SFaFk5019246; Wed, 28 Apr 2004 08:36:17 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqlm-0007Z4-T3; Wed, 28 Apr 2004 11:14:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqBK-0001ej-81 for ipsec@optimus.ietf.org; Wed, 28 Apr 2004 10:37:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18591 for ; Wed, 28 Apr 2004 10:36:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIqAu-0002IM-8y for ipsec@ietf.org; Wed, 28 Apr 2004 10:36:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIpw0-0000EK-00 for ipsec@ietf.org; Wed, 28 Apr 2004 10:21:13 -0400 Received: from rs9.luxsci.com ([66.216.98.59]) by ietf-mx with esmtp (Exim 4.12) id 1BIpvZ-0000Al-00 for ipsec@ietf.org; Wed, 28 Apr 2004 10:20:46 -0400 Received: from rs9.luxsci.com (localhost [127.0.0.1]) by rs9.luxsci.com (8.12.11/8.12.10) with ESMTP id i3SEKCHn015955 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 28 Apr 2004 09:20:12 -0500 Received: (from root@localhost) by rs9.luxsci.com (8.12.11/8.12.10/Submit) id i3SEK3TI015884; Wed, 28 Apr 2004 14:20:03 GMT Message-Id: <200404281420.i3SEK3TI015884@rs9.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Wed, 28 Apr 2004 14:20:02 +0000 From: "William Dixon" To: "'Tero Kivinen'" , "'Joern Sierwald'" Cc: "'Chris Stillson'" , Subject: RE: [Ipsec] VID for nat traversal Date: Wed, 28 Apr 2004 10:18:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <16527.40492.492637.72108@fireball.acr.fi> X-Lux-Comment: LuxSci remailer message ID code - 1083162002-7937996.67242455 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Tero, what is the schedule now for getting the IKE NAT-T & UDP-ESP drafts to RFC ? > -----Original Message----- > From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org] On > Behalf Of Tero Kivinen > Sent: Wednesday, April 28, 2004 8:06 AM > To: Joern Sierwald > Cc: Chris Stillson; ipsec@ietf.org > Subject: Re: [Ipsec] VID for nat traversal > > Joern Sierwald writes: > > floats to port 4500 > > two OA payloads > > NAT-D 15, NAT-OA 16, UDP-Tunnel 3, UDP-Transport 4 VID of unknown > > value > > Forgot that second OA payload, so there is some changes in > the protocol. > > > md5("RFC NATT"). I like that one. or md5("RFC NAT-T"). or > > md5("draft-ietf-ipsec-nat-t-ike"). > > Will be a big problem if somebody DOES change the draft > again, obviously. > > DO NOT use the numbers specified in the drafts from the IANA > allocated area. The NAT-D and NAT-OA payload numbers WILL > change, as the payload number 15 and 16 are already taken by RFC 3547. > -- > kivinen@safenet-inc.com > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 28 08:39:36 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SFdYVU019454; Wed, 28 Apr 2004 08:39:35 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqmK-0007dI-N8; Wed, 28 Apr 2004 11:15:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqHL-0003TB-NI for ipsec@optimus.ietf.org; Wed, 28 Apr 2004 10:43:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19224 for ; Wed, 28 Apr 2004 10:42:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIqGw-0003J3-0P for ipsec@ietf.org; Wed, 28 Apr 2004 10:42:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIqES-0002rZ-00 for ipsec@ietf.org; Wed, 28 Apr 2004 10:40:18 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BIqCN-0002RL-00 for ipsec@ietf.org; Wed, 28 Apr 2004 10:38:07 -0400 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3SEbFp29665 for ; Wed, 28 Apr 2004 10:37:15 -0400 (EDT) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BIpzs-0004JS-Eo; Wed, 28 Apr 2004 10:25:12 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , ipsec mailing list , ipsec chair , ipsec chair Message-Id: Date: Wed, 28 Apr 2004 10:25:12 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Ipsec] Protocol Action: 'Negotiation of NAT-Traversal in the IKE' to Proposed Standard Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , The IESG has approved the following document: - 'Negotiation of NAT-Traversal in the IKE ' as a Proposed Standard This document is the product of the IP Security Protocol Working Group. The IESG contact persons are Russ Housley and Steve Bellovin. Technical Summary This document describes how to detect one or more network address translation devices (NATs) between IPsec hosts, and how to negotiate the use of UDP encapsulation of the IPsec packets through the NAT boxes in Internet Key Exchange (IKE) protocol. Working Group Summary The IPsec Working Group came to consensus on this document. Protocol Quality This document was reviewed by Russell Housley for the IESG. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 28 08:42:38 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SFgaSU019708; Wed, 28 Apr 2004 08:42:37 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqmj-0007kS-Fz; Wed, 28 Apr 2004 11:15:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqWH-0005Wr-1Y for ipsec@optimus.ietf.org; Wed, 28 Apr 2004 10:58:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20195 for ; Wed, 28 Apr 2004 10:58:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIqVr-0004eu-1v for ipsec@ietf.org; Wed, 28 Apr 2004 10:58:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIqV1-0004XP-00 for ipsec@ietf.org; Wed, 28 Apr 2004 10:57:24 -0400 Received: from [192.43.161.6] (helo=max.safenet-inc) by ietf-mx with esmtp (Exim 4.12) id 1BIqTm-0004Dg-00 for ipsec@ietf.org; Wed, 28 Apr 2004 10:56:06 -0400 Received: by MAX with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Apr 2004 10:55:26 -0400 Message-ID: <4516D26F7B3DD611BD310002A507C88B032801EC@MAX> From: Bill Becker To: "'William Dixon'" , "'Chris Stillson'" , ipsec@ietf.org Subject: RE: [Ipsec] VID for nat traversal Date: Wed, 28 Apr 2004 10:55:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , SafeNet's currently released VPN clients also use the -02 vendor ID. Whenever this issue comes up, we send the below explanation to help ensure interoperability... Regards, Bill 4.) NAT-T VID Our version 8.0 client has support for draft -01: draft-ietf-ipsec-nat-t-ike-01.txt draft-ietf-ipsec-udp-encaps-01.txt Field testing of draft -01 has proven that it only works with certain NATdevices. Hence the move to draft 02 and 03. For backward compatibility with products that implemented NAT-T-01, SoftRemote will continue to send and accept the NAT-T-01 vendor ID: SafeNet SoftRemote v9.0 supports: draft-ietf-ipsec-nat-t-ike-02.txt ** same as -03 except for the Vendor ID. draft-ietf-ipsec-udp-encaps-03.txt We strongly recommend implementing -02 / -03 instead of -01. As described below the only difference between nat-t-ike-02 and nat-t-ike-03 is the value of the vendor ID value. SafeNet's implementation is to send, and expect receipt of, the nat-t-ike-02 vendor ID value. Here are the minutes from the IETF meeting in which the situation was discussed: http://www.vpnc.org/ietf-ipsec/mail-archive/msg04389.html An excerpt from the minutes: "Draft-03 versions submitted to update the author list and make some clarifications. The draft-ietf-ipsec-nat-t-ike-03.txt did change the Vendor-ID string to represent draft-03, although there are no changes that would make it interoperably different from draft-02, except the vendor ID. Vendors, which have implemented draft-02, should accept draft-02's vendor ID. If recent implementation was done according to draft-03, send the vendor ID for draft 02 as well to interoperate. Note however, the vendor ID string in draft 02 was wrong for the hash value. Implementers should use the MD5 hash hex value, not the string to interoperate with other implementations." The actual -02 draft is hard to find on the internet. Below is the vendor ID section from draft-ietf-ipsec-nat-t-ike-02.txt. As described above, make sure the actual hex value is used. "3.1. Detecting support of Nat-Traversal The NAT-Traversal capability of the remote host is determined by an exchange of vendor strings; in Phase 1 two first messages, the vendor id payload for this specification of NAT-Traversal (MD5 hash of "draft- ietf-ipsec-nat-t-ike-02" - ["90cb8091 3ebb696e 086381b5 ec427b1f"]) MUST be sent if supported (and it MUST be received by both sides) for the NAT-Traversal probe to continue." Bill Becker Technology Manager SafeNet, Inc. 4690 Millennium Drive Belcamp, MD 21017 (443) 327-1335 bbecker@safenet-inc.com www.safenet-inc.com ----------------------------------------------- The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it -----Original Message----- From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org] On Behalf Of William Dixon Sent: Tuesday, April 27, 2004 12:35 PM To: 'Chris Stillson'; ipsec@ietf.org Subject: RE: [Ipsec] VID for nat traversal Chris, the earlier drafts provided the vendor ID being MD5 of the draft name. If you support multiple versions, you include multiple vendor IDs. >From draft-ietf-ipsec-nat-t-ike-02.txt: "the vendor id payload for this specification of NAT-Traversal (MD5 hash of "draft- ietf-ipsec-nat-t-ike-02" - ["90cb8091 3ebb696e 086381b5 ec427b1f"])" Windows NAT-T implementation so far uses draft-02 vendor ID. Here is the Win2k & XP NAT-T update info. http://support.microsoft.com/default.aspx?scid=kb;en-us;818043 > -----Original Message----- > From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org] On > Behalf Of Chris Stillson > Sent: Tuesday, April 27, 2004 11:37 AM > To: ipsec@ietf.org > Subject: [Ipsec] VID for nat traversal > > Just wondering what different implementations use for the VID > to signify an implementation supports nat-t (since there is > no rfc # yet) > > By my calculations the md5 hash of "RFC XXXX" is > 810fa565f8ab14369105d706fbd57279, which seems to make as much > sense as anything at this point. But, other people may have a > different solution which will make interoperability tricky :) > So, before releasing anything to the public, I would like to > get this issue sorted out. > > > chris stillson > IPSEC crypto monkey > x82477 > > Note: Preceding comments written by an engineer. There is > nothing to read into them. He really has no hidden motives or agendas. > > 1.Right Understanding 2.Right Thoughts 3.Right Speech 4.Right > Action 5.Right Livelihood 6.Right Effort 7.Right Mindfulness > 8.Right Concentration --Please inform author if he has > forgotten about any of these > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 28 09:49:09 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SGn91s024450; Wed, 28 Apr 2004 09:49:09 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIs8J-0004Tr-7z; Wed, 28 Apr 2004 12:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrwy-00021I-0E for ipsec@optimus.ietf.org; Wed, 28 Apr 2004 12:30:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26615 for ; Wed, 28 Apr 2004 12:30:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIrwv-000583-0Q for ipsec@ietf.org; Wed, 28 Apr 2004 12:30:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIrvz-00051j-00 for ipsec@ietf.org; Wed, 28 Apr 2004 12:29:20 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1BIrvA-0004qv-00 for ipsec@ietf.org; Wed, 28 Apr 2004 12:28:28 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3SGRu6b020778; Wed, 28 Apr 2004 09:27:56 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i3SGRt4F001305; Wed, 28 Apr 2004 10:27:56 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i3SGRKhf007749; Wed, 28 Apr 2004 11:27:20 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i3SGRIaB007748; Wed, 28 Apr 2004 11:27:18 -0500 (CDT) Date: Wed, 28 Apr 2004 11:27:18 -0500 From: Nicolas Williams To: William Dixon Cc: "'Tero Kivinen'" , "'Joern Sierwald'" , "'Chris Stillson'" , ipsec@ietf.org Subject: Re: [Ipsec] VID for nat traversal Message-ID: <20040428162718.GZ22519@binky.central.sun.com> Mail-Followup-To: William Dixon , 'Tero Kivinen' , 'Joern Sierwald' , 'Chris Stillson' , ipsec@ietf.org References: <16527.40492.492637.72108@fireball.acr.fi> <200404281420.i3SEK3TI015884@rs9.luxsci.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404281420.i3SEK3TI015884@rs9.luxsci.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , On Wed, Apr 28, 2004 at 10:18:08AM -0400, William Dixon wrote: > Tero, what is the schedule now for getting the IKE NAT-T & UDP-ESP drafts to > RFC ? I just saw the IESG announcement that draft-ietf-ipsec-nat-t-ike-08.txt has been moved to Proposed Standard. So it looks like "draft-ietf-ipsec-nat-t-ike-08" will make a good VID :) And it should be possible to get an RFC number allocated for it now, no? Nico -- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 28 10:15:06 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SHF3H8027853; Wed, 28 Apr 2004 10:15:05 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsUX-0000uG-RO; Wed, 28 Apr 2004 13:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsHL-0006Om-F6 for ipsec@optimus.ietf.org; Wed, 28 Apr 2004 12:51:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28191 for ; Wed, 28 Apr 2004 12:51:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsHI-0006OI-A5 for ipsec@ietf.org; Wed, 28 Apr 2004 12:51:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsGR-0006Lf-00 for ipsec@ietf.org; Wed, 28 Apr 2004 12:50:27 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BIsFh-0006JN-00 for ipsec@ietf.org; Wed, 28 Apr 2004 12:49:41 -0400 Received: from [63.202.92.148] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SGnb44024484 for ; Wed, 28 Apr 2004 09:49:38 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <4516D26F7B3DD611BD310002A507C88B032801EC@MAX> References: <4516D26F7B3DD611BD310002A507C88B032801EC@MAX> Date: Wed, 28 Apr 2004 09:49:18 -0700 To: IPsec WG From: Paul Hoffman / VPNC Subject: RE: [Ipsec] VID for nat traversal Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Given this morning's official announcement: >The IESG has approved the following document: > >- 'Negotiation of NAT-Traversal in the IKE ' > as a Proposed Standard The industry should either (a) wait for an RFC number or (b) use something now that reflects the official version that will turn into an RFC. I propose the latter. The MD5 of "draft-ietf-ipsec-nat-t-ike-08.txt" is 074d5b89c6ea3b8337b34c630cfd05f1. People who implemented earlier versions of the draft will use different vendor-IDs, which is appropriate. However, for the "final" vendor-ID, this seems good enough. Does anyone have any objection to using 0x074d5b89c6ea3b8337b34c630cfd05f1 for the vendor-ID of what will become the RFC for this document? --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 28 10:19:35 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SHJXpL028170; Wed, 28 Apr 2004 10:19:34 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsUa-0000v5-Ha; Wed, 28 Apr 2004 13:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsIJ-0006Wm-HY for ipsec@optimus.ietf.org; Wed, 28 Apr 2004 12:52:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28241 for ; Wed, 28 Apr 2004 12:52:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsIG-0006RS-Er for ipsec@ietf.org; Wed, 28 Apr 2004 12:52:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsHQ-0006PJ-00 for ipsec@ietf.org; Wed, 28 Apr 2004 12:51:28 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BIsGs-0006N3-00 for ipsec@ietf.org; Wed, 28 Apr 2004 12:50:54 -0400 Received: from [63.202.92.148] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SGooMa024539 for ; Wed, 28 Apr 2004 09:50:51 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <20040428162718.GZ22519@binky.central.sun.com> References: <16527.40492.492637.72108@fireball.acr.fi> <200404281420.i3SEK3TI015884@rs9.luxsci.com> <20040428162718.GZ22519@binky.central.sun.com> Date: Wed, 28 Apr 2004 09:50:53 -0700 To: ipsec@ietf.org From: Paul Hoffman / VPNC Subject: Re: [Ipsec] VID for nat traversal Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , At 11:27 AM -0500 4/28/04, Nicolas Williams wrote: >And it should be possible to get an RFC number allocated for it now, no? No. The RFC Editor normally only allocates RFC numbers after doing an initial review of the document, and that can take weeks or months. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 28 10:54:24 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SHsNkD031290; Wed, 28 Apr 2004 10:54:24 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIt7I-0002pb-1g; Wed, 28 Apr 2004 13:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIswv-0000S4-ON for ipsec@optimus.ietf.org; Wed, 28 Apr 2004 13:34:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01737 for ; Wed, 28 Apr 2004 13:34:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsws-0001jl-Bi for ipsec@ietf.org; Wed, 28 Apr 2004 13:34:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIsvt-0001e2-00 for ipsec@ietf.org; Wed, 28 Apr 2004 13:33:18 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1BIsuv-0001XB-00 for ipsec@ietf.org; Wed, 28 Apr 2004 13:32:17 -0400 Received: from jurassic.eng.sun.com ([129.146.83.130]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i3SHVm6b010277 for ; Wed, 28 Apr 2004 10:31:48 -0700 (PDT) Received: from jurassic.eng.sun.com (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i3SHVlmS378825 for ; Wed, 28 Apr 2004 10:31:47 -0700 (PDT) Received: (from stillson@localhost) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id i3SHVlKg378824 for ipsec@ietf.org; Wed, 28 Apr 2004 10:31:47 -0700 (PDT) Date: Wed, 28 Apr 2004 10:31:47 -0700 From: Chris Stillson To: ipsec@ietf.org Subject: RE: [Ipsec] VID for nat traversal Message-ID: <20040428173147.GA376368@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , >Paul Hoffman wrote: >The industry should either (a) wait for an RFC number or (b) use >something now that reflects the official version that will turn into >an RFC. I propose the latter. > >The MD5 of "draft-ietf-ipsec-nat-t-ike-08.txt" is >074d5b89c6ea3b8337b34c630cfd05f1. > >People who implemented earlier versions of the draft will use >different vendor-IDs, which is appropriate. However, for the "final" >vendor-ID, this seems good enough. > >Does anyone have any objection to using >0x074d5b89c6ea3b8337b34c630cfd05f1 for the vendor-ID of what will >become the RFC for this document? Generally, no. except you should drop the txt, I think i.e. md5("draft-ietf-ipsec-nat-t-ike-08"). That, and the fact that the final RFC will likely change the payload #'s for the NATD and NATOA from 15,16 to 20,21 to work with rfc3547. Or maybe they are orthoganal. Not sure yet. Personally, I have not problem with what we pick, as long as we agree. Although the point is moot if the Windows implementation does nothing. In that case, we will all do the same as them chris stillson IPSEC crypto monkey x82477 Note: Preceding comments written by an engineer. There is nothing to read into them. He really has no hidden motives or agendas. 1.Right Understanding 2.Right Thoughts 3.Right Speech 4.Right Action 5.Right Livelihood 6.Right Effort 7.Right Mindfulness 8.Right Concentration --Please inform author if he has forgotten about any of these _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 28 11:31:13 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SIVCbM034664; Wed, 28 Apr 2004 11:31:12 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItdI-0001qH-8G; Wed, 28 Apr 2004 14:18:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItYp-0000xL-Cj for ipsec@optimus.ietf.org; Wed, 28 Apr 2004 14:13:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05106 for ; Wed, 28 Apr 2004 14:13:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BItYl-0004jD-G6 for ipsec@ietf.org; Wed, 28 Apr 2004 14:13:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItY4-0004gc-00 for ipsec@ietf.org; Wed, 28 Apr 2004 14:12:45 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BItXR-0004c7-00 for ipsec@ietf.org; Wed, 28 Apr 2004 14:12:05 -0400 Received: from [63.202.92.148] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SIC0cQ033168; Wed, 28 Apr 2004 11:12:01 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <20040428173147.GA376368@jurassic.eng.sun.com> References: <20040428173147.GA376368@jurassic.eng.sun.com> Date: Wed, 28 Apr 2004 11:12:02 -0700 To: Chris Stillson , ipsec@ietf.org From: Paul Hoffman / VPNC Subject: RE: [Ipsec] VID for nat traversal Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , At 10:31 AM -0700 4/28/04, Chris Stillson wrote: >Generally, no. except you should drop the txt, I think >i.e. md5("draft-ietf-ipsec-nat-t-ike-08"). This is completely inconsequential. The only requirement is that the final value is unique. >Personally, I have not problem with what we pick, as long as we agree. Thus, my message encouraging us to pick one consistent with the spirit of vendor-IDs matching something unique. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 28 11:39:37 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SIdaVU035188; Wed, 28 Apr 2004 11:39:37 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItpn-0004cT-1r; Wed, 28 Apr 2004 14:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItgR-0002Kp-3s for ipsec@optimus.ietf.org; Wed, 28 Apr 2004 14:21:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05474 for ; Wed, 28 Apr 2004 14:21:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BItgN-00056b-6r for ipsec@ietf.org; Wed, 28 Apr 2004 14:21:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItfQ-00054g-00 for ipsec@ietf.org; Wed, 28 Apr 2004 14:20:20 -0400 Received: from noxmail.sandelman.ottawa.on.ca ([205.150.200.166]) by ietf-mx with esmtp (Exim 4.12) id 1BIteZ-00052h-00 for ipsec@ietf.org; Wed, 28 Apr 2004 14:19:27 -0400 Received: from sandelman.ottawa.on.ca (wlan237.sandelman.ca [205.150.200.237]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i3SIJGP02652 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Wed, 28 Apr 2004 14:19:16 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3SIJGsG027232 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 28 Apr 2004 14:19:16 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3SIJF95027229; Wed, 28 Apr 2004 14:19:16 -0400 To: Paul Hoffman / VPNC cc: IPsec WG Subject: Re: [Ipsec] VID for nat traversal In-Reply-To: Message from Paul Hoffman / VPNC of "Wed, 28 Apr 2004 09:49:18 PDT." References: <4516D26F7B3DD611BD310002A507C88B032801EC@MAX> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Wed, 28 Apr 2004 14:19:15 -0400 Message-ID: <27228.1083176355@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , -----BEGIN PGP SIGNED MESSAGE----- >>>>> "VPNC" == VPNC writes: >> The IESG has approved the following document: >> >> - 'Negotiation of NAT-Traversal in the IKE ' >> as a Proposed Standard VPNC> The industry should either (a) wait for an RFC number or (b) VPNC> use something now that reflects the official version that will VPNC> turn into an RFC. I propose the latter. VPNC> The MD5 of "draft-ietf-ipsec-nat-t-ike-08.txt" is VPNC> 074d5b89c6ea3b8337b34c630cfd05f1. It is my understanding that someone who implemented -03 can interop with someone who has done -08. Tero, is this wrong? That -04 thru -08 are all just editorial changes. If so, it seems that using -03 is the correct answer. - -- ] 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 iQCVAwUBQI/1ooqHRg3pndX9AQFJ/QP/f0Z5Z7A/Tq62BobHWMafwwsJMzV2wEW0 JsN3HMu+5qCCYdHZ9DVSW8tV/aWQ1nByD5BiRx7wt7kPlPBOsb01eTXgjguh661R lHKnYhzcoOgq4gdsc00U0Pcsz4R9SVYJZfXEj+vZkKz/xDgCZs87mlW5T3K4veJY ZvviN8nzwN4= =3ddt -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 28 14:08:07 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SL85DS044753; Wed, 28 Apr 2004 14:08:06 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuxU-0004pq-H0; Wed, 28 Apr 2004 15:43:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuoJ-0002Yg-T0 for ipsec@optimus.ietf.org; Wed, 28 Apr 2004 15:33:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11385 for ; Wed, 28 Apr 2004 15:33:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIuoH-0001qB-9Y for ipsec@ietf.org; Wed, 28 Apr 2004 15:33:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIunJ-0001nR-00 for ipsec@ietf.org; Wed, 28 Apr 2004 15:32:34 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BIun5-0001kj-00 for ipsec@ietf.org; Wed, 28 Apr 2004 15:32:19 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3SJVJp28291 for ; Wed, 28 Apr 2004 15:31:25 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3SJTFve023375 for ; Wed, 28 Apr 2004 15:29:15 -0400 (EDT) Received: from odin.ietf.org(132.151.1.176) by nutshell.tislabs.com via csmap (V6.0) id srcAAAdtaOCT; Wed, 28 Apr 04 15:28:40 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11213; Wed, 28 Apr 2004 15:31:01 -0400 (EDT) Message-Id: <200404281931.PAA11213@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Date: Wed, 28 Apr 2004 15:31:01 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Subject: [Ipsec] I-D ACTION:draft-ietf-ipsec-pki-profile-04.txt Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , --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 : The Internet IP Security PKI Profile of ISAKMP and PKIX Author(s) : B. Korver, E. Rescorla Filename : draft-ietf-ipsec-pki-profile-04.txt Pages : 32 Date : 2004-4-28 ISAKMP and PKIX both provide frameworks that must be profiled for use in a given application. This document provides a profile of ISAKMP and PKIX that defines the requirements for using PKI technology in the context of IPsec. The document compliments protocol specifications such as IKE, which assume the existence of public key certificates and related keying materials, but which do not address PKI issues explicitly. This document addresses those issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-pki-profile-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-pki-profile-04.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-pki-profile-04.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-4-28153203.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-pki-profile-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-pki-profile-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-28153203.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 28 14:09:50 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SL9m2j044885; Wed, 28 Apr 2004 14:09:49 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuyQ-0004wE-0x; Wed, 28 Apr 2004 15:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIup7-0002xs-Mt for ipsec@optimus.ietf.org; Wed, 28 Apr 2004 15:34:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11431 for ; Wed, 28 Apr 2004 15:34:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIup5-0001sA-4f for ipsec@ietf.org; Wed, 28 Apr 2004 15:34:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIuo6-0001of-00 for ipsec@ietf.org; Wed, 28 Apr 2004 15:33:23 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BIunA-0001lr-00 for ipsec@ietf.org; Wed, 28 Apr 2004 15:32:24 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3SJV3p28224 for ; Wed, 28 Apr 2004 15:31:29 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i3SJT9eG023350 for ; Wed, 28 Apr 2004 15:29:09 -0400 (EDT) Received: from odin.ietf.org(132.151.1.176) by nutshell.tislabs.com via csmap (V6.0) id srcAAAlha4zT; Wed, 28 Apr 04 15:28:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11195; Wed, 28 Apr 2004 15:30:55 -0400 (EDT) Message-Id: <200404281930.PAA11195@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Date: Wed, 28 Apr 2004 15:30:55 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Subject: [Ipsec] I-D ACTION:draft-ietf-ipsec-rfc2401bis-02.txt Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , --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-02.txt Pages : 78 Date : 2004-4-28 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-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-02.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-02.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-4-28153148.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-rfc2401bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-rfc2401bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-28153148.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 28 15:13:47 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SMDgQl049994; Wed, 28 Apr 2004 15:13:45 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwwN-0006bE-Am; Wed, 28 Apr 2004 17:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwiQ-0006sW-Qi for ipsec@optimus.ietf.org; Wed, 28 Apr 2004 17:35:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24738 for ; Wed, 28 Apr 2004 17:35:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIwiM-0001fj-UN for ipsec@ietf.org; Wed, 28 Apr 2004 17:35:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIwhN-0001Xb-00 for ipsec@ietf.org; Wed, 28 Apr 2004 17:34:33 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BIwgW-0001Ro-00 for ipsec@ietf.org; Wed, 28 Apr 2004 17:33:40 -0400 Received: from [63.202.92.148] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SLXUil046774; Wed, 28 Apr 2004 14:33:31 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <27228.1083176355@marajade.sandelman.ottawa.on.ca> References: <4516D26F7B3DD611BD310002A507C88B032801EC@MAX> <27228.1083176355@marajade.sandelman.ottawa.on.ca> Date: Wed, 28 Apr 2004 14:33:32 -0700 To: Michael Richardson From: Paul Hoffman / VPNC Subject: Re: [Ipsec] VID for nat traversal Cc: IPsec WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-0.5 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , At 2:19 PM -0400 4/28/04, Michael Richardson wrote: > It is my understanding that someone who implemented -03 can interop >with someone who has done -08. > > Tero, is this wrong? That -04 thru -08 are all just editorial changes. > > If so, it seems that using -03 is the correct answer. Er, why is that the "correct answer"? It doesn't matter as long as we all agree on one answer. There is no rule that says "it has to be the earliest Internet Draft name after which there were no technical changes". Any stable number that has never been used in any other context will do. We are sure that the number I gave (that corresponds to -08.txt) has not been used. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Wed Apr 28 15:14:04 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SME3ud050020; Wed, 28 Apr 2004 15:14:04 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwyH-0007WE-KN; Wed, 28 Apr 2004 17:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwoC-0001ts-0q for ipsec@optimus.ietf.org; Wed, 28 Apr 2004 17:41:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25176 for ; Wed, 28 Apr 2004 17:41:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIwo8-00025h-8R for ipsec@ietf.org; Wed, 28 Apr 2004 17:41:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIwn9-000213-00 for ipsec@ietf.org; Wed, 28 Apr 2004 17:40:32 -0400 Received: from noxmail.sandelman.ottawa.on.ca ([205.150.200.166]) by ietf-mx with esmtp (Exim 4.12) id 1BIwm8-0001xO-00 for ipsec@ietf.org; Wed, 28 Apr 2004 17:39:28 -0400 Received: from sandelman.ottawa.on.ca (wlan237.sandelman.ca [205.150.200.237]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i3SLdEP04291 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Wed, 28 Apr 2004 17:39:15 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3SLdEsG002871 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 28 Apr 2004 17:39:14 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3SLdE0h002868; Wed, 28 Apr 2004 17:39:14 -0400 To: Paul Hoffman / VPNC cc: IPsec WG Subject: Re: [Ipsec] VID for nat traversal In-Reply-To: Message from Paul Hoffman / VPNC of "Wed, 28 Apr 2004 14:33:32 PDT." References: <4516D26F7B3DD611BD310002A507C88B032801EC@MAX> <27228.1083176355@marajade.sandelman.ottawa.on.ca> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Wed, 28 Apr 2004 17:39:14 -0400 Message-ID: <2867.1083188354@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , -----BEGIN PGP SIGNED MESSAGE----- >>>>> "VPNC" == VPNC writes: >> It is my understanding that someone who implemented -03 can >> interop with someone who has done -08. >> >> Tero, is this wrong? That -04 thru -08 are all just editorial >> changes. >> >> If so, it seems that using -03 is the correct answer. VPNC> Er, why is that the "correct answer"? It doesn't matter as VPNC> long as we all agree on one answer. There is no rule that says Because a product that was built and deployed when -03 was out will have the -03 VID, and since it will continue to interop with a -08, it seems to serve no purpose to use any other ID. If we use -08 VID, then I just have to have add -08 VID to the list. There is no gain, no change in functionality over the -03 VID, just extra code. - -- ] 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 iQCVAwUBQJAkgYqHRg3pndX9AQGEJQQApSkaCLBzzxPOW3KTVFys/mis9kug2Z7U DpnVEcKRpPb3mU2+/PLXWGb9u5dMKfpCSafMKJEXO7shWZkr2HCo0fxr3X/fpxcV npu7JcW8BH0+1tdN3WkwkzHK+0iKHZdCYicD3StfGrygoIo4IbpwGlu0aTx0dXiO iz3ktdrjGOA= =stMQ -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu Apr 29 01:16:30 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3T8GTLq050680; Thu, 29 Apr 2004 01:16:29 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ6Wa-0003qI-Ni; Thu, 29 Apr 2004 04:04:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ6Pi-0002TX-Vc for ipsec@optimus.ietf.org; Thu, 29 Apr 2004 03:56:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11764 for ; Thu, 29 Apr 2004 03:56:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ6Pb-0001La-Ef for ipsec@ietf.org; Thu, 29 Apr 2004 03:56:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ6Oc-0001Bz-00 for ipsec@ietf.org; Thu, 29 Apr 2004 03:55:50 -0400 Received: from ip212-226-138-153.adsl.kpnqwest.fi ([212.226.138.153] helo=mail.kivinen.iki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BJ6Nb-0000uo-00 for ipsec@ietf.org; Thu, 29 Apr 2004 03:54:47 -0400 Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i3T7skfK015921 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 29 Apr 2004 10:54:46 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.12.10/8.12.6/Submit) id i3T7si4d015918; Thu, 29 Apr 2004 10:54:44 +0300 (EEST) 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: <16528.46276.29256.619430@fireball.acr.fi> Date: Thu, 29 Apr 2004 10:54:44 +0300 From: Tero Kivinen To: "William Dixon" Cc: "'Joern Sierwald'" , "'Chris Stillson'" , Subject: RE: [Ipsec] VID for nat traversal In-Reply-To: <200404281420.i3SEK3TI015884@rs9.luxsci.com> References: <16527.40492.492637.72108@fireball.acr.fi> <200404281420.i3SEK3TI015884@rs9.luxsci.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 1 min X-Total-Time: 1 min X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , William Dixon writes: > Tero, what is the schedule now for getting the IKE NAT-T & UDP-ESP drafts to > RFC ? IKE NAT-T protocol action announcement was just sent out. The UDP encapsulation draft still have some DISCUSS items in the IESG, so it needs some more work. I will try to do something to that today. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu Apr 29 01:16:42 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3T8Gcna050756; Thu, 29 Apr 2004 01:16:42 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ6Wi-0003rB-8c; Thu, 29 Apr 2004 04:04:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ6So-0002pI-Ks for ipsec@optimus.ietf.org; Thu, 29 Apr 2004 04:00:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12147 for ; Thu, 29 Apr 2004 04:00:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ6Sh-0001yB-0x for ipsec@ietf.org; Thu, 29 Apr 2004 04:00:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ6Rr-0001p4-00 for ipsec@ietf.org; Thu, 29 Apr 2004 03:59:12 -0400 Received: from ip212-226-138-153.adsl.kpnqwest.fi ([212.226.138.153] helo=mail.kivinen.iki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BJ6RO-0001fE-00 for ipsec@ietf.org; Thu, 29 Apr 2004 03:58:42 -0400 Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i3T7wgfK015968 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 29 Apr 2004 10:58:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.12.10/8.12.6/Submit) id i3T7wfms015965; Thu, 29 Apr 2004 10:58:41 +0300 (EEST) 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: <16528.46513.823477.91118@fireball.acr.fi> Date: Thu, 29 Apr 2004 10:58:41 +0300 From: Tero Kivinen To: Nicolas Williams Cc: William Dixon , "'Joern Sierwald'" , "'Chris Stillson'" , ipsec@ietf.org Subject: Re: [Ipsec] VID for nat traversal In-Reply-To: <20040428162718.GZ22519@binky.central.sun.com> References: <16527.40492.492637.72108@fireball.acr.fi> <200404281420.i3SEK3TI015884@rs9.luxsci.com> <20040428162718.GZ22519@binky.central.sun.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 2 min X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Nicolas Williams writes: > So it looks like "draft-ietf-ipsec-nat-t-ike-08" will make a good VID :) Not really, as the numbers in the draft cannot be used. > And it should be possible to get an RFC number allocated for it now, no? Now as it is entering the rfc-editor queue, we can quite soon get the real IANA allocated numbers, and the RFC number also. So if everybody would please wait for us to get those real numbers before doing anything. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu Apr 29 01:30:42 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3T8Ueo7056115; Thu, 29 Apr 2004 01:30:41 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ6mE-0008O8-ME; Thu, 29 Apr 2004 04:20:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ6iR-0007MS-46 for ipsec@optimus.ietf.org; Thu, 29 Apr 2004 04:16:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12889 for ; Thu, 29 Apr 2004 04:16:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ6iJ-0004bQ-ED for ipsec@ietf.org; Thu, 29 Apr 2004 04:16:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ6ho-0004Pg-00 for ipsec@ietf.org; Thu, 29 Apr 2004 04:15:40 -0400 Received: from ip212-226-138-153.adsl.kpnqwest.fi ([212.226.138.153] helo=mail.kivinen.iki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BJ6fn-00045S-00 for ipsec@ietf.org; Thu, 29 Apr 2004 04:13:35 -0400 Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i3T8DZfK016169 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 29 Apr 2004 11:13:35 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.12.10/8.12.6/Submit) id i3T8DWEN016166; Thu, 29 Apr 2004 11:13:32 +0300 (EEST) 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: <16528.47404.192488.985846@fireball.acr.fi> Date: Thu, 29 Apr 2004 11:13:32 +0300 From: Tero Kivinen To: Paul Hoffman / VPNC Cc: IPsec WG Subject: RE: [Ipsec] VID for nat traversal In-Reply-To: References: <4516D26F7B3DD611BD310002A507C88B032801EC@MAX> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 13 min X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Paul Hoffman / VPNC writes: > Does anyone have any objection to using > 0x074d5b89c6ea3b8337b34c630cfd05f1 for the vendor-ID of what will > become the RFC for this document? Yes, I have objections. As I said the numbers allocated in the draft are WRONG, they will change. We are not going to get those numbers that are currently in the draft, so nobody should put out any products using those numbers, which means that the VID should really matter. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu Apr 29 01:38:36 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3T8cZtQ058716; Thu, 29 Apr 2004 01:38:35 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ6ye-0002hR-R7; Thu, 29 Apr 2004 04:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ6qs-00019x-J0 for ipsec@optimus.ietf.org; Thu, 29 Apr 2004 04:25:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13309 for ; Thu, 29 Apr 2004 04:24:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ6qk-00069Y-PA for ipsec@ietf.org; Thu, 29 Apr 2004 04:24:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ6pn-0005zD-00 for ipsec@ietf.org; Thu, 29 Apr 2004 04:23:55 -0400 Received: from fsmail-out.f-secure.com ([193.110.109.20]) by ietf-mx with esmtp (Exim 4.12) id 1BJ6ov-0005g6-00 for ipsec@ietf.org; Thu, 29 Apr 2004 04:23:01 -0400 Received: from fsav4im2 (fsav4im2.f-secure.com [193.110.108.82]) by fsmail-out.f-secure.com (Postfix) with SMTP id 6CB9C5BAF3 for ; Thu, 29 Apr 2004 11:21:46 +0300 (EEST) Received: from [10.128.128.81]:36509 (HELO dfintra.f-secure.com) by fsav4im2.f-secure.com ([193.110.108.82]:25) (F-Secure Anti-Virus for Internet Mail 6.30.25 Release) with SMTP; Thu, 29 Apr 2004 08:22:30 -0000 Received: (qmail 2595 invoked from network); 29 Apr 2004 08:22:30 -0000 Received: from unknown (HELO fsecure-joern1.f-secure.com) (10.128.150.1) by dfintra.f-secure.com with SMTP; 29 Apr 2004 08:22:30 -0000 Message-Id: <5.2.1.1.0.20040429100534.03f4fc70@dfintra.f-secure.com> X-Sender: joern@dfintra.f-secure.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 29 Apr 2004 10:23:27 +0200 To: ipsec@ietf.org From: Joern Sierwald Subject: Re: [Ipsec] VID for nat traversal In-Reply-To: References: <24892.1083099943@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i3T8cZtQ058716 At 09:53 28.04.2004 +0200, Mathieu Lafon wrote: >Openswan (and others FreeS/WAN forks) support following VIDs : > >md5("draft-ietf-ipsec-nat-t-ike-00") >md5("draft-ietf-ipsec-nat-t-ike-01") > no port floating > NAT-D 130, NAT-OA 131, UDP-Tunnel 61443, UDP-Transport 61443 > >md5("draft-ietf-ipsec-nat-t-ike-02") >md5("draft-ietf-ipsec-nat-t-ike-02\n") [1] >md5("draft-ietf-ipsec-nat-t-ike-03") > port floating (udp/4500) > NAT-D 130, NAT-OA 131, UDP-Tunnel 61443, UDP-Transport 61443 > >The code for following drafts (NAT-D 15, NAT-OA 16, UDP-Tunnel 3, >UDP-Transport 4) is in the code but not enabled by default because >we have no official VID to negociate it. > >I use md5("Testing NAT-T RFC") to test it but it's not sent during >negociation. > >[1]: http://www.sandelman.ottawa.on.ca/ipsec/2002/04/msg00233.html > >-- >Mathieu Lafon - Arkoon Network Security I have changed the implementation of F-Secure VPN+ 5.60 to match with the system above. Tero had a very good point when he said that drafts 4 to 8 can't be used at all outside a lab, as the payload IDs are wrong. Also, as a warning or implementation note, VPN+ does not support floating the port to 4500. A negotiation must start with 4500. That's not a problem for our client, as this is an allowed behaviour, but if anybody trying to use a client which connect to port 500 first, we only answer to VID 00, not 02 or 03. (genius, isn't it). Jörn _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu Apr 29 02:38:14 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3T9cDlK080298; Thu, 29 Apr 2004 02:38:13 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ7ou-00069F-4X; Thu, 29 Apr 2004 05:27:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ7iG-0004ms-QR for ipsec@optimus.ietf.org; Thu, 29 Apr 2004 05:20:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15712 for ; Thu, 29 Apr 2004 05:20:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ7i8-00000Y-I2 for ipsec@ietf.org; Thu, 29 Apr 2004 05:20:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ7hA-0007e6-00 for ipsec@ietf.org; Thu, 29 Apr 2004 05:19:05 -0400 Received: from ip212-226-138-153.adsl.kpnqwest.fi ([212.226.138.153] helo=mail.kivinen.iki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BJ7gh-0007Tv-00 for ipsec@ietf.org; Thu, 29 Apr 2004 05:18:35 -0400 Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i3T9IYfK016762 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 29 Apr 2004 12:18:34 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.12.10/8.12.6/Submit) id i3T9IXRx016759; Thu, 29 Apr 2004 12:18:33 +0300 (EEST) 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: <16528.51305.225565.784412@fireball.acr.fi> Date: Thu, 29 Apr 2004 12:18:33 +0300 From: Tero Kivinen To: Michael Richardson Cc: Paul Hoffman / VPNC , IPsec WG Subject: Re: [Ipsec] VID for nat traversal In-Reply-To: <27228.1083176355@marajade.sandelman.ottawa.on.ca> References: <4516D26F7B3DD611BD310002A507C88B032801EC@MAX> <27228.1083176355@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 10 min X-Total-Time: 9 min X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Michael Richardson writes: > It is my understanding that someone who implemented -03 can interop > with someone who has done -08. Partly. They will interoperate if they use tunnel mode, if they try to use transport mode the -08 implementation will assume/send two NAT-OA payloads, and the -03 will only assume/send one NAT-OA payload. This will most likely cause them to fail to negotiate. Also in the -08 the NAT-OA payloads are MANDATORY if using transport mode, as in the -03 it was only SHOULD. If they only use tunnel mode then the protocol itselfs are interoperable. Of course the -03 had numbers from the private use range, the -08 have invalid numbers from the IANA allocated range. So if you need to ship your products now, and want to have RFC compatibility, then implement the latest draft and make the VID, NAT-D and NAT-OA payload numbers configurable by some config file / registry or any other wierd method. Then you can test it with other vendors, by simply agreeing on something when testing and when the final numbers will be out in month or two, you can change them easily. The UDP-encapsulated-transport and UDP-encapsulated-tunnel are probably staying same... -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu Apr 29 02:59:06 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3T9x5WX082477; Thu, 29 Apr 2004 02:59:05 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ89E-0002I2-Lw; Thu, 29 Apr 2004 05:48:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ85M-0001Q4-Te for ipsec@optimus.ietf.org; Thu, 29 Apr 2004 05:44:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16316 for ; Thu, 29 Apr 2004 05:43:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ85E-0003tw-GT for ipsec@ietf.org; Thu, 29 Apr 2004 05:43:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ84F-0003kP-00 for ipsec@ietf.org; Thu, 29 Apr 2004 05:42:55 -0400 Received: from pace.stpp.soft.net ([203.129.230.147]) by ietf-mx with esmtp (Exim 4.12) id 1BJ83C-0003Rb-00 for ipsec@ietf.org; Thu, 29 Apr 2004 05:41:50 -0400 Received: from sujit (NEETA [192.168.100.209]) by pace.stpp.soft.net (8.11.6/8.11.6) with SMTP id i3T9m1M29505 for ; Thu, 29 Apr 2004 15:18:01 +0530 Reply-To: From: "Sujit Gujar" To: Date: Thu, 29 Apr 2004 15:15:09 +0530 Message-ID: <007b01c42dce$a96f8ef0$d164a8c0@psil> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01C42DFC.C327CAF0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.3 required=5.0 tests=HTML_90_100, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,MIME_HTML_MOSTLY autolearn=no version=2.60 Subject: [Ipsec] unsubscibe Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_007C_01C42DFC.C327CAF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sujit P. Gujar. ------=_NextPart_000_007C_01C42DFC.C327CAF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

 

Sujit P. Gujar.

 <= /p>

------=_NextPart_000_007C_01C42DFC.C327CAF0-- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu Apr 29 07:20:39 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TEKbHr004027; Thu, 29 Apr 2004 07:20:38 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJC54-0002gU-S6; Thu, 29 Apr 2004 10:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBwq-0000Mk-BJ for ipsec@optimus.ietf.org; Thu, 29 Apr 2004 09:51:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02025 for ; Thu, 29 Apr 2004 09:51:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBwf-0004Yu-Il for ipsec@ietf.org; Thu, 29 Apr 2004 09:51:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBvg-0004KS-00 for ipsec@ietf.org; Thu, 29 Apr 2004 09:50:21 -0400 Received: from noxmail.sandelman.ottawa.on.ca ([205.150.200.166]) by ietf-mx with esmtp (Exim 4.12) id 1BJBv7-00046D-00 for ipsec@ietf.org; Thu, 29 Apr 2004 09:49:45 -0400 Received: from sandelman.ottawa.on.ca (wlan237.sandelman.ca [205.150.200.237]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i3TDnPP12764 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Thu, 29 Apr 2004 09:49:25 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3TDnOsG014640 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 29 Apr 2004 09:49:24 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3TDnOx0014636; Thu, 29 Apr 2004 09:49:24 -0400 To: Tero Kivinen cc: Paul Hoffman / VPNC , IPsec WG Subject: Re: [Ipsec] VID for nat traversal In-Reply-To: Message from Tero Kivinen of "Thu, 29 Apr 2004 12:18:33 +0300." <16528.51305.225565.784412@fireball.acr.fi> References: <4516D26F7B3DD611BD310002A507C88B032801EC@MAX> <27228.1083176355@marajade.sandelman.ottawa.on.ca> <16528.51305.225565.784412@fireball.acr.fi> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Thu, 29 Apr 2004 09:49:24 -0400 Message-ID: <14635.1083246564@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tero" == Tero Kivinen writes: >> It is my understanding that someone who implemented -03 can >> interop with someone who has done -08. Tero> Partly. They will interoperate if they use tunnel mode, if Tero> they try to use transport mode the -08 implementation will Tero> assume/send two NAT-OA payloads, and the -03 will only Tero> assume/send one NAT-OA payload. This will most likely cause Tero> them to fail to negotiate. Also in the -08 the NAT-OA payloads Tero> are MANDATORY if using transport mode, as in the -03 it was Tero> only SHOULD. Hmm. Okay, so one needs a new VID for -08, but since: Tero> use range, the -08 have invalid numbers from the IANA Tero> allocated range. I think it would be better not to have an official -08 VID at all! In fact, I'd urge you to issue a -09 without the invalid numbers. Tero> So if you need to ship your products now, and want to have RFC Tero> compatibility, then implement the latest draft and make the I'd say something different. Unless you need transport mode, implement - -03 now, and RFC in a month or whatever. Maybe we can get the #s assigned sooner. Tero> when testing and when the final numbers will be out in month Tero> or two, you can change them easily. The Tero> UDP-encapsulated-transport and UDP-encapsulated-tunnel are I don't like such things - products stay in the field for a lot longer than anyone would like, and editing config parameters seems a PITA. {Btw, I have come up with a way to do OE with NAT-T with tunnel mode. I have yet to implement it yet. Look for a future document. Transport mode might actually make it easier, but I'm kind of skeptical about how well that really works. It seems that the IPsec has to do per-peer NAT in order to avoid possible port-overlaps if one has two clients connected from behind the same NAPT} - -- ] 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 iQCVAwUBQJEH2oqHRg3pndX9AQGrZQP/bcYdGQ9YbHmrjQhnXaBt8ElaGujrzU0t esP8dMYOeP0yNxAI8PGq0HVmr7+f6diEWEyqij2vXBpmWLaBxpQS4P30rMfHocEN je7qBa8vyZQElr37O0gCOmQ+0j39CqEto4xHBOn1coygFlls0Q3+oSYTHvDBjy5Y HNBoDRqR+j4= =byWR -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu Apr 29 14:08:23 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TL8Lw2073344; Thu, 29 Apr 2004 14:08:22 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJIM5-0007OA-Bd; Thu, 29 Apr 2004 16:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItxu-0006zP-BL for ipsec@optimus.ietf.org; Wed, 28 Apr 2004 14:39:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06464 for ; Wed, 28 Apr 2004 14:39:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BItxq-00066E-52 for ipsec@ietf.org; Wed, 28 Apr 2004 14:39:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItwv-000633-00 for ipsec@ietf.org; Wed, 28 Apr 2004 14:38:26 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BItvw-00060J-00 for ipsec@ietf.org; Wed, 28 Apr 2004 14:37:25 -0400 Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i3SIaWp21304 for ; Wed, 28 Apr 2004 14:36:32 -0400 (EDT) Received: from tsx2.cup.hp.com (tsx2.cup.hp.com [15.13.185.29]) by palrel13.hp.com (Postfix) with ESMTP id B76321C00AFD; Wed, 28 Apr 2004 11:37:23 -0700 (PDT) Received: from AZ735044 (az730541.cup.hp.com [15.13.105.111]) by tsx2.cup.hp.com (8.9.3 (PHNE_29774)/8.8.6) with SMTP id LAA28923; Wed, 28 Apr 2004 11:37:22 -0700 (PDT) From: "Andrew Wenlang Zhu" To: "'The IESG'" , <"IETF-Announce:"@tsx2.cup.hp.com> Cc: "'Internet Architecture Board'" , "'RFC Editor'" , "'ipsec mailing list'" , "'ipsec chair'" , "'ipsec chair'" Subject: RE: [Ipsec] Protocol Action: 'Negotiation of NAT-Traversal in the IKE' to Proposed Standard Date: Wed, 28 Apr 2004 11:36:48 -0700 Message-ID: <011c01c42d4f$c498c8b0$6f690d0f@AZ735044> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , FYI: One more thing we can do :-) Andrew > -----Original Message----- > From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org]On > Behalf Of The > IESG > Sent: Wednesday, April 28, 2004 7:25 AM > To: IETF-Announce: > Cc: Internet Architecture Board; RFC Editor; ipsec mailing list; ipsec > chair; ipsec chair > Subject: [Ipsec] Protocol Action: 'Negotiation of NAT-Traversal in the > IKE' to Proposed Standard > > > The IESG has approved the following document: > > - 'Negotiation of NAT-Traversal in the IKE ' > as a Proposed Standard > > This document is the product of the IP Security Protocol > Working Group. > > The IESG contact persons are Russ Housley and Steve Bellovin. > > Technical Summary > > This document describes how to detect one or more network address > translation devices (NATs) between IPsec hosts, and how to negotiate > the use of UDP encapsulation of the IPsec packets through the NAT > boxes in Internet Key Exchange (IKE) protocol. > > Working Group Summary > > The IPsec Working Group came to consensus on this document. > > Protocol Quality > > This document was reviewed by Russell Housley for the IESG. > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Thu Apr 29 14:44:58 2004 Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TLivQN079965; Thu, 29 Apr 2004 14:44:58 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJBO-0003ZP-BV; Thu, 29 Apr 2004 17:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJIv0-0006z0-Me for ipsec@optimus.ietf.org; Thu, 29 Apr 2004 17:18:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02506 for ; Thu, 29 Apr 2004 17:18:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJIut-0006vg-2e for ipsec@ietf.org; Thu, 29 Apr 2004 17:17:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJIs1-0006YG-00 for ipsec@ietf.org; Thu, 29 Apr 2004 17:15:01 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BJIqZ-0006KZ-00 for ipsec@ietf.org; Thu, 29 Apr 2004 17:13:31 -0400 Received: from [63.249.100.82] (dsl2-63-249-109-251.cruzio.com [63.249.109.251]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3TLDSpR074344 for ; Thu, 29 Apr 2004 14:13:29 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Thu, 29 Apr 2004 14:12:45 -0700 To: IPsec WG From: Paul Hoffman / VPNC Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=SUBJ_HAS_SPACES autolearn=no version=2.60 Subject: [Ipsec] Fwd: Last Call: 'State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator' to Informational RFC Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Given the use of EAP by IKEv2, implementers might want to review this document and comment to the IESG or the EAP WG. --Paul Hoffman >X-test-idtracker: no >To: IETF-Announce :; >From: The IESG >Subject: Last Call: 'State Machines for Extensible Authentication Protocol > (EAP) Peer and Authenticator' to Informational RFC >Reply-to: iesg@ietf.org >Date: Thu, 29 Apr 2004 14:35:22 -0400 >X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on > ietf-mx.ietf.org >X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,TO_HAS_SPACES autolearn=no > version=2.60 >Sender: ietf-announce-admin@ietf.org >X-BeenThere: ietf-announce@ietf.org >X-Mailman-Version: 2.0.12 >List-Unsubscribe: , > >List-Id: >List-Post: >List-Help: >List-Subscribe: , > > >The IESG has received a request from the Extensible Authentication Protocol WG >to consider the following document: > >- 'State Machines for Extensible Authentication Protocol (EAP) Peer and > Authenticator ' > as an Informational RFC > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by 2004-05-13. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-03.txt > > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri Apr 30 01:56:25 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3U8uOA0047255; Fri, 30 Apr 2004 01:56:24 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJTgf-0006qU-UB; Fri, 30 Apr 2004 04:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJTfh-0006jh-5G for ipsec@optimus.ietf.org; Fri, 30 Apr 2004 04:47:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03586 for ; Fri, 30 Apr 2004 04:46:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJTfa-00005e-LS for ipsec@ietf.org; Fri, 30 Apr 2004 04:46:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJTeY-0007m5-00 for ipsec@ietf.org; Fri, 30 Apr 2004 04:45:50 -0400 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 1BJTeL-0007f6-00 for ipsec@ietf.org; Fri, 30 Apr 2004 04:45:37 -0400 Received: from vies1k7x.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i3U8jBEP005917 for ; Fri, 30 Apr 2004 10:45:11 +0200 Received: from vies194a.sie.siemens.at (vies1kbx.sie.siemens.at [158.226.135.174]) by vies1k7x.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i3U8jBZv022162 for ; Fri, 30 Apr 2004 10:45:11 +0200 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Apr 2004 10:45:28 +0200 Message-ID: <4D50D5110555D5119F270800062B41650532AB74@viee10pa.erd.siemens.at> From: Grubmair Peter To: "IPsec WG (E-mail)" Date: Fri, 30 Apr 2004 10:42:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Ipsec] IKEv2 Diffie Hellman groups Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , draft 13 In Appendix B page 94 it is stated that there are 5 DH groups for use in IKEv2, but then only the first for groups of Orm96 are mentioned, I think Group 5 MODP 1536 was forgotten. Best regards Peter _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri Apr 30 14:15:05 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3ULF4dE072432; Fri, 30 Apr 2004 14:15:04 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJf7A-0004ZE-C8; Fri, 30 Apr 2004 17:00:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJeAH-0003ch-HT for ipsec@optimus.ietf.org; Fri, 30 Apr 2004 15:59:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27292 for ; Fri, 30 Apr 2004 15:59:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJeAF-00004B-Uh for ipsec@ietf.org; Fri, 30 Apr 2004 15:59:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJe9N-00000B-00 for ipsec@ietf.org; Fri, 30 Apr 2004 15:58:21 -0400 Received: from bay8-f82.bay8.hotmail.com ([64.4.27.82] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BJe8w-0007im-00 for ipsec@ietf.org; Fri, 30 Apr 2004 15:57:54 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 30 Apr 2004 12:57:24 -0700 Received: from 81.178.20.174 by by8fd.bay8.hotmail.msn.com with HTTP; Fri, 30 Apr 2004 19:57:24 GMT X-Originating-IP: [81.178.20.174] X-Originating-Email: [bob_arthurs@hotmail.com] X-Sender: bob_arthurs@hotmail.com From: "Bob Arthurs" To: ipsec@ietf.org Date: Fri, 30 Apr 2004 19:57:24 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Apr 2004 19:57:24.0321 (UTC) FILETIME=[5B116510:01C42EED] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Ipsec] IKE Keepalive draft??? Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , Hi, I'm just doing some research on IKE keepalives. Does anyone know if there is a draft that describes Cisco's implementation of IKE keepalives. I'm not talking about DPD here - I mean the original IKE keepalive implementation. I'm sure that there was a draft that described this, but I can't locate it now. Maybe there has never been a a draft describing this - maybe it's just my imagination :) Many thanks for any help in advance Bob _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-admin@ietf.org Fri Apr 30 14:41:44 2004 Received: from optimus.ietf.org (datatracker.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3ULfgkY079515; Fri, 30 Apr 2004 14:41:43 -0700 (PDT) (envelope-from ipsec-admin@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfaO-0006Qq-5t; Fri, 30 Apr 2004 17:30:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJfT9-0003iy-QW for ipsec@optimus.ietf.org; Fri, 30 Apr 2004 17:22:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04708 for ; Fri, 30 Apr 2004 17:22:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJfT7-0003ag-FI for ipsec@ietf.org; Fri, 30 Apr 2004 17:22:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJfSM-0003Rh-00 for ipsec@ietf.org; Fri, 30 Apr 2004 17:22:03 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BJfQQ-00030T-00 for ipsec@ietf.org; Fri, 30 Apr 2004 17:20:02 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3ULJUW9018322; Fri, 30 Apr 2004 14:19:30 -0700 (PDT) Received: from cisco.com (stealth-10-32-244-26.cisco.com [10.32.244.26]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id ASP60071; Fri, 30 Apr 2004 14:18:43 -0700 (PDT) Message-ID: <4092C2F3.6080609@cisco.com> Date: Fri, 30 Apr 2004 14:19:47 -0700 From: Geoffrey Huang User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Arthurs CC: ipsec@ietf.org Subject: Re: [Ipsec] IKE Keepalive draft??? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipsec-admin@ietf.org Errors-To: ipsec-admin@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Security List-Post: List-Help: List-Subscribe: , There is no such draft. Do a search on cisco.com. -g Bob Arthurs wrote: > Hi, > > I'm just doing some research on IKE keepalives. Does anyone know if > there is a draft that describes Cisco's implementation of IKE > keepalives. I'm not talking about DPD here - I mean the original IKE > keepalive implementation. I'm sure that there was a draft that described > this, but I can't locate it now. Maybe there has never been a a draft > describing this - maybe it's just my imagination :) > > Many thanks for any help in advance > > Bob > > _________________________________________________________________ > Stay in touch with absent friends - get MSN Messenger > http://www.msn.co.uk/messenger > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec