From owner-ipsec@lists.tislabs.com Thu Apr 1 07:14:11 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08193 for ; Thu, 1 Apr 2004 07:14:10 -0500 (EST) 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 Content-Transfer-Encoding: 8bit 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 08:08:32 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10296 for ; Thu, 1 Apr 2004 08:08:32 -0500 (EST) 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 Content-Transfer-Encoding: 8bit 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 08:15:27 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10947 for ; Thu, 1 Apr 2004 08:15:27 -0500 (EST) 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 Content-Transfer-Encoding: 8bit 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:38:11 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12357 for ; Thu, 1 Apr 2004 08:38:11 -0500 (EST) 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 Content-Transfer-Encoding: 8bit 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 09:39:34 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15047 for ; Thu, 1 Apr 2004 09:39:34 -0500 (EST) 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 10:29:42 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16694 for ; Thu, 1 Apr 2004 10:29:42 -0500 (EST) 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 Content-Transfer-Encoding: 7bit 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 12:32:02 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23085 for ; Thu, 1 Apr 2004 12:32:02 -0500 (EST) 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 Content-Transfer-Encoding: 7bit >>>>> "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 12:34:04 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23150 for ; Thu, 1 Apr 2004 12:34:04 -0500 (EST) 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 Content-Transfer-Encoding: 7bit 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 13:30:04 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25014 for ; Thu, 1 Apr 2004 13:30:03 -0500 (EST) 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 Content-Transfer-Encoding: 7bit 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 13:33:50 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25103 for ; Thu, 1 Apr 2004 13:33:50 -0500 (EST) 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 13:55:21 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25667 for ; Thu, 1 Apr 2004 13:55:20 -0500 (EST) 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 14:01:57 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25946 for ; Thu, 1 Apr 2004 14:01:56 -0500 (EST) 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:02:19 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25973 for ; Thu, 1 Apr 2004 14:02:17 -0500 (EST) 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 19:11:51 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12159 for ; Thu, 1 Apr 2004 19:11:51 -0500 (EST) 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 19:27:50 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13717 for ; Thu, 1 Apr 2004 19:27:50 -0500 (EST) 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 Content-Transfer-Encoding: 7bit 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 20:11:47 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16793 for ; Thu, 1 Apr 2004 20:11:47 -0500 (EST) 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 Content-Transfer-Encoding: 7bit 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 21:10:11 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23178 for ; Thu, 1 Apr 2004 21:10:11 -0500 (EST) 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 22:58:51 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00353 for ; Thu, 1 Apr 2004 22:58:50 -0500 (EST) 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 Content-Transfer-Encoding: 7bit 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 23:41:34 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04778 for ; Thu, 1 Apr 2004 23:41:34 -0500 (EST) 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 Content-Transfer-Encoding: 7bit -----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 Fri Apr 2 01:01:56 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11417 for ; Fri, 2 Apr 2004 01:01:56 -0500 (EST) 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 Content-Transfer-Encoding: 7bit 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:16:08 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11798 for ; Fri, 2 Apr 2004 01:16:08 -0500 (EST) 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 Content-Transfer-Encoding: 7bit -----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 Fri Apr 2 02:38:45 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26941 for ; Fri, 2 Apr 2004 02:38:44 -0500 (EST) 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 Content-Transfer-Encoding: 8bit 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 Fri Apr 2 04:24:35 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00845 for ; Fri, 2 Apr 2004 04:24:35 -0500 (EST) 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 Content-Transfer-Encoding: 7bit -----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 05:51:53 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03230 for ; Fri, 2 Apr 2004 05:51:52 -0500 (EST) 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 05:56:02 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03334 for ; Fri, 2 Apr 2004 05:56:02 -0500 (EST) 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 Content-Transfer-Encoding: 7bit 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 06:32:47 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04107 for ; Fri, 2 Apr 2004 06:32:46 -0500 (EST) 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 Content-Transfer-Encoding: 8bit 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 07:05:03 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05571 for ; Fri, 2 Apr 2004 07:05:03 -0500 (EST) 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 Content-Transfer-Encoding: 8bit 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 16:39:48 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02536 for ; Fri, 2 Apr 2004 16:39:47 -0500 (EST) 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 16:45:43 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03426 for ; Fri, 2 Apr 2004 16:45:43 -0500 (EST) 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 Content-Transfer-Encoding: 7bit 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 18:55:26 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14552 for ; Fri, 2 Apr 2004 18:55:25 -0500 (EST) 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 Content-Transfer-Encoding: 7bit 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 19:37:41 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15462 for ; Fri, 2 Apr 2004 19:37:41 -0500 (EST) 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 Fri Apr 2 21:09:26 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18499 for ; Fri, 2 Apr 2004 21:09:25 -0500 (EST) 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 21:09:27 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18517 for ; Fri, 2 Apr 2004 21:09:26 -0500 (EST) 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 Content-Transfer-Encoding: 7bit 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 Sat Apr 3 00:20:33 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24211 for ; Sat, 3 Apr 2004 00:20:33 -0500 (EST) 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 Content-Transfer-Encoding: 7bit >>>>> "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 Sat Apr 3 00:56:41 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25242 for ; Sat, 3 Apr 2004 00:56:40 -0500 (EST) 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 Mon Apr 5 17:08:13 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10033 for ; Mon, 5 Apr 2004 17:08:13 -0400 (EDT) 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 21:27:12 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01887 for ; Mon, 5 Apr 2004 21:27:11 -0400 (EDT) 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 Content-Transfer-Encoding: 7bit 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 03:42:56 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16819 for ; Tue, 6 Apr 2004 03:42:56 -0400 (EDT) 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 Content-Transfer-Encoding: 7bit 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 17:25:14 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27670 for ; Tue, 6 Apr 2004 17:25:13 -0400 (EDT) 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 17:31:27 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28633 for ; Tue, 6 Apr 2004 17:31:27 -0400 (EDT) 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 17:31:28 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28650 for ; Tue, 6 Apr 2004 17:31:28 -0400 (EDT) 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 18:06:25 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04559 for ; Tue, 6 Apr 2004 18:06:24 -0400 (EDT) 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 18:10:39 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05125 for ; Tue, 6 Apr 2004 18:10:39 -0400 (EDT) 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 18:13:25 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05429 for ; Tue, 6 Apr 2004 18:13:25 -0400 (EDT) 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 18:26:08 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06290 for ; Tue, 6 Apr 2004 18:26:08 -0400 (EDT) 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 19:11:24 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08712 for ; Tue, 6 Apr 2004 19:11:24 -0400 (EDT) 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 19:26:02 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09265 for ; Tue, 6 Apr 2004 19:26:02 -0400 (EDT) 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 19:28:33 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09746 for ; Tue, 6 Apr 2004 19:28:33 -0400 (EDT) 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 19:47:59 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13630 for ; Tue, 6 Apr 2004 19:47:59 -0400 (EDT) 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 19:49:36 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13728 for ; Tue, 6 Apr 2004 19:49:36 -0400 (EDT) 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 19:50:51 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13766 for ; Tue, 6 Apr 2004 19:50:50 -0400 (EDT) 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 20:19:35 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17088 for ; Tue, 6 Apr 2004 20:19:35 -0400 (EDT) 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 20:53:26 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17620 for ; Tue, 6 Apr 2004 20:53:26 -0400 (EDT) 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 23:37:50 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01004 for ; Tue, 6 Apr 2004 23:37:50 -0400 (EDT) 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 Wed Apr 7 01:22:01 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12325 for ; Wed, 7 Apr 2004 01:22:00 -0400 (EDT) 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 Wed Apr 7 01:26:34 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12390 for ; Wed, 7 Apr 2004 01:26:33 -0400 (EDT) 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 Wed Apr 7 01:42:07 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13116 for ; Wed, 7 Apr 2004 01:42:06 -0400 (EDT) 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 Wed Apr 7 01:45:00 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13211 for ; Wed, 7 Apr 2004 01:44:59 -0400 (EDT) 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 Content-Transfer-Encoding: 7bit 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 Wed Apr 7 03:02:16 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19097 for ; Wed, 7 Apr 2004 03:02:15 -0400 (EDT) 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 06:51:15 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05711 for ; Wed, 7 Apr 2004 06:51:14 -0400 (EDT) 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 Content-Transfer-Encoding: 7bit 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 06:54:33 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05896 for ; Wed, 7 Apr 2004 06:54:32 -0400 (EDT) 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 07:03:29 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07032 for ; Wed, 7 Apr 2004 07:03:28 -0400 (EDT) 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 Content-Transfer-Encoding: 7bit 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 08:29:11 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15781 for ; Wed, 7 Apr 2004 08:29:11 -0400 (EDT) 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 Content-Transfer-Encoding: 7bit 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 10:40:21 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29507 for ; Wed, 7 Apr 2004 10:40:21 -0400 (EDT) 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 13:04:36 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11145 for ; Wed, 7 Apr 2004 13:04:35 -0400 (EDT) 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 13:09:19 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12012 for ; Wed, 7 Apr 2004 13:09:19 -0400 (EDT) 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 13:13:07 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12626 for ; Wed, 7 Apr 2004 13:13:07 -0400 (EDT) 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 13:25:37 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15410 for ; Wed, 7 Apr 2004 13:25:36 -0400 (EDT) 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 13:42:35 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16952 for ; Wed, 7 Apr 2004 13:42:35 -0400 (EDT) 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 13:54:57 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19667 for ; Wed, 7 Apr 2004 13:54:57 -0400 (EDT) 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 14:18:40 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22960 for ; Wed, 7 Apr 2004 14:18:39 -0400 (EDT) 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> 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 Content-Transfer-Encoding: 8bit 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 14:19:17 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23148 for ; Wed, 7 Apr 2004 14:19:17 -0400 (EDT) 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 15:02:12 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26744 for ; Wed, 7 Apr 2004 15:02:12 -0400 (EDT) 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 Content-Transfer-Encoding: 7bit > > 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 16:27:17 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29783 for ; Wed, 7 Apr 2004 16:27:16 -0400 (EDT) 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 16:32:15 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00864 for ; Wed, 7 Apr 2004 16:32:15 -0400 (EDT) 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 Content-Transfer-Encoding: 7bit >>>>> "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 16:57:48 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04046 for ; Wed, 7 Apr 2004 16:57:48 -0400 (EDT) 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: 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 Content-Transfer-Encoding: 8bit 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 17:17:10 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07175 for ; Wed, 7 Apr 2004 17:17:10 -0400 (EDT) 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 Content-Transfer-Encoding: 7bit > > > > 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 18:04:04 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14471 for ; Wed, 7 Apr 2004 18:04:03 -0400 (EDT) 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 19:16:55 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19404 for ; Wed, 7 Apr 2004 19:16:54 -0400 (EDT) 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 19:17:23 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19422 for ; Wed, 7 Apr 2004 19:17:23 -0400 (EDT) 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 19:23:28 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19486 for ; Wed, 7 Apr 2004 19:23:27 -0400 (EDT) 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 Content-Transfer-Encoding: 7bit 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 21:42:16 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04734 for ; Wed, 7 Apr 2004 21:42:15 -0400 (EDT) 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 Content-Transfer-Encoding: 7bit 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 21:49:31 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05212 for ; Wed, 7 Apr 2004 21:49:31 -0400 (EDT) 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: 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 Content-Transfer-Encoding: 8bit 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 owner-ipsec@lists.tislabs.com Thu Apr 8 03:11:03 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15720 for ; Thu, 8 Apr 2004 03:11:03 -0400 (EDT) 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 Content-Transfer-Encoding: 7bit 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 05:25:52 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24739 for ; Thu, 8 Apr 2004 05:25:51 -0400 (EDT) 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 Content-Transfer-Encoding: 7bit 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 06:48:00 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06205 for ; Thu, 8 Apr 2004 06:47:59 -0400 (EDT) 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 Content-Transfer-Encoding: 7bit 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 09:48:29 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15569 for ; Thu, 8 Apr 2004 09:48:29 -0400 (EDT) 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 Content-Transfer-Encoding: 7bit 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 11:40:29 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28986 for ; Thu, 8 Apr 2004 11:40:27 -0400 (EDT) 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 12:59:06 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03224 for ; Thu, 8 Apr 2004 12:59:03 -0400 (EDT) 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 Content-Transfer-Encoding: 7bit >>>>> "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 14:49:53 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09999 for ; Thu, 8 Apr 2004 14:49:52 -0400 (EDT) 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 17:53:05 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28846 for ; Thu, 8 Apr 2004 17:53:04 -0400 (EDT) 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 Fri Apr 9 02:02:26 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02073 for ; Fri, 9 Apr 2004 02:02:22 -0400 (EDT) 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 owner-ipsec@lists.tislabs.com Fri Apr 9 10:34:29 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00586 for ; Fri, 9 Apr 2004 10:34:28 -0400 (EDT) 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 Content-Transfer-Encoding: 7BIT 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 11:37:33 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03021 for ; Fri, 9 Apr 2004 11:37:31 -0400 (EDT) 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 11:39:53 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03105 for ; Fri, 9 Apr 2004 11:39:52 -0400 (EDT) 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 Content-Transfer-Encoding: 7bit >>>>> "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 12:25:50 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03122 for ; Fri, 9 Apr 2004 11:39:56 -0400 (EDT) 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 15:34:48 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15271 for ; Fri, 9 Apr 2004 15:34:46 -0400 (EDT) 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: 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 Content-Transfer-Encoding: 8bit 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 18:12:58 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27036 for ; Fri, 9 Apr 2004 18:12:58 -0400 (EDT) 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 18:13:14 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27097 for ; Fri, 9 Apr 2004 18:13:13 -0400 (EDT) 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 Content-Transfer-Encoding: 7BIT 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 19:10:27 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00426 for ; Fri, 9 Apr 2004 19:10:25 -0400 (EDT) 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 19:53:08 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01696 for ; Fri, 9 Apr 2004 19:53:07 -0400 (EDT) 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 Content-Transfer-Encoding: 7bit >>>>> "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 21:26:19 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04182 for ; Fri, 9 Apr 2004 21:26:17 -0400 (EDT) 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 Content-Transfer-Encoding: 7bit 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 23:40:46 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07733 for ; Fri, 9 Apr 2004 23:40:45 -0400 (EDT) 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 Sat Apr 10 01:00:54 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09617 for ; Sat, 10 Apr 2004 01:00:52 -0400 (EDT) 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: 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 Content-Transfer-Encoding: 8bit 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 Sat Apr 10 01:38:45 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10379 for ; Sat, 10 Apr 2004 01:38:45 -0400 (EDT) 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 Content-Transfer-Encoding: 7BIT 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 05:02:53 2004 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28852 for ; Sat, 10 Apr 2004 05:02:50 -0400 (EDT) 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 Content-Transfer-Encoding: 8bit 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 14:36:03 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14013 for ; Sat, 10 Apr 2004 14:36:00 -0400 (EDT) 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 15:21:32 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16379 for ; Sat, 10 Apr 2004 15:21:32 -0400 (EDT) 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 23:29:07 2004 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04051 for ; Mon, 12 Apr 2004 23:29:04 -0400 (EDT) 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