From ipsec-bounces@ietf.org Mon Nov 1 03:59:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06303 for ; Mon, 1 Nov 2004 03:59:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COXtV-0006m5-4K; Mon, 01 Nov 2004 03:50:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COXrx-0006Kl-4V for ipsec@megatron.ietf.org; Mon, 01 Nov 2004 03:48:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05122 for ; Mon, 1 Nov 2004 03:48:52 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COY6o-0001Wd-Mo for ipsec@ietf.org; Mon, 01 Nov 2004 04:04:15 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iA18md7S013073 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 1 Nov 2004 10:48:40 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iA18mbrE013068; Mon, 1 Nov 2004 10:48:37 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.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: <16773.63589.716356.612414@fireball.kivinen.iki.fi> Date: Mon, 1 Nov 2004 10:48:37 +0200 From: Tero Kivinen To: Subject: RE: [Ipsec] Reauthentication in IKEv2 In-Reply-To: <125EA890549C8641A72F3809CB80DCCD17839D@esebe056.ntc.nokia.com> References: <125EA890549C8641A72F3809CB80DCCD17839D@esebe056.ntc.nokia.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 10 min X-Total-Time: 10 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, ynir@checkpoint.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com writes: > Yes, but the client has more knowledge about the situation... > E.g., if I have a long download ongoing, and I'm leaving for > lunch, I could check how much time is remaining before the > next reauthentication (instead of always reauthenticating > "just in case", or hoping for the best). So the client does not have any more information in this case, but the user of the client does. The user in the client end can do much more intelligent things regardless of the lifetimes sent in the protocol. > And sending the lifetime means one message exchange less > in >99% of the cases, so it's IMHO the simpler of the two > alternatives (but I guess we disagree here :-). Note, that in the proposal the lifetime is sent AS A SEPARATE informational exchange, so the number of packets and exchanges stays same. Only difference is that if the lifetime parameter is there, then BOTH client and server will need to keep track of it. If it is not there, then only the AAA server need to keep track of it, and it can inform the server that now it is time to do reauthentication, and the server will then inform client etc. > policies without any need for negotiation. But IMHO here > making the gateway's policy visible to the client would > (in some circumstances) provide benefits to the end user. Some people do consider giving out the lifetime also gives out too much information, i.e. the attacker knows that he has this much time before the vpn connection to the corporate hq is cut out from the laptop he stole. > > At least I didn't see enough support for this, in the list, so > > this could really be a WG item. I think this should propably > > be postponed to the IKEv2 extensions WG (I assume someone will > > someday create one), just like the > > draft-eronen-ipsec-ikev2-eap-auth-02.txt... > > Are you against publishing them as individual submissions? No, but I would think it would be better to start WG to take care of them. There is people who are interested in them, and as the IPsec WG is going to be shutdown, we need some place to discuss and process them. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 1 04:31:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08412 for ; Mon, 1 Nov 2004 04:31:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COYVW-0001vq-8Z; Mon, 01 Nov 2004 04:29:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COYRL-0001f1-1X for ipsec@megatron.ietf.org; Mon, 01 Nov 2004 04:25:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08105 for ; Mon, 1 Nov 2004 04:25:26 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COYgC-0002NQ-W1 for ipsec@ietf.org; Mon, 01 Nov 2004 04:40:49 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iA19PMon013486 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 1 Nov 2004 11:25:22 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iA19PIsA013483; Mon, 1 Nov 2004 11:25:18 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.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: <16774.254.491197.429541@fireball.kivinen.iki.fi> Date: Mon, 1 Nov 2004 11:25:18 +0200 From: Tero Kivinen To: Paul Koning Subject: Re: [Ipsec] AES Algorithm Negotiation in IKE In-Reply-To: <16770.24109.878000.862040@gargle.gargle.HOWL> References: <6.1.2.0.2.20041028143707.05514a50@mail.binhost.com> <5F0B1AEC-2939-11D9-A773-000393AD410A@netvision.net.il> <16770.24109.878000.862040@gargle.gargle.HOWL> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 25 min X-Total-Time: 30 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, ynir@netvision.net.il X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Paul Koning writes: > Similarly, ICV length for the combined algorithms should be another > parameter just like the key length -- not encoded in the algorithm > ID. Note, that the transform attributes are AND'ed together, i.e. there must not be multiple transform attributes in one transform, and all of them must be selected. I.e. if you want to propose 128, 192 bit AES with 8 and 12 octect ICVs you have following proposals: (with transform attributes): proposal #1, ID = ESP, SPI size = 4, # of transforms = 5, SPI = 0x12345678 trasform type = ENCR, ID = ENCR_AES_CCM, len = 16 transform attribute: type = key length, value = 128 transform attribute: type = ICV length, value = 8 trasform type = ENCR, ID = ENCR_AES_CCM, len = 16 transform attribute: type = key length, value = 128 transform attribute: type = ICV length, value = 12 trasform type = ENCR, ID = ENCR_AES_CCM, len = 16 transform attribute: type = key length, value = 192 transform attribute: type = ICV length, value = 8 trasform type = ENCR, ID = ENCR_AES_CCM, len = 16 transform attribute: type = key length, value = 192 transform attribute: type = ICV length, value = 12 trasform type = INTEG, ID = AUTH_HMAC_SHA1_96, len = 8 or with the ICV included in the ID, and still using the key length defined in the IKEv2 draft: proposal #1, ID = ESP, SPI size = 4, # of transforms = 5, SPI = 0x12345678 trasform type = ENCR, ID = ENCR_AES_CCM_ICV_8, len = 12 transform attribute: type = key length, value = 128 trasform type = ENCR, ID = ENCR_AES_CCM_ICV_12, len = 12 transform attribute: type = key length, value = 128 trasform type = ENCR, ID = ENCR_AES_CCM_ICV_8, len = 12 transform attribute: type = key length, value = 192 trasform type = ENCR, ID = ENCR_AES_CCM_ICV_12, len = 12 transform attribute: type = key length, value = 192 trasform type = INTEG, ID = AUTH_HMAC_SHA1_96, len = 8 and if we remove the key length parameter for the AES too: proposal #1, ID = ESP, SPI size = 4, # of transforms = 5, SPI = 0x12345678 trasform type = ENCR, ID = ENCR_AES_CCM_128_ICV_8, len = 8 trasform type = ENCR, ID = ENCR_AES_CCM_128_ICV_12, len = 8 trasform type = ENCR, ID = ENCR_AES_CCM_128_ICV_8, len = 8 trasform type = ENCR, ID = ENCR_AES_CCM_128_ICV_12, len = 8 trasform type = INTEG, ID = AUTH_HMAC_SHA1_96, len = 8 The total lenght of SA payloads will be 88, 72 and 56 bytes. The real benefit from using the transform attributes comes only when there is lots of different valid values. If there is only 3 different values (8, 12, and 16 byte ICV), I think using multiple transform IDs is better. If there is much more like there actually could be for the key lengths (at least 40, 64, 80, 128, 160, 192, 256, 384, 448, 512 bits have been used), then it is better to use transform attributes. So my suggestion is that we continue using the key length attribute for key lengths, but for that kind of parametrized ciphers, where there is only few (less than 5) possible choices for the parameter, we encode the parameter inside transform ID. Note, that it does not matter whether there is multiple or one parameter, as we need to list all possible combinations of them in all cases, i.e. if we add another parameter say block length above, we need to double the number of ENCR transform payloads in all the cases above, so using transform attribute only wastes bytes on the packet, but saves it from the IANA registry. There is one more option which can be used if we really have some new parameter which we do not want to allocate from the transform attributes or from the transform ids. We can we create new transform type for it, i.e: proposal #1, ID = ESP, SPI size = 4, # of transforms = 5, SPI = 0x12345678 trasform type = ENCR, ID = ENCR_AES_CCM, len = 12 transform attribute: type = key length, value = 128 trasform type = ENCR, ID = ENCR_AES_CCM, len = 12 transform attribute: type = key length, value = 192 trasform type = INTEG, ID = AUTH_HMAC_SHA1_96, len = 8 trasform type = ICV_LEN, ID = ICV_LEN_8, len = 8 trasform type = ICV_LEN, ID = ICV_LEN_12, len = 8 (this is not really for this case, but I am listing it so people remember this option too, when making extensions later...) -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 1 04:49:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09386 for ; Mon, 1 Nov 2004 04:49:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COYdK-0002on-UX; Mon, 01 Nov 2004 04:37:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COYX8-0002A2-HD for ipsec@megatron.ietf.org; Mon, 01 Nov 2004 04:31:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08399 for ; Mon, 1 Nov 2004 04:31:25 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COYm0-0002Tk-PE for ipsec@ietf.org; Mon, 01 Nov 2004 04:46:49 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iA19VHT0013619 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 1 Nov 2004 11:31:22 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iA19VFdm013616; Mon, 1 Nov 2004 11:31:15 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.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: <16774.610.973224.636283@fireball.kivinen.iki.fi> Date: Mon, 1 Nov 2004 11:31:14 +0200 From: Tero Kivinen To: Paul Hoffman / VPNC Subject: Re: [Ipsec] AES Algorithm Negotiation in IKE In-Reply-To: References: <6.1.2.0.2.20041028143707.05514a50@mail.binhost.com> <5F0B1AEC-2939-11D9-A773-000393AD410A@netvision.net.il> <16770.24109.878000.862040@gargle.gargle.HOWL> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 1 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Paul Hoffman / VPNC writes: > Let me push back on this and ask for real-world implementers: do you > agree here? That it would be better to create a new > algorithm-specific parameter and use the current parameter system > rather than two additional algorithms IDs for CCM and zero additional > algorithm IDs for GCM? I would rather see them included in the ID than to create new transform attributes (I actually already do this same for the key lengths in my implementation, i.e. I take the key length from the transform attributes, and encode it to the cipher name I will be using..., I can do the same for the ICV lengths, but it will result bigger packets on the wire). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 1 04:55:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09855 for ; Mon, 1 Nov 2004 04:55:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COYs5-0004Tx-1t; Mon, 01 Nov 2004 04:53:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COYiC-00035f-1c for ipsec@megatron.ietf.org; Mon, 01 Nov 2004 04:42:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09029 for ; Mon, 1 Nov 2004 04:42:34 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COYwn-0002gt-O3 for ipsec@ietf.org; Mon, 01 Nov 2004 04:57:58 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iA19gW6o013702 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 1 Nov 2004 11:42:33 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iA19gVZv013699; Mon, 1 Nov 2004 11:42:31 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.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: <16774.1287.739798.629629@fireball.kivinen.iki.fi> Date: Mon, 1 Nov 2004 11:42:31 +0200 From: Tero Kivinen To: Paul Hoffman / VPNC Subject: Re: [Ipsec] AES Algorithm Negotiation in IKE In-Reply-To: References: <6.1.2.0.2.20041028143707.05514a50@mail.binhost.com> <5F0B1AEC-2939-11D9-A773-000393AD410A@netvision.net.il> <16770.24109.878000.862040@gargle.gargle.HOWL> <16770.39440.480000.71261@gargle.gargle.HOWL> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 7 min X-Total-Time: 7 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Paul Hoffman / VPNC writes: > Except that it wasn't used for many years after the spec was > implemented because there wasn't a commonly-used encryption algorithm > that needed it until AES. I can't say exactly what people had > problems with, but I can say that I had at least two implementers who > said "we got it wrong the first time we tried" (and that they had > fixed the problem before it got to the VPNC interop testing). Most of the problems were in the form like "including key length attribute for the fixed key length cipher" or "assume the default of 128 bits for the key lenght if no key length attribute given" etc. And also having policy which allows only exactly 224 bit blowfish keys, and the other end proposed 256, thus no proposal chosen. BTW, key length and ICV length are not really comparable, as there is much more valid values for the key length than there is for the ICVs. Especially if you consider ciphers like blowfish. ICV is not really variable length, there is only very few valid values for that defined in the drafts. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From mailman-bounces@ietf.org Mon Nov 1 05:58:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16159 for ; Mon, 1 Nov 2004 05:58:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZIY-0003ts-8t for ipsec-archive@lists.ietf.org; Mon, 01 Nov 2004 05:20:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ipsec-archive@ietf.org X-No-Archive: yes Message-ID: Date: Mon, 01 Nov 2004 05:06:25 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ipsec-archive@lists.ietf.org: List Password // URL ---- -------- ipsec@ietf.org ogcewi https://www1.ietf.org/mailman/options/ipsec/ipsec-archive%40lists.ietf.org From ipsec-bounces@ietf.org Mon Nov 1 09:36:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08030 for ; Mon, 1 Nov 2004 09:36:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZqR-0006ag-Fe; Mon, 01 Nov 2004 05:55:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZ6l-0007hn-NC for ipsec@megatron.ietf.org; Mon, 01 Nov 2004 05:08:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10659 for ; Mon, 1 Nov 2004 05:08:14 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COZLe-0003EM-3z for ipsec@ietf.org; Mon, 01 Nov 2004 05:23:38 -0500 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id iA1A7f028085; Mon, 1 Nov 2004 12:07:41 +0200 (IST) In-Reply-To: <16773.63589.716356.612414@fireball.kivinen.iki.fi> References: <125EA890549C8641A72F3809CB80DCCD17839D@esebe056.ntc.nokia.com> <16773.63589.716356.612414@fireball.kivinen.iki.fi> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] Reauthentication in IKEv2 Date: Mon, 1 Nov 2004 12:07:40 +0200 To: Tero Kivinen X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit IMO if it's a gateway's policy to trust a user for only 2 hours after authentication, then it must delete all SAs after two hours, unless the user authenticates again. All this information is available to the gateway at the time of the Initial exchange, and this seems like the most natural time to inform the client. Obviously, we can't send a "reauth_now" after two hours, as this would break connections, so a "reauth_now" would need to be sent earlier. How much earlier? The IKE gateway cannot know how much time it takes to re-authenticate. This involves packet lag, fumbling for the SecurID card or the USB token with the cert, typing and checking, and maybe even repeating the whole process if you typed wrong. This time can be as short as 2 seconds in the case of a certificate on the client or softID (like SecurID but in software), or it can be as much as several minutes for a real token. In any case, this sends the user a message saying "quickly enter your password or else your connections will be broken real soon, we don't know how soon." OTOH, if at the Initial exchange the client gets a message saying "2 hours to go", it can show a countdown timer, or it can pop a re-authentication window an appropriate time in advance. This way, the client software has control of the user experience, which is much better than leaving it to some gateway. As long as we're using Check Point clients with Check Point gateways or Cisco clients with Cisco gateways there will always be IKE or non-IKE ways of passing this information and fixing the user experience. I'm thinking about generic clients that may come from companies like Microsoft or Apple, or some GPL project for Linux. These clients should not have to depend on vendor-specific extensions to display the time before re-authentication is required. Unless I hear some very compelling argument as to why "reauth_now" is superior, I think I'll stick with a lifetime message. On Nov 1, 2004, at 10:48 AM, Tero Kivinen wrote: > Pasi.Eronen@nokia.com writes: >> Yes, but the client has more knowledge about the situation... >> E.g., if I have a long download ongoing, and I'm leaving for >> lunch, I could check how much time is remaining before the >> next reauthentication (instead of always reauthenticating >> "just in case", or hoping for the best). > > So the client does not have any more information in this case, but the > user of the client does. The user in the client end can do much more > intelligent things regardless of the lifetimes sent in the protocol. > >> And sending the lifetime means one message exchange less >> in >99% of the cases, so it's IMHO the simpler of the two >> alternatives (but I guess we disagree here :-). > > Note, that in the proposal the lifetime is sent AS A SEPARATE > informational exchange, so the number of packets and exchanges stays > same. Only difference is that if the lifetime parameter is there, then > BOTH client and server will need to keep track of it. If it is not > there, then only the AAA server need to keep track of it, and it can > inform the server that now it is time to do reauthentication, and the > server will then inform client etc. > >> policies without any need for negotiation. But IMHO here >> making the gateway's policy visible to the client would >> (in some circumstances) provide benefits to the end user. > > Some people do consider giving out the lifetime also gives out too > much information, i.e. the attacker knows that he has this much time > before the vpn connection to the corporate hq is cut out from the > laptop he stole. > >>> At least I didn't see enough support for this, in the list, so >>> this could really be a WG item. I think this should propably >>> be postponed to the IKEv2 extensions WG (I assume someone will >>> someday create one), just like the >>> draft-eronen-ipsec-ikev2-eap-auth-02.txt... >> >> Are you against publishing them as individual submissions? > > No, but I would think it would be better to start WG to take care of > them. There is people who are interested in them, and as the IPsec WG > is going to be shutdown, we need some place to discuss and process > them. > -- > kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 1 11:09:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26657 for ; Mon, 1 Nov 2004 11:09:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COdyY-0000oN-Qp; Mon, 01 Nov 2004 10:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CObPM-0001Ki-BQ for ipsec@megatron.ietf.org; Mon, 01 Nov 2004 07:35:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25223 for ; Mon, 1 Nov 2004 07:35:34 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CObe7-00061n-HC for ipsec@ietf.org; Mon, 01 Nov 2004 07:51:00 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iA1CZJXa015474 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 1 Nov 2004 14:35:19 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iA1CZHrf015469; Mon, 1 Nov 2004 14:35:17 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.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: <16774.11653.287889.606592@fireball.kivinen.iki.fi> Date: Mon, 1 Nov 2004 14:35:17 +0200 From: Tero Kivinen To: Yoav Nir Subject: Re: [Ipsec] Reauthentication in IKEv2 In-Reply-To: References: <125EA890549C8641A72F3809CB80DCCD17839D@esebe056.ntc.nokia.com> <16773.63589.716356.612414@fireball.kivinen.iki.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 12 min X-Total-Time: 11 min X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Yoav Nir writes: > IMO if it's a gateway's policy to trust a user for only 2 hours after > authentication, then it must delete all SAs after two hours, unless the > user authenticates again. All this information is available to the > gateway at the time of the Initial exchange, and this seems like the > most natural time to inform the client. But lets say the gateways policy is "client need to reauthenticate after it has done more than $10000 worth of transactions in the shop". We do not want to send that policy to the client, so why should we try to send the lifetime policy to the client? We did remove all the lifetimes in the IKEv2, so why are we trying to add another. The lifetimes did cause lots of trouble in IKEv1, so lets try to keep them away from the IKEv2... > Obviously, we can't send a "reauth_now" after two hours, as this would > break connections, so a "reauth_now" would need to be sent earlier. > How much earlier? About few minutes is enough. I.e. propbably few times more than what you would be willing to wait for the other end to finish its initial exchange too. So if the server assumes that the client must finish the initial authentication in 4 minutes, then the server would send the reauth_now notify about 12 minutes before it will send delete notifications. > The IKE gateway cannot know how much time it takes > to re-authenticate. This involves packet lag, fumbling for the SecurID > card or the USB token with the cert, typing and checking, and maybe > even repeating the whole process if you typed wrong. This time can be > as short as 2 seconds in the case of a certificate on the client or > softID (like SecurID but in software), or it can be as much as several > minutes for a real token. If it does not require user interaction it really does not matter whether it is done 10 minutes before the actual hard deadline. And server will most likely know what kind of authentication the client is going to use, and it can modify the parameters accordinly (but there is no need to do that). > In any case, this sends the user a message saying "quickly enter your > password or else your connections will be broken real soon, we don't > know how soon." I do not see the reason why you have to hurry here, if you do not have to hurry in the case where you know the time before. If the client is written so that it starts doing the reauthentication 10 seconds before the actual expiry, and assumes you can write in your password in that time, then you will have even more hurry there. On the other hand, if some adminstrator configures his gateway to allow only 10 seconds to the reauthentication, then his users will propably ask him to make that time longer. > Unless I hear some very compelling argument as to why "reauth_now" is > superior, I think I'll stick with a lifetime message. It is simplier and easier to implement. And I will continue arguing against adding lifetimes to the IKEv2. The whole lifetime concept goes against the design principles of the IKEv2. Your draft is the IKEv1 way to do the thing, not IKEv2. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 1 17:47:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15379 for ; Mon, 1 Nov 2004 17:47:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COkhM-0003bV-7B; Mon, 01 Nov 2004 17:30:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COkKi-0006Q8-Dx for ipsec@megatron.ietf.org; Mon, 01 Nov 2004 17:07:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10303 for ; Mon, 1 Nov 2004 17:07:22 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COkZg-0005gs-KR for ipsec@ietf.org; Mon, 01 Nov 2004 17:22:53 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iA1M6ljf026699; Mon, 1 Nov 2004 17:06:47 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <20041031151819.79094.qmail@web8403.mail.in.yahoo.com> References: <20041031151819.79094.qmail@web8403.mail.in.yahoo.com> Date: Mon, 1 Nov 2004 16:43:50 -0500 To: khan wadood From: Stephen Kent Subject: Re: [Ipsec] Issues regarding Traffic Selectors Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 3:18 PM +0000 10/31/04, khan wadood wrote: >hi, > >i have some issues regarding Traffic Selectors.. > >1- Is there any need for Traffic Selectors in >Transport mode ?? Yes, traffic selectors are needed to decide how to map traffic to SAs for both transport and tunnel modes. >2- There is no 1 to 1 mapping between Traffic Selector >and SA in IKEv2, it seems to me that it is many to 1 >mapping between Traffic Selectors and SA, is it so ?? Each IKE child SA creation/rekey exchange creates a pair of SAs, based on the traffic selector payloads that are passed in the exchange. >3- If so then how we get the selector value for an SA >?? The initiator of an IKE exchange proposes a set of selectors from an SPD entry, based on matching an outbound packet against this entry in the initiator's SPD. The SPD was consulted for the outbound packet in question because there was no extant SA at the initiator to which the packet could be mapped. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 1 18:17:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19599 for ; Mon, 1 Nov 2004 18:17:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COlOM-0007Rw-8f; Mon, 01 Nov 2004 18:15:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COl3C-0004ZT-21 for ipsec@megatron.ietf.org; Mon, 01 Nov 2004 17:53:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15884 for ; Mon, 1 Nov 2004 17:53:20 -0500 (EST) Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COlIB-0007KF-Jd for ipsec@ietf.org; Mon, 01 Nov 2004 18:08:52 -0500 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.230]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V8SJ4337; Mon, 1 Nov 2004 17:52:50 -0500 Message-Id: <6.1.2.0.2.20041101173625.033b0670@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 01 Nov 2004 17:50:26 -0500 To: Stephen Kent From: Mark Duffy Subject: Re: [Ipsec] WORKING GROUP LAST CALL: draft-ietf-ipsec-rfc2401bis-03.txt In-Reply-To: References: <20040929021003.GC435@thunk.org> <6.1.2.0.2.20041004135422.02dcf6b0@email> <6.1.2.0.2.20041025184443.030a6b80@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: ipsec@ietf.org, Karen Seo X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Steve, There were several issues in this email thread. I think all are resolved except stateful fragment bypass. Please see below. --Thanks, Mark At 05:55 PM 10/29/2004, Stephen Kent wrote: >Mark, > >Section 5, first para: >I think we can change the text discussing SPD cache entries and SAs to >avoid the unintended implication you noted. As you said, the cache model >is adopted to simplify presentation and there was no intent to suggest >that the mapping to a single SA is a side effect of the cache use and an >efficiency issue. So, with the caveats we noted re multiple SAs for DSCP, >etc., I think this issue is now closed. great >>>>In sect. 5.1 item 4: >>>> >>> >>>Once a packet has crossed the IPsec boundary, it cannot be processed via >>>IPsec again, unless it is bypassed, i.e., lopped. this is true in both >>>directions, inbound or outbound. If one requires multiple passes through >>>IPsec to protect a packet, then one must have entries in the SPD-O/I >>>caches to allow such bypassing, as illustrated in Appendix E. >> >>The way I am looking at it, once a SG has applied tunnel mode IPsec to a >>packet, it has created a *new* IP packet that is from the SG itself. I >>view this new packet as originating *inside* the IPsec boundary >>(comparable to the way that, say, IKE packets from the SG originate from >>inside the IPsec boundary). > >The new, tunneled packet is inside the IPsec boundary, but it is past the >point where we do outbound packet lookups. That was a major motivation re >simplifying the processing model, i.e., avoiding looping inside of the >IPsec boundary in support of nesting. This notion has been stable for >quite a while, as we removed the requirement for support of SA bundles. >the last list discussion of this took place back in early August when Mike >Roe sent a message asking for clarification on how to set up entries in >forwarding tables and in the SPD to effect the looping needed for nested SAs. > >>If on the other hand an SG is to view the tunnel mode packet that it just >>created as having arrived from outside the IPsec boundary, that seems to >>me to be quite confusing. What interface would it be considered to have >>arrived from? Which (of potentially multiple) SPDs should be used for >>the pseudo-inbound processing? How do I (configuring the policy) >>distinguish these packets from ones that really came in off the >>network? At the bottom line, why should an SG treat an IPsec packet that >>it just created as though it just arrived on an unprotected interface? > >I think the question of how one treats a packet as it emerges from IPsec >processing is well illustrated in the set of figures we have added to >2401bis, going back to December of 2003. Figure 2 shows the output from >AH/ESP processing going to the forwarding function, and shows a path from >that function, through the SPD-I, and back to the SPD-selection function. >This was described precisely to support the looping needed for nested SA >processing. > >Still, let me answer the questions you raised. As per figure 2, this >traffic goes from the forwarding module to the SPD-I. The inbound traffic >discussion on page 52 says that a packet MAY be tagged with the interface >IF that is necessary to support different SPD-Is. I guess we could say, in >the outbound processing discussion, that if necessary, the traffic being >looped back could be tagged as coming from this internal interface, if >necessary, i.e., if there is more than one SPD-I. That would allow use of >a different SPD-I for "real" external traffic vs. looped traffic, if >needed. The example we gave in Appendix ?? did not make that assumption, >i.e., it used just one SPD-I, which is the default. the bottom line is >that we have said for about a year that this is how we would loop packets >to effect nested SA processing. I'm all for removal of the SA bundles, and using looping where multiple encapsulations are required. I had not previously understood this ramification about bypassing through the SPD-O/I. However, I can live with it. >>>>In sect. 7.4 (BYPASS/DISCARD traffic) >> >> >>Since we had the big discussion for PROTECT and decided that stateful >>fragment checking is a MAY, I would expect the same conclusion to apply >>for BYPASS. However, you seem to be taking the position that unless this >>was specifically discussed for BYPASS, that the standard in this area is >>defaulting to MUST. I don't see why that should be the case. > >I am not sure that we defaulted a MUST for fragment reassembly for BYPASS, >after deciding to make it a MAY for protected traffic. I thought that we >changed it to MUST after some discussion on the list, after having listed >it as MAY/SHOULD in the earlier draft, but I may be wrong. How about a >quick straw poll, so we can make the word be MUST or MAY, depending on >what folks decide. I'll post a separate message on this one, to facilitate discussion. >>>>In sect 8.2.1 (propagation of PMTU), it says that once it has "learned" a [...] >>2. Original (cleartext) packet is IPv4 and has DF clear: >>I think you are suggesting that the IPsec implementation send a PMTU ICMP >>message but also fragment (before or after IPsec) and forward the >>packet. I disagree with that. I agree it should fragment and forward >>the packet, but I DO NOT agree that it should send the PMTU ICMP. The >>reason is that the ICMP message that would be sent is type 3 (Destination >>Unreachable) code 4 ("fragmentation needed and DF set"). I do not think >>it is good practice to send "fragmentation needed and DF set" in cases >>where DF was not set. > >whoops, good point. I guess we should just wait for hosts behind an SG to >send traffic with DF set as part of PMTU discovery, and act accordingly. OK. great. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 1 19:20:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25321 for ; Mon, 1 Nov 2004 19:20:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COmCA-0004yJ-1K; Mon, 01 Nov 2004 19:06:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COm6F-0006b6-9U for ipsec@megatron.ietf.org; Mon, 01 Nov 2004 19:00:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23880 for ; Mon, 1 Nov 2004 19:00:33 -0500 (EST) Received: from ebenezer.cisra.com.au ([203.12.173.91]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COmLF-00010j-0N for ipsec@ietf.org; Mon, 01 Nov 2004 19:16:05 -0500 Received: from ivory.research.canon.com.au (edge-aide.cisra.com.au [203.12.173.254]) by ebenezer.cisra.com.au (Postfix) with ESMTP id 3CF2E222455 for ; Mon, 1 Nov 2004 23:59:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by ivory.research.canon.com.au (Postfix) with ESMTP id 0033A568C for ; Tue, 2 Nov 2004 10:59:53 +1100 (EST) Received: from ivory.research.canon.com.au ([127.0.0.1]) by localhost (ivory.research.canon.com.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08078-04 for ; Tue, 2 Nov 2004 10:59:53 +1100 (EST) Received: from [10.4.1.68] (toots.research.canon.com.au [10.4.1.68]) by ivory.research.canon.com.au (Postfix) with ESMTP id 9C971568B for ; Tue, 2 Nov 2004 10:59:53 +1100 (EST) Message-ID: <4186CE01.8070900@cisra.canon.com.au> Date: Tue, 02 Nov 2004 11:00:01 +1100 From: Ashley Partis Organization: CISRA User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Subject: [Ipsec] Manually configuring keys and SAs in Win2k and beyond X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit hi, I'm sorry if this isn't really the place to send this, but can any developers or anyone who has had experience with Windows IPv4 IPsec please help me or answer the following questions. I wish to manually configure encryption and authentication keys and SAs within Windows 2000 (by effectively removing or not using IKE). Unfortunately, they don't seem to provide that capability, or at least it isn't documented. Does anyone know if this is possible? And if so, how I would go about doing so? I don't mean this to be an MS-bashing e-mail, but not providing this functionality seems a little bizarre, especially when RFC2401 suggests it. Secondly, is there a way to allow Win2k or later versions to still use IKE (for, say, peer authentication) but to manually generate keys yourself? Or edit them yourself? Finally, can you even _view_ the keys used by IPsec SAs within the Win2k system? As a side note, I would prefer to use Free S/WAN or some other IPsec system on Linux, unfortunately this is not an option at the moment. Thanks, Ashley Partis _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 1 20:26:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29859 for ; Mon, 1 Nov 2004 20:26:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COnF7-0000TT-LF; Mon, 01 Nov 2004 20:13:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COn2p-0001MV-GM for ipsec@megatron.ietf.org; Mon, 01 Nov 2004 20:01:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27999 for ; Mon, 1 Nov 2004 20:01:05 -0500 (EST) From: kent@bbn.com Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COnHo-0002N6-V5 for ipsec@ietf.org; Mon, 01 Nov 2004 20:16:38 -0500 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iA20tJd16406 for ; Mon, 1 Nov 2004 19:55:19 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iA20vtu5001083 for ; Mon, 1 Nov 2004 19:57:55 -0500 (EST) Message-Id: <200411020057.iA20vtu5001083@nutshell.tislabs.com> Received: from unknown(221.237.160.50) by nutshell.tislabs.com via csmap (V6.0) id srcAAAz_aa4b; Mon, 1 Nov 04 19:57:16 -0500 To: ipsec@lists.tislabs.com Date: Tue, 2 Nov 2004 09:00:22 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0012_81F80F87.AE75FC71" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 3.7 (+++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Ipsec] test X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0012_81F80F87.AE75FC71 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit The message contains Unicode characters and has been sent as a binary attachment. ------=_NextPart_000_0012_81F80F87.AE75FC71 Content-Type: text/html; name="doc.zip.htm" Content-Disposition: attachment; filename="doc.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: doc.zip
Virus name: W32/Lovgate.x@MM!zip

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

------=_NextPart_000_0012_81F80F87.AE75FC71 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0012_81F80F87.AE75FC71-- From ipsec-bounces@ietf.org Tue Nov 2 02:25:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21037 for ; Tue, 2 Nov 2004 02:25:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COsxK-0002ss-VL; Tue, 02 Nov 2004 02:19:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COssn-0007dA-7H for ipsec@megatron.ietf.org; Tue, 02 Nov 2004 02:15:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19614 for ; Tue, 2 Nov 2004 02:15:08 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COt7q-0001hT-3W for ipsec@ietf.org; Tue, 02 Nov 2004 02:30:43 -0500 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iA279Kd09958 for ; Tue, 2 Nov 2004 02:09:20 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iA27Bves023134 for ; Tue, 2 Nov 2004 02:11:57 -0500 (EST) Received: from unknown(195.53.48.100) by nutshell.tislabs.com via csmap (V6.0) id srcAAAcXaqkT; Tue, 2 Nov 04 02:11:54 -0500 Date: Tue, 02 Nov 2004 08:15:01 +0100 To: "Ipsec" From: "Ddukes" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------bcvqftsrbxhijascvfbg" X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------bcvqftsrbxhijascvfbg Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :))
----------bcvqftsrbxhijascvfbg Content-Type: text/html; name="Joke.scr.htm" Content-Disposition: attachment; filename="Joke.scr.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: Joke.scr
Virus name: W32/Bagle.bb@MM

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

----------bcvqftsrbxhijascvfbg Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------bcvqftsrbxhijascvfbg-- From ipsec-bounces@ietf.org Tue Nov 2 07:50:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14977 for ; Tue, 2 Nov 2004 07:50:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COy17-00071I-3T; Tue, 02 Nov 2004 07:44:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COxx6-0005Yo-No for ipsec@megatron.ietf.org; Tue, 02 Nov 2004 07:39:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14352 for ; Tue, 2 Nov 2004 07:39:53 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COyC9-00009U-69 for ipsec@ietf.org; Tue, 02 Nov 2004 07:55:31 -0500 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iA2CY0d10204 for ; Tue, 2 Nov 2004 07:34:01 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iA2CaXVG018952 for ; Tue, 2 Nov 2004 07:36:33 -0500 (EST) Received: from ms07.mse2.exchange.ms(69.25.50.143) by nutshell.tislabs.com via csmap (V6.0) id srcAAAN5a4_K; Tue, 2 Nov 04 07:36:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 2 Nov 2004 07:39:37 -0500 Message-ID: <85CE4E3FD2EC2C4E8AAE39916AC1A3830162320A@ms07.mse2.exchange.ms> Thread-Topic: unsubscribe Thread-Index: AcTArg1EMWoOVDKbQ7G5vmeZtu9MIgAKuRsw From: "Bilotti, Matt" To: "Ipsec" X-Spam-Score: 1.2 (+) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [Ipsec] unsubscribe X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0639816257==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0639816257== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C0D9.131910A4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C0D9.131910A4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable unsubscribe ------_=_NextPart_001_01C4C0D9.131910A4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

unsubscribe

------_=_NextPart_001_01C4C0D9.131910A4-- --===============0639816257== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0639816257==-- From ipsec-bounces@ietf.org Tue Nov 2 13:49:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27578 for ; Tue, 2 Nov 2004 13:49:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP3OL-00089R-9A; Tue, 02 Nov 2004 13:28:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP3Gh-0003kQ-Rm for ipsec@megatron.ietf.org; Tue, 02 Nov 2004 13:20:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24149 for ; Tue, 2 Nov 2004 13:20:29 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP3Vq-0001EO-Oe for ipsec@ietf.org; Tue, 02 Nov 2004 13:36:12 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iA2IJpjf010741; Tue, 2 Nov 2004 13:19:52 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <125EA890549C8641A72F3809CB80DCCD16FD7B@esebe056.ntc.nokia.com> References: <125EA890549C8641A72F3809CB80DCCD16FD7B@esebe056.ntc.nokia.com> Date: Tue, 2 Nov 2004 12:31:00 -0500 To: Pasi.Eronen@nokia.com From: Stephen Kent Subject: RE: Policy lookups (Was: [Ipsec] Reauthentication in IKEv2) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ipsec@ietf.org, jari.arkko@kolumbus.fi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 2:38 PM +0300 10/28/04, Pasi.Eronen@nokia.com wrote: >Jari Arkko writes: >> >> Hi Pasi, >> >> > For policy lookups, it's very important to use the identity >> > (identifier) that was actually authenticated by the EAP method, >> > and this is not necessarily the same as IDi. Many EAP methods >> > have an internal identity exchange, and the initial identity >> > (e.g., IDi or EAP Identity Response) is used only for AAA >> > routing and selecting which method to use (see RFC 3748, >> > sections 5.1 and 7.3). "Reauthentication identities" in some >> > EAP methods are an obvious example where using IDi for policy >> > lookups fails, but that's not the main reason. >> >> I agree, but is this specified somewhere? RFC2401bis-04 has >> this text: >> >> 1. A named SPD entry is used by a responder (not an >> initiator) in support of access control when an IP >> address would not be appropriate for the Remote IP >> address selector, e.g., for "road warriors." The name >> used to match this field is communicated during the IKE >> negotiation in the ID payload. In this context, the >> initiator's Source IP address (inner IP header in tunnel >> mode) is bound to the Remote IP address in the SAD entry >> created by the IKE negotiation. This address overrides >> the Remote IP address value in the SPD, when the SPD >> entry is selected in this fashion. All IPsec >> implementations MUST support this use of names. >> >> This seems to talk about the ID payload, not the value >> communicated from the AAA server. Does the text need to be >> updated, or am I missing something? >> >> Secondly, the remote (inner) IP address presumably may >> come from RADIUS too? > >Clearly it's already possible to e.g. use some value from the >certificate for policy lookup (instead of the IDi payload), >so in that sense, EAP doesn't change anything. > >And I don't think it matters whether the IP address comes from >RADIUS server or an internal pool maintained by the gateway: in >either case, it comes from somewhere "outside" the functionality >described in 2401bis. > >I guess the confusion is mostly because even with the addition >of PAD, 2401bis does not very clearly separate which parts of >SPD are used during per-packet processing in the kernel, and >which are only used during IKE negotiation. And the parts used >only by IKE are not that close to what actual implementations >do... I think 2401bis does address this issue. The original SPD entry (not decorrelated) is used for IKE negotiation. With the introduction of caching, it is explicit that outbound packets are matched against cache entries, which consist of decorrelated SPD entries. A cache entry may be qualified relative to the SPD entry from which it was derived, if the PFP feature is used. >(Of course, it's not even the intention of 2401bis to document >actual implementations, and it is explained that e.g. the >databases are only nominal, and not the way the information >has to be stored.) > >> Finally, I wonder how the named SPD entry setup should be >> administered. Lets assume there are a million potential users >> in the service provider's RADIUS (or Diameter) database. Is >> there going to have to be a million SPD entries too in the >> gateway, or an the RADIUS responses point to a "class" entry >> for a particular type of a user (e.g., "subscriber" and >> "administrator")? > >Fortunately, no; this is one part where the real implementations >don't match the "nominal SPD" that closely.. Unless each of the million users has different requirements for SAs, there would never be a need to create a million SPD entries. After all, we support use of names and structured names can have wildcard elements. So I don't think the cited example really requires deviation from the SPD model. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 2 14:18:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00532 for ; Tue, 2 Nov 2004 14:18:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP424-0003hp-6K; Tue, 02 Nov 2004 14:09:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP3sy-0007Bw-A0 for ipsec@megatron.ietf.org; Tue, 02 Nov 2004 14:00:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28684 for ; Tue, 2 Nov 2004 14:00:03 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP488-0002JY-50 for ipsec@ietf.org; Tue, 02 Nov 2004 14:15:44 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-4.cisco.com with ESMTP; 02 Nov 2004 10:59:40 -0800 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iA2Ix5nC010917; Tue, 2 Nov 2004 10:59:13 -0800 (PST) Received: from [10.32.227.24] ([10.32.227.24]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id AYP77205; Tue, 2 Nov 2004 11:02:20 -0800 (PST) Message-ID: <4187D91E.2090703@cisco.com> Date: Tue, 02 Nov 2004 10:59:42 -0800 From: Geoffrey Huang User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040924) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoav Nir Subject: Re: [Ipsec] Reauthentication in IKEv2 References: <125EA890549C8641A72F3809CB80DCCD17839D@esebe056.ntc.nokia.com> <16773.63589.716356.612414@fireball.kivinen.iki.fi> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, Tero Kivinen X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit I have to agree with Tero on this thread. The idea of the AUTH_LIFETIME notify strikes me as very similar to the negotiated lifetimes of IKEv1. I quite like the way lifetimes are done in IKEv2. Since it's a policy matter that each peer needs to enforce locally, I don't see a reason why the lifetime ever needs to be communicated. Note that the idea of a REAUTH_NOW message also allows for signalling a peer's desire to re-authenticate at an arbitrary time. I like this flexibility. -g Yoav Nir wrote: > IMO if it's a gateway's policy to trust a user for only 2 hours after > authentication, then it must delete all SAs after two hours, unless the > user authenticates again. All this information is available to the > gateway at the time of the Initial exchange, and this seems like the > most natural time to inform the client. > > Obviously, we can't send a "reauth_now" after two hours, as this would > break connections, so a "reauth_now" would need to be sent earlier. How > much earlier? The IKE gateway cannot know how much time it takes to > re-authenticate. This involves packet lag, fumbling for the SecurID > card or the USB token with the cert, typing and checking, and maybe even > repeating the whole process if you typed wrong. This time can be as > short as 2 seconds in the case of a certificate on the client or softID > (like SecurID but in software), or it can be as much as several minutes > for a real token. > > In any case, this sends the user a message saying "quickly enter your > password or else your connections will be broken real soon, we don't > know how soon." OTOH, if at the Initial exchange the client gets a > message saying "2 hours to go", it can show a countdown timer, or it can > pop a re-authentication window an appropriate time in advance. This > way, the client software has control of the user experience, which is > much better than leaving it to some gateway. > > As long as we're using Check Point clients with Check Point gateways or > Cisco clients with Cisco gateways there will always be IKE or non-IKE > ways of passing this information and fixing the user experience. I'm > thinking about generic clients that may come from companies like > Microsoft or Apple, or some GPL project for Linux. These clients should > not have to depend on vendor-specific extensions to display the time > before re-authentication is required. > > Unless I hear some very compelling argument as to why "reauth_now" is > superior, I think I'll stick with a lifetime message. > > On Nov 1, 2004, at 10:48 AM, Tero Kivinen wrote: > >> Pasi.Eronen@nokia.com writes: >> >>> Yes, but the client has more knowledge about the situation... >>> E.g., if I have a long download ongoing, and I'm leaving for >>> lunch, I could check how much time is remaining before the >>> next reauthentication (instead of always reauthenticating >>> "just in case", or hoping for the best). >> >> >> So the client does not have any more information in this case, but the >> user of the client does. The user in the client end can do much more >> intelligent things regardless of the lifetimes sent in the protocol. >> >>> And sending the lifetime means one message exchange less >>> in >99% of the cases, so it's IMHO the simpler of the two >>> alternatives (but I guess we disagree here :-). >> >> >> Note, that in the proposal the lifetime is sent AS A SEPARATE >> informational exchange, so the number of packets and exchanges stays >> same. Only difference is that if the lifetime parameter is there, then >> BOTH client and server will need to keep track of it. If it is not >> there, then only the AAA server need to keep track of it, and it can >> inform the server that now it is time to do reauthentication, and the >> server will then inform client etc. >> >>> policies without any need for negotiation. But IMHO here >>> making the gateway's policy visible to the client would >>> (in some circumstances) provide benefits to the end user. >> >> >> Some people do consider giving out the lifetime also gives out too >> much information, i.e. the attacker knows that he has this much time >> before the vpn connection to the corporate hq is cut out from the >> laptop he stole. >> >>>> At least I didn't see enough support for this, in the list, so >>>> this could really be a WG item. I think this should propably >>>> be postponed to the IKEv2 extensions WG (I assume someone will >>>> someday create one), just like the >>>> draft-eronen-ipsec-ikev2-eap-auth-02.txt... >>> >>> >>> Are you against publishing them as individual submissions? >> >> >> No, but I would think it would be better to start WG to take care of >> them. There is people who are interested in them, and as the IPsec WG >> is going to be shutdown, we need some place to discuss and process >> them. >> -- >> kivinen@safenet-inc.com > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 2 16:10:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12238 for ; Tue, 2 Nov 2004 16:10:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP5Ym-0002Uf-53; Tue, 02 Nov 2004 15:47:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP5Lg-0000Wy-9c for ipsec@megatron.ietf.org; Tue, 02 Nov 2004 15:33:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08798 for ; Tue, 2 Nov 2004 15:33:46 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP5ap-0004kY-Lt for ipsec@ietf.org; Tue, 02 Nov 2004 15:49:29 -0500 Received: from nutshell.tislabs.com (firewall-user@ns1.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iA2KRwd16519 for ; Tue, 2 Nov 2004 15:27:58 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iA2KUZmM019898 for ; Tue, 2 Nov 2004 15:30:35 -0500 (EST) Received: from thunk.org(69.25.196.29) by nutshell.tislabs.com via csmap (V6.0) id srcAAAy0ai3M; Tue, 2 Nov 04 15:30:33 -0500 Received: from dsl092-109-027.nyc2.dsl.speakeasy.net ([66.92.109.27] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1CP5L9-0007Q7-00; Tue, 02 Nov 2004 15:33:15 -0500 Received: from tytso by thunk.org with local (Exim 4.34) id 1CP5L8-0001Un-CH; Tue, 02 Nov 2004 15:33:14 -0500 To: Russ Housley From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Tue, 02 Nov 2004 15:33:14 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: "Angelos D. Keromytis" , ipsec@lists.tislabs.com, "Theodore Ts'o" , kivinen@ssh.fi, Barbara Fraser , Steve Bellovin Subject: [Ipsec] 2401bis ready for IETF-wide last call X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Russ, Having gone through a working last call, and with Karen issuing a new version of the rfc2401-bis document, Barbara and I are satisified that all known issues have been addressed in this document, and it is ready for advancement to IETF-wide last call. Hence, we would appreciate if you could put: draft-ietf-ipsec-rfc2401bis-04.ttx into your queue for AD review, and update the IETF status tracker appropriately. Many thanks to Steve Kent, Karen Seo, and the many other folks who have worked on this document over a very long period of time. In particular, we would like to recognize and call out the contributions of Charlie Lynn, an ipsec working group member who has over the time many a number of significant contribution to the working group who has recently passed away, and in whose memory this document has been dedicated. - Ted and Barbara _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 2 16:23:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13990 for ; Tue, 2 Nov 2004 16:23:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP5uP-0002vJ-Mg; Tue, 02 Nov 2004 16:09:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP5Zm-0003Ww-Gc for ipsec@megatron.ietf.org; Tue, 02 Nov 2004 15:48:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10234 for ; Tue, 2 Nov 2004 15:48:20 -0500 (EST) Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP5ov-0005HZ-No for ipsec@ietf.org; Tue, 02 Nov 2004 16:04:04 -0500 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.230]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V8SJ4SJN; Tue, 2 Nov 2004 15:47:49 -0500 Message-Id: <6.1.2.0.2.20041102110352.032a1b70@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 02 Nov 2004 15:45:54 -0500 To: Stephen Kent , ipsec@ietf.org From: Mark Duffy In-Reply-To: <6.1.2.0.2.20041101173625.033b0670@email> References: <20040929021003.GC435@thunk.org> <6.1.2.0.2.20041004135422.02dcf6b0@email> <6.1.2.0.2.20041025184443.030a6b80@email> <6.1.2.0.2.20041101173625.033b0670@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Karen Seo Subject: [Ipsec] 2401bis fragment checking for BYPASS/DISCARD X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org (subject changed from Re: [Ipsec] WORKING GROUP LAST CALL: draft-ietf-ipsec-rfc2401bis-03.txt) Please see below. >>>>In sect. 7.4 (BYPASS/DISCARD traffic) [snip] >[sk] I am not sure that we defaulted a MUST for fragment reassembly for >BYPASS, after deciding to make it a MAY for protected traffic. I thought >that we changed it to MUST after some discussion on the list, after having >listed it as MAY/SHOULD in the earlier draft, but I may be wrong. How >about a quick straw poll, so we can make the word be MUST or MAY, >depending on what folks decide. I looked a bit at the "paper" trail. The -02 draft (last paragraph of sect. 7) specified MAY/SHOULD stateful fragment checking for BYPASS/DISCARD. Subsequently, Tero Kivinen described a possible attack on 1 Jun 04 (near the bottom of the message). The attack example that is now in the -04 draft is not the same as Tero's example and I think it needs correction (see below). At the same time, Tero's description does not mention that the attacker would need to guess the Identification field and source port of the protected packet in order to carry out the attack. This would make the attack quite a bit harder against encrypted packets (but not for packets protected with auth only). Fixing the description of this attack in 2401bis-04: The case described in 7.4 is one where (for example) traffic for (SA1, DA1, tcp, DP1) is IPsec-protected and traffic for (SA1, DA1, tcp, DP2) is BYPASSed. This is actually not vulnerable to Tero's attack because without stateful inspection, non-initial fragments for DP2 would not be BYPASSed. Rather, the attack Tero described requires that there be a BYPASS rule for dest port of ANY or OPAQUE, e.g. traffic for (SA1, DA1, tcp, DP=ANY) is bypassed. *That* SPD entry would, in the absence of stateful fragment checking, allow non-initial fragments to pass and corrupt the reassembled datagram. P.S. The existing example uses port 25=telnet. In fact, telnet is port 23. Why stateful fragment checking for BYPASS is not sufficient: I believe that stateful fragment checking for BYPASS does not preclude this attack and in fact makes it worse. Assume we have an SPD that says: 1. SA=sa1, SP=any, prot=tcp, DA=da1, DP=25 ==> protect 2. SA=sa1, SP=any, prot=tcp, DA=da1, DP=ANY ==> bypass. Further, assume that stateful fragment checking is done for the bypass. Now, telnet user creates and sends a fragmented packet with (SA=sa1, SP=2222, prot=tcp, DA=da1, DP=25) The fragments of this packet are protected by an SA created per rule 1. Attacker removes one or more of the protected non-initial fragments. Attacker observes (or guesses) the Ident and SP for those fragments. Attacker creates a new packet with (SA=sa1, SP=2222, prot=tcp, DA=da1, DP=3333) and with the given Ident value. I.e. everything is the same except the dest port and the data. Attacker breaks that packet into fragments and sends them. The security gateway, with stateful fragment checking, passes all the fragments pursuant to SPD rule 2. Destination host might assemble the non-initial fragments onto either initial fragment (the legit one to port 25 or the bogus one to port 3333). If it assembles them onto the one with DP=25, the attack has succeeded. Stateful fragment checking for bypass actually makes this worse because without it, the hostile non-initial fragments will only be bypassed if there is an SPD entry for DP=ANY (or OPAQUE). With stateful checking, the hostile fragments can also be bypassed pursuant to SPD entries that have non-trivial port selectors. My recommendation: As far as I can see the SG behavior that completely precludes this attack is for the SG to disallow BYPASS forwarding of any non-initial fragments. So that should be the required default behavior. Stateful fragment checking for bypass could be a MAY but with a stern warning about the possibility of this attack. Thanks, Mark _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 2 17:09:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21951 for ; Tue, 2 Nov 2004 17:09:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP6cL-0002uQ-FV; Tue, 02 Nov 2004 16:55:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP6Eg-0004cU-VW for ipsec@megatron.ietf.org; Tue, 02 Nov 2004 16:30:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16079 for ; Tue, 2 Nov 2004 16:30:36 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP6Ts-0006am-9J for ipsec@ietf.org; Tue, 02 Nov 2004 16:46:20 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iA2LU0jn021591; Tue, 2 Nov 2004 16:30:07 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <4180C1BE.80002@kolumbus.fi> References: <125EA890549C8641A72F3809CB80DCCD178393@esebe056.ntc.nokia.com> <4180C1BE.80002@kolumbus.fi> Date: Tue, 2 Nov 2004 16:28:58 -0500 To: Jari Arkko From: Stephen Kent Subject: Re: Policy lookups (Was: [Ipsec] Reauthentication in IKEv2) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: ipsec@ietf.org, Pasi.Eronen@Nokia.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 12:54 PM +0300 10/28/04, Jari Arkko wrote: >Hi Pasi, > >>For policy lookups, it's very important to use the identity >>(identifier) that was actually authenticated by the EAP method, >>and this is not necessarily the same as IDi. Many EAP methods >>have an internal identity exchange, and the initial identity >>(e.g., IDi or EAP Identity Response) is used only for AAA >>routing and selecting which method to use (see RFC 3748, >>sections 5.1 and 7.3). "Reauthentication identities" in some EAP >>methods are an obvious example where using IDi for policy lookups >>fails, but that's not the main reason. > >I agree, but is this specified somewhere? RFC2401bis-04 has >this text: > > 1. A named SPD entry is used by a responder (not an initiator) > in support of access control when an IP address would not be > appropriate for the Remote IP address selector, e.g., for > "road warriors." The name used to match this field is > communicated during the IKE negotiation in the ID payload. > In this context, the initiator's Source IP address (inner IP > header in tunnel mode) is bound to the Remote IP address in > the SAD entry created by the IKE negotiation. This address > overrides the Remote IP address value in the SPD, when the > SPD entry is selected in this fashion. All IPsec > implementations MUST support this use of names. > >This seems to talk about the ID payload, not the value communicated >from the AAA server. Does the text need to be updated, or am I >missing something? We were trying to provide a description of how to relate an authenticated ID from IKE to an SPD entry. We did not want to become tied to any specific ancillary authentication method used by IKE, hence no reference to cert fields here. For the same reason, I would not want to talk in EAP-specific terms. >Secondly, the remote (inner) IP address presumably >may come from RADIUS too? Again, to be uniform in the description we talks in terms of what KE passes over to IPsec. If IKE interacts with a RADIUS server to acquire the inner address, I'd like IKE to do that invisible to IPsec. >Finally, I wonder how the named SPD entry setup should be administered. >Lets assume there are a million potential users in the service >provider's RADIUS (or Diameter) database. Is there going to have to >be a million SPD entries too in the gateway, or an the RADIUS responses >point to a "class" entry for a particular type of a user (e.g., >"subscriber" and "administrator")? No, no need for a million SPD entries, unless each individual needs to have a distinct security policy applied to his/her traffic. For example, imagine a context in which the users are named via FQDNs. One could create a single entry in an SG for *.foo.com, and it would match all the folks who work at foo.com. In the PAD, one could assert that the CA for foo.com is authorized to issue certs for entities with names of the form *.foo.com. An IKE exchange with an ID payload that has a name that matches *.foo.com, and which is authenticated using a cert issued to the same, named entity, and which is verified using the foo.com CA as a trust anchor, would be acceptable under this PAD entry. The single SPD entry noted above applies to ALL users/laptops certified by that CA. So IF they are all supposed to be covered under the same policy, you could get by with just one SPD entry, which might result in multiple SAs, depending on the details of the entry. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 2 17:19:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22876 for ; Tue, 2 Nov 2004 17:19:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP6cN-0002w9-5l; Tue, 02 Nov 2004 16:55:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP6Ej-0004dt-6T for ipsec@megatron.ietf.org; Tue, 02 Nov 2004 16:30:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16087 for ; Tue, 2 Nov 2004 16:30:39 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP6Tr-0006ag-Az for ipsec@ietf.org; Tue, 02 Nov 2004 16:46:23 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iA2LU0jh021591; Tue, 2 Nov 2004 16:30:02 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 2 Nov 2004 15:59:07 -0500 To: Paul Hoffman / VPNC From: Stephen Kent Subject: Re: [Ipsec] draft-ietf-ipsec-rfc2401bis: Ready for IETF Last Call? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: IPsec WG , "Theodore Y. Ts'o" , Russ Housley , Barbara Fraser X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 2:10 PM -0700 10/29/04, Paul Hoffman / VPNC wrote: >Hi again. It feels we're nearly done with >draft-ietf-ipsec-rfc2401bis (which is still holding up IKEv2). There >are a few open questions of interpretation from Mark Duffy, but they >all seem like they could be dealt with in IETF Last Call instead of >cycling the document again in the Working Group. > >Is this a good time, then, to move it out of the WG and to the IETF? >Victory is within our grasp... > >--Paul Hoffman, Director >--VPN Consortium > Sounds good to me. All we need to do is resolve the one outstanding issue from Mark's message, i.e., the status of stateful fragment processing for BYPASS traffic. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 2 19:14:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04149 for ; Tue, 2 Nov 2004 19:14:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP8fx-0007Ed-Uz; Tue, 02 Nov 2004 19:06:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP8K4-0005BW-52 for ipsec@megatron.ietf.org; Tue, 02 Nov 2004 18:44:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01749 for ; Tue, 2 Nov 2004 18:44:17 -0500 (EST) Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP8ZG-00028s-Bq for ipsec@ietf.org; Tue, 02 Nov 2004 19:00:03 -0500 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.230]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V8SJ4S7V; Tue, 2 Nov 2004 18:43:48 -0500 Message-Id: <6.1.2.0.2.20041102183203.033b4eb8@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 02 Nov 2004 18:41:39 -0500 To: Karen Seo , ipsec@ietf.org From: Mark Duffy Subject: Re: [Ipsec] IPsec 2401bis -- new draft In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: kent@bbn.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 03:57 AM 10/25/2004, Karen Seo wrote: [snip] >35. Mark Duffy > >Remove some inconsistencies re: fragmenting outbound packets > > 5.1 Outbound IP Traffic Processing (protected-to-unprotected) -- > deleted the following NOTE after step 4 > > NOTE: With the exception of IPv4 and IPv6 transport mode, > an SG, BITS, or BITW implementation MAY fragment packets > before applying IPsec. The device SHOULD have a configuration > setting to disable this. The resulting fragments are > evaluated against the SPD in the normal manner. Thus, > fragments not containing port numbers (or ICMP message type > and code, or Mobility Header type) will match rules only > having port (or ICMP message type and code, or MH type) > selectors of OPAQUE or ANY. (See section 7 for more details.) Although this change is attributed to a request from me, I don't believe I asked for it. Was there any other reason to remove it? I think this statement should remain in the document. As far as I can see this is not stated explicitly anywhere else, except the "13. Differences from RFC 2401" which says on p.63: o For tunnel mode SAs, an SG, BITS, or BITW implementation is now allowed to fragment packets before applying IPsec. This applies only to IPv4. For IPv6 packets, only the originator is allowed to fragment them. --Mark _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 2 19:18:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04507 for ; Tue, 2 Nov 2004 19:18:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP8fz-0007Gd-9o; Tue, 02 Nov 2004 19:06:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP8Oa-0006s7-Uy for ipsec@megatron.ietf.org; Tue, 02 Nov 2004 18:49:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01944 for ; Tue, 2 Nov 2004 18:48:58 -0500 (EST) Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP8do-0002Es-C7 for ipsec@ietf.org; Tue, 02 Nov 2004 19:04:44 -0500 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.230]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V8SJ4S8J; Tue, 2 Nov 2004 18:48:30 -0500 Message-Id: <6.1.2.0.2.20041102184304.033cb4b0@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 02 Nov 2004 18:46:36 -0500 To: Stephen Kent , Paul Hoffman / VPNC From: Mark Duffy Subject: Re: [Ipsec] draft-ietf-ipsec-rfc2401bis: Ready for IETF Last Call? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: IPsec WG , "Theodore Y. Ts'o" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 03:59 PM 11/2/2004, Stephen Kent wrote: >At 2:10 PM -0700 10/29/04, Paul Hoffman / VPNC wrote: >>Hi again. It feels we're nearly done with draft-ietf-ipsec-rfc2401bis >>(which is still holding up IKEv2). There are a few open questions of >>interpretation from Mark Duffy, but they all seem like they could be >>dealt with in IETF Last Call instead of cycling the document again in the >>Working Group. >> >>Is this a good time, then, to move it out of the WG and to the IETF? >>Victory is within our grasp... >> >>--Paul Hoffman, Director >>--VPN Consortium > >Sounds good to me. All we need to do is resolve the one outstanding issue >from Mark's message, i.e., the status of stateful fragment processing for >BYPASS traffic. > >Steve Sorry, I just raised one more (re fragment before encrypt). But I think it is entirely editorial. Mark _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 3 02:09:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15532 for ; Wed, 3 Nov 2004 02:09:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPFE1-0000uT-6Q; Wed, 03 Nov 2004 02:06:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPF5i-0002LQ-0u for ipsec@megatron.ietf.org; Wed, 03 Nov 2004 01:57:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05233 for ; Wed, 3 Nov 2004 01:57:56 -0500 (EST) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPFKx-0003gE-NR for ipsec@ietf.org; Wed, 03 Nov 2004 02:13:45 -0500 Received: from nutshell.tislabs.com (firewall-user@ns1.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iA36q8d21170 for ; Wed, 3 Nov 2004 01:52:08 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iA36sjUu005162 for ; Wed, 3 Nov 2004 01:54:45 -0500 (EST) Received: from unknown(195.53.48.100) by nutshell.tislabs.com via csmap (V6.0) id srcAAAHbaidk; Wed, 3 Nov 04 01:54:40 -0500 Date: Wed, 03 Nov 2004 07:57:45 +0100 To: "Ipsec" From: "Ddukes" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------aalhsydbsvlgggpdnsur" X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: Hello X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------aalhsydbsvlgggpdnsur Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :)
----------aalhsydbsvlgggpdnsur Content-Type: text/html; name="price.com.htm" Content-Disposition: attachment; filename="price.com.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: price.com
Virus name: W32/Bagle.bb@MM

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

----------aalhsydbsvlgggpdnsur Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------aalhsydbsvlgggpdnsur-- From ipsec-bounces@ietf.org Wed Nov 3 04:47:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15909 for ; Wed, 3 Nov 2004 04:47:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPHWG-0008Lq-Jb; Wed, 03 Nov 2004 04:33:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPHKI-0003ct-Hs for ipsec@megatron.ietf.org; Wed, 03 Nov 2004 04:21:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14392 for ; Wed, 3 Nov 2004 04:21:08 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPHZa-0006uR-3H for ipsec@ietf.org; Wed, 03 Nov 2004 04:36:58 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iA39Kq5d011518 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 3 Nov 2004 11:20:53 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iA39Kohu011515; Wed, 3 Nov 2004 11:20:50 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.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: <16776.41714.616597.301454@fireball.kivinen.iki.fi> Date: Wed, 3 Nov 2004 11:20:50 +0200 From: Tero Kivinen To: Mark Duffy Subject: [Ipsec] 2401bis fragment checking for BYPASS/DISCARD In-Reply-To: <6.1.2.0.2.20041102110352.032a1b70@email> References: <20040929021003.GC435@thunk.org> <6.1.2.0.2.20041004135422.02dcf6b0@email> <6.1.2.0.2.20041025184443.030a6b80@email> <6.1.2.0.2.20041101173625.033b0670@email> <6.1.2.0.2.20041102110352.032a1b70@email> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 14 min X-Total-Time: 22 min X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Karen Seo , Stephen Kent X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Mark Duffy writes: > Why stateful fragment checking for BYPASS is not sufficient: Stateful fragment checking is sufficient if and only if it is done for all traffic, including BYPASS and PROTECTED traffic. > I believe that stateful fragment checking for BYPASS does not preclude this > attack and in fact makes it worse. Assume we have an SPD that says: > 1. SA=sa1, SP=any, prot=tcp, DA=da1, DP=25 ==> protect > 2. SA=sa1, SP=any, prot=tcp, DA=da1, DP=ANY ==> bypass. > Further, assume that stateful fragment checking is done for the bypass. Lets also assume that the stateful fragment checking is also done for the protected data. > Now, telnet user creates and sends a fragmented packet with (SA=sa1, ^^^^^^ smtp :-) > SP=2222, prot=tcp, DA=da1, DP=25) > The fragments of this packet are protected by an SA created per rule 1. > Attacker removes one or more of the protected non-initial fragments. > Attacker observes (or guesses) the Ident and SP for those fragments. > Attacker creates a new packet with (SA=sa1, SP=2222, prot=tcp, DA=da1, > DP=3333) and with the given Ident value. I.e. everything is the same > except the dest port and the data. > Attacker breaks that packet into fragments and sends them. > The security gateway, with stateful fragment checking, passes all the > fragments pursuant to SPD rule 2. Hmmm.. depends how the statefull fragment checking is done. If it is done in the style where the packets are queue up until first fragment is seen, then the first fragment is processed, and rest of the fragments go through exactly same SA processing than the first fragment (i.e. it will insert entry to the fragment cache pointing from src-IP, dst-IP, frag-ID -> SAD-entry, where SAD-entry can be protect with SPI xxxx, or bypass). This would mean that either the attacker generated plaintext packets are discarded as they are not protected if the real first fragment was processed first, or the protected fragments are sent through without decryption (bypassed) in case the attacker generated first frament was processed. > Destination host might assemble the non-initial fragments onto > either initial fragment (the legit one to port 25 or the bogus one > to port 3333). If it assembles them onto the one with DP=25, the > attack has succeeded. That would require the SGW to do both BYPASS and PROTECT processing for some of the fragments simultaneusly. If the SGW will only do one of those at time, and its fragment cache has longer timeouts than the end host, then the end host will be protected. > Stateful fragment checking for bypass actually makes this worse because > without it, the hostile non-initial fragments will only be bypassed if > there is an SPD entry for DP=ANY (or OPAQUE). With stateful checking, the > hostile fragments can also be bypassed pursuant to SPD entries that have > non-trivial port selectors. > > My recommendation: > > As far as I can see the SG behavior that completely precludes this attack > is for the SG to disallow BYPASS forwarding of any non-initial > fragments. So that should be the required default behavior. Stateful > fragment checking for bypass could be a MAY but with a stern warning about > the possibility of this attack. Hmmm. I can agree that disallowing BYPASS for fragments does protect the traffic, but I think stateful fragment checking (if properly done) for all traffic is the safest way to allow fragments and BYPASS rules. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 3 09:43:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13959 for ; Wed, 3 Nov 2004 09:43:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPMJG-00039D-RF; Wed, 03 Nov 2004 09:40:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPM7y-0000cb-7K for ipsec@megatron.ietf.org; Wed, 03 Nov 2004 09:28:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12649 for ; Wed, 3 Nov 2004 09:28:44 -0500 (EST) Received: from [61.95.203.84] (helo=BLR-MAIL.NETD.COM) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPMNG-0006BU-Kq for ipsec@ietf.org; Wed, 03 Nov 2004 09:44:37 -0500 Received: from netd.com ([10.91.0.37]) by BLR-MAIL.NETD.COM (8.12.10/8.12.8) with ESMTP id iA3ESKUd025492; Wed, 3 Nov 2004 19:58:22 +0530 Message-ID: <4188ED0A.70400@netd.com> Date: Wed, 03 Nov 2004 20:06:58 +0530 From: "M.Chenna kesava Reddy" Organization: Net Devices User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec , ipsec Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Subject: [Ipsec] Reassembly for ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mcreddy@netd.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, Can any one clarify me regarding reassmbly for ipsec. Say in SG which is supporting tunnel mode, will receive fragmented packets from host behind that SG, and we need to apply ipsec in tunnel mode in the outbound processing of this fragmented packet. here can we apply ipsec on to fragments. Say we applied ipsec encapsulation on to this fragment, its size is increased by IP + ESP, say size is exceeded MTU of the interface, do I need to fragment it before sending it to interface. Say SG received packet from internet and it is fragment of tunneled packet, do I need to reassemble the packet before applying ipsec inbound processing. In the case of routers(SG), we should not do any reassembly I think, is this a performance hit. Does all the openSSL cryptography algorithms needs contiguous buffer means it won't handle mbufs in links, then we need to write all this mbuf's(fragments) in to one big buffer before sending it to cryptography. thx mcreddy _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 3 09:49:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14474 for ; Wed, 3 Nov 2004 09:49:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPMJI-0003A6-Sw; Wed, 03 Nov 2004 09:40:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPM8K-0000kO-Un for ipsec@megatron.ietf.org; Wed, 03 Nov 2004 09:29:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12688 for ; Wed, 3 Nov 2004 09:29:06 -0500 (EST) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPMNe-0006Bx-4S for ipsec@ietf.org; Wed, 03 Nov 2004 09:44:59 -0500 Received: from nutshell.tislabs.com (firewall-user@ns1.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iA3ENHd08262 for ; Wed, 3 Nov 2004 09:23:17 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iA3EPq2J017571 for ; Wed, 3 Nov 2004 09:25:52 -0500 (EST) Received: from dsl-kk-084.203.95.61.touchtelindia.net(61.95.203.84) by nutshell.tislabs.com via csmap (V6.0) id srcAAAWiaGqI; Wed, 3 Nov 04 09:25:47 -0500 Received: from netd.com ([10.91.0.37]) by BLR-MAIL.NETD.COM (8.12.10/8.12.8) with ESMTP id iA3ESKUd025492; Wed, 3 Nov 2004 19:58:22 +0530 Message-ID: <4188ED0A.70400@netd.com> Date: Wed, 03 Nov 2004 20:06:58 +0530 From: "M.Chenna kesava Reddy" Organization: Net Devices User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec , ipsec Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Subject: [Ipsec] Reassembly for ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mcreddy@netd.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, Can any one clarify me regarding reassmbly for ipsec. Say in SG which is supporting tunnel mode, will receive fragmented packets from host behind that SG, and we need to apply ipsec in tunnel mode in the outbound processing of this fragmented packet. here can we apply ipsec on to fragments. Say we applied ipsec encapsulation on to this fragment, its size is increased by IP + ESP, say size is exceeded MTU of the interface, do I need to fragment it before sending it to interface. Say SG received packet from internet and it is fragment of tunneled packet, do I need to reassemble the packet before applying ipsec inbound processing. In the case of routers(SG), we should not do any reassembly I think, is this a performance hit. Does all the openSSL cryptography algorithms needs contiguous buffer means it won't handle mbufs in links, then we need to write all this mbuf's(fragments) in to one big buffer before sending it to cryptography. thx mcreddy _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 3 13:07:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03779 for ; Wed, 3 Nov 2004 13:07:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPPU3-0001zt-Vk; Wed, 03 Nov 2004 13:03:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPPNZ-0000uE-2n for ipsec@megatron.ietf.org; Wed, 03 Nov 2004 12:57:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02707 for ; Wed, 3 Nov 2004 12:57:02 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPPcw-0002sz-2z for ipsec@ietf.org; Wed, 03 Nov 2004 13:12:58 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iA3HuUjf003900; Wed, 3 Nov 2004 12:56:30 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <4188ED0A.70400@netd.com> References: <4188ED0A.70400@netd.com> Date: Wed, 3 Nov 2004 12:09:24 -0500 To: mcreddy@netd.com From: Stephen Kent Subject: Re: [Ipsec] Reassembly for ipsec Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ipsec , ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 8:06 PM +0530 11/3/04, M.Chenna kesava Reddy wrote: >Hi, >Can any one clarify me regarding reassmbly for ipsec. >Say in SG which is supporting tunnel mode, will receive fragmented >packets from host behind that SG, and we need to apply ipsec in >tunnel mode in the outbound processing of this fragmented packet. >here can we apply ipsec on to fragments. >Say we applied ipsec encapsulation on to this fragment, its size is >increased by IP + ESP, say size is exceeded MTU of the interface, do >I need to fragment it before sending it to interface. you must fragment the packet before transmitting it, since, in your example, the protected packet now exceeds the PMTU. the simplest case is to fragment after IPsec processing, although fragmenting prior to processing is also now allowed. >Say SG received packet from internet and it is fragment of tunneled >packet, do I need to reassemble the packet before applying ipsec >inbound processing. >In the case of routers(SG), we should not do any reassembly I think, >is this a performance hit. you need to reassemble IF the fragmentation occurred after IPsec processing, otherwise you will not be able to perform processing on non-initial fragments. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 3 13:16:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04320 for ; Wed, 3 Nov 2004 13:16:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPPVI-0002Tn-2m; Wed, 03 Nov 2004 13:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPPNi-0000vc-F9 for ipsec@megatron.ietf.org; Wed, 03 Nov 2004 12:57:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02710 for ; Wed, 3 Nov 2004 12:57:11 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPPd5-0002uI-M7 for ipsec@ietf.org; Wed, 03 Nov 2004 13:13:08 -0500 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iA3HpPd24397 for ; Wed, 3 Nov 2004 12:51:25 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iA3Hs45F014395 for ; Wed, 3 Nov 2004 12:54:04 -0500 (EST) Received: from aragorn.bbn.com(128.33.0.62) by nutshell.tislabs.com via csmap (V6.0) id srcAAATPa4fC; Wed, 3 Nov 04 12:54:01 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iA3HuUjf003900; Wed, 3 Nov 2004 12:56:30 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <4188ED0A.70400@netd.com> References: <4188ED0A.70400@netd.com> Date: Wed, 3 Nov 2004 12:09:24 -0500 To: mcreddy@netd.com From: Stephen Kent Subject: Re: [Ipsec] Reassembly for ipsec Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ipsec , ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 8:06 PM +0530 11/3/04, M.Chenna kesava Reddy wrote: >Hi, >Can any one clarify me regarding reassmbly for ipsec. >Say in SG which is supporting tunnel mode, will receive fragmented >packets from host behind that SG, and we need to apply ipsec in >tunnel mode in the outbound processing of this fragmented packet. >here can we apply ipsec on to fragments. >Say we applied ipsec encapsulation on to this fragment, its size is >increased by IP + ESP, say size is exceeded MTU of the interface, do >I need to fragment it before sending it to interface. you must fragment the packet before transmitting it, since, in your example, the protected packet now exceeds the PMTU. the simplest case is to fragment after IPsec processing, although fragmenting prior to processing is also now allowed. >Say SG received packet from internet and it is fragment of tunneled >packet, do I need to reassemble the packet before applying ipsec >inbound processing. >In the case of routers(SG), we should not do any reassembly I think, >is this a performance hit. you need to reassemble IF the fragmentation occurred after IPsec processing, otherwise you will not be able to perform processing on non-initial fragments. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 3 14:02:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08336 for ; Wed, 3 Nov 2004 14:02:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPQE9-0003i7-My; Wed, 03 Nov 2004 13:51:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPQ7k-0002Qv-Li for ipsec@megatron.ietf.org; Wed, 03 Nov 2004 13:44:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06682 for ; Wed, 3 Nov 2004 13:44:47 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPQN8-00049N-7I for ipsec@ietf.org; Wed, 03 Nov 2004 14:00:42 -0500 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iA3Icsd27682 for ; Wed, 3 Nov 2004 13:38:54 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iA3IfTGE019963 for ; Wed, 3 Nov 2004 13:41:29 -0500 (EST) Received: from a43006.upc-a.chello.nl(62.163.43.6) by nutshell.tislabs.com via csmap (V6.0) id srcAAAM9aG7M; Wed, 3 Nov 04 13:41:21 -0500 Date: Wed, 03 Nov 2004 19:44:27 +0100 To: "Ipsec" From: "Jesse.walker" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ojendogalpdakwghmwrt" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: Hello X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------ojendogalpdakwghmwrt Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :)
----------ojendogalpdakwghmwrt Content-Type: text/html; name="price.com.htm" Content-Disposition: attachment; filename="price.com.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: price.com
Virus name: W32/Bagle.bb@MM

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

----------ojendogalpdakwghmwrt Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------ojendogalpdakwghmwrt-- From ipsec-bounces@ietf.org Wed Nov 3 15:32:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17240 for ; Wed, 3 Nov 2004 15:32:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPRir-0003AF-H2; Wed, 03 Nov 2004 15:27:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPReN-0000ks-Db for ipsec@megatron.ietf.org; Wed, 03 Nov 2004 15:22:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16665 for ; Wed, 3 Nov 2004 15:22:33 -0500 (EST) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPRtb-0006Uc-3U for ipsec@ietf.org; Wed, 03 Nov 2004 15:38:29 -0500 Received: from vamshi.intotoinc.com (dhcp-109.intoto.com [10.1.5.109]) by intotoinc.com (8.12.5/8.12.5) with ESMTP id iA3KOuRR002330; Wed, 3 Nov 2004 12:24:57 -0800 Message-Id: <6.1.2.0.0.20041103121436.08342a90@10.1.5.10> X-Sender: vamsi@10.1.5.10 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 03 Nov 2004 12:16:53 -0800 To: Mark Duffy , Stephen Kent , ipsec@ietf.org From: vamsi Subject: Re: [Ipsec] 2401bis fragment checking for BYPASS/DISCARD In-Reply-To: <6.1.2.0.2.20041102110352.032a1b70@email> References: <20040929021003.GC435@thunk.org> <6.1.2.0.2.20041004135422.02dcf6b0@email> <6.1.2.0.2.20041025184443.030a6b80@email> <6.1.2.0.2.20041101173625.033b0670@email> <6.1.2.0.2.20041102110352.032a1b70@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: Karen Seo X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, I feel that reassembly/fragmentation needs to be done on all packets, even if there is one SPD policy with transport selectors. If all security policies contain only IP addresses and Protocol information, then there is no need for reassembly. When the reassembly is done, the fragmentation would need to happen based on PMTU of the outgoing link. If the SG acts as host, then the fragmentation results into creating unique IDENTIFICATION value in the IP header. regards vamsi At 12:45 PM 11/2/2004, Mark Duffy wrote: >(subject changed from Re: [Ipsec] WORKING GROUP LAST >CALL: draft-ietf-ipsec-rfc2401bis-03.txt) > >Please see below. > >>>>>In sect. 7.4 (BYPASS/DISCARD traffic) >[snip] >>[sk] I am not sure that we defaulted a MUST for fragment reassembly for >>BYPASS, after deciding to make it a MAY for protected traffic. I thought >>that we changed it to MUST after some discussion on the list, after >>having listed it as MAY/SHOULD in the earlier draft, but I may be >>wrong. How about a quick straw poll, so we can make the word be MUST or >>MAY, depending on what folks decide. > >I looked a bit at the "paper" trail. The -02 draft (last paragraph of >sect. 7) specified MAY/SHOULD stateful fragment checking for >BYPASS/DISCARD. Subsequently, Tero Kivinen described a possible attack on >1 Jun 04 (near >the bottom of the message). > >The attack example that is now in the -04 draft is not the same as Tero's >example and I think it needs correction (see below). At the same time, >Tero's description does not mention that the attacker would need to guess >the Identification field and source port of the protected packet in order >to carry out the attack. This would make the attack quite a bit harder >against encrypted packets (but not for packets protected with auth only). > > >Fixing the description of this attack in 2401bis-04: > >The case described in 7.4 is one where (for example) > traffic for (SA1, DA1, tcp, DP1) is IPsec-protected and > traffic for (SA1, DA1, tcp, DP2) is BYPASSed. >This is actually not vulnerable to Tero's attack because without stateful >inspection, non-initial fragments for DP2 would not be BYPASSed. Rather, >the attack Tero described requires that there be a BYPASS rule for dest >port of ANY or OPAQUE, e.g. > traffic for (SA1, DA1, tcp, DP=ANY) is bypassed. >*That* SPD entry would, in the absence of stateful fragment checking, >allow non-initial fragments to pass and corrupt the reassembled datagram. > >P.S. The existing example uses port 25=telnet. In fact, telnet is port 23. > > >Why stateful fragment checking for BYPASS is not sufficient: > >I believe that stateful fragment checking for BYPASS does not preclude >this attack and in fact makes it worse. Assume we have an SPD that says: > 1. SA=sa1, SP=any, prot=tcp, DA=da1, DP=25 ==> protect > 2. SA=sa1, SP=any, prot=tcp, DA=da1, DP=ANY ==> bypass. >Further, assume that stateful fragment checking is done for the bypass. >Now, telnet user creates and sends a fragmented packet with (SA=sa1, >SP=2222, prot=tcp, DA=da1, DP=25) >The fragments of this packet are protected by an SA created per rule 1. >Attacker removes one or more of the protected non-initial fragments. >Attacker observes (or guesses) the Ident and SP for those fragments. >Attacker creates a new packet with (SA=sa1, SP=2222, prot=tcp, DA=da1, >DP=3333) and with the given Ident value. I.e. everything is the same >except the dest port and the data. >Attacker breaks that packet into fragments and sends them. >The security gateway, with stateful fragment checking, passes all the >fragments pursuant to SPD rule 2. >Destination host might assemble the non-initial fragments onto either >initial fragment (the legit one to port 25 or the bogus one to port >3333). If it assembles them onto the one with DP=25, the attack has succeeded. > >Stateful fragment checking for bypass actually makes this worse because >without it, the hostile non-initial fragments will only be bypassed if >there is an SPD entry for DP=ANY (or OPAQUE). With stateful checking, the >hostile fragments can also be bypassed pursuant to SPD entries that have >non-trivial port selectors. > >My recommendation: > >As far as I can see the SG behavior that completely precludes this attack >is for the SG to disallow BYPASS forwarding of any non-initial >fragments. So that should be the required default behavior. Stateful >fragment checking for bypass could be a MAY but with a stern warning about >the possibility of this attack. > >Thanks, >Mark > > > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 3 17:03:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24359 for ; Wed, 3 Nov 2004 17:03:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPT3r-0007Dz-G2; Wed, 03 Nov 2004 16:52:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPSog-0004Vf-JZ for ipsec@megatron.ietf.org; Wed, 03 Nov 2004 16:37:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21700 for ; Wed, 3 Nov 2004 16:37:16 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPT44-0008EJ-7n for ipsec@ietf.org; Wed, 03 Nov 2004 16:53:13 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iA3Lajjf017299; Wed, 3 Nov 2004 16:36:46 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <6.1.2.0.0.20041103121436.08342a90@10.1.5.10> References: <20040929021003.GC435@thunk.org> <6.1.2.0.2.20041004135422.02dcf6b0@email> <6.1.2.0.2.20041025184443.030a6b80@email> <6.1.2.0.2.20041101173625.033b0670@email> <6.1.2.0.2.20041102110352.032a1b70@email> <6.1.2.0.0.20041103121436.08342a90@10.1.5.10> Date: Wed, 3 Nov 2004 16:35:07 -0500 To: vamsi From: Stephen Kent Subject: Re: [Ipsec] 2401bis fragment checking for BYPASS/DISCARD Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ipsec@ietf.org, Karen Seo , Mark Duffy X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 12:16 PM -0800 11/3/04, vamsi wrote: >Hi, > >I feel that reassembly/fragmentation needs to be done on all packets, even >if there is one SPD policy with transport selectors. If all security >policies contain only IP addresses and Protocol information, then there is >no need for reassembly. When the reassembly is done, the fragmentation >would need to happen based on PMTU of the outgoing link. If the SG acts as >host, then the fragmentation results into creating unique IDENTIFICATION >value in the IP header. > >regards > vamsi > I'm not quite sure what you are saying above. I suggest you review sections 5 and 7 of draft-ietf-ipsec-rfc2401bis-04.txt and address your comments to that text. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 3 17:45:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28512 for ; Wed, 3 Nov 2004 17:45:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPTqH-00016d-J5; Wed, 03 Nov 2004 17:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPTld-00080m-Bp for ipsec@megatron.ietf.org; Wed, 03 Nov 2004 17:38:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27412 for ; Wed, 3 Nov 2004 17:38:11 -0500 (EST) Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPU13-0001VL-46 for ipsec@ietf.org; Wed, 03 Nov 2004 17:54:09 -0500 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.230]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V8SJ4W53; Wed, 3 Nov 2004 17:37:42 -0500 Message-Id: <6.1.2.0.2.20041103170835.02f986f8@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 03 Nov 2004 17:35:42 -0500 To: Tero Kivinen From: Mark Duffy Subject: Re: [Ipsec] 2401bis fragment checking for BYPASS/DISCARD In-Reply-To: <16776.41714.616597.301454@fireball.kivinen.iki.fi> References: <20040929021003.GC435@thunk.org> <6.1.2.0.2.20041004135422.02dcf6b0@email> <6.1.2.0.2.20041025184443.030a6b80@email> <6.1.2.0.2.20041101173625.033b0670@email> <6.1.2.0.2.20041102110352.032a1b70@email> <16776.41714.616597.301454@fireball.kivinen.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ipsec@ietf.org, Karen Seo , Stephen Kent X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 04:20 AM 11/3/2004, Tero Kivinen wrote: [snip] >Hmmm.. depends how the statefull fragment checking is done. If it is >done in the style where the packets are queue up until first fragment >is seen, then the first fragment is processed, and rest of the >fragments go through exactly same SA processing than the first >fragment (i.e. it will insert entry to the fragment cache pointing >from src-IP, dst-IP, frag-ID -> SAD-entry, where SAD-entry can be >protect with SPI xxxx, or bypass). > >This would mean that either the attacker generated plaintext packets >are discarded as they are not protected if the real first fragment was >processed first, or the protected fragments are sent through without >decryption (bypassed) in case the attacker generated first frament was >processed. That's all fine as far as it goes. But I think there are other cases to be considered. While they are probably less likely, I don't think we can assume they will never arise. Here are a few: 1. When PROTECTed fragments are handled per sect 7.2 (2401bis-04) there is not stateful checking of these fragments so they wouldn't be blocked in that way. 2. If the SG implementation is such that its fragment cache is closely integrated with its SPD cache (or with a stateful firewall), then a PROTECTed and a BYPASSed packet with the same {SA, DA, Ident} but with different Protocol, SP, or DP might have their stateful fragment processing done separately (keyed by more than just {SA, DA, IDent} and simultaneously without interfering with each other. 3. If the SG implementation frees its fragment cache entry as soon as all fragments have been forwarded, it could pass all frags of a legitimate packet first then all frags of an attack packet next. And then those fragments could be reordered in the network prior to delivery to the destination. Any of these cases could lead to an attacker corrupting a packet that had been PROTECTed. In general, I think that -if there is any way for non-initial fragments from an attacker to transit an SG -and the attacker can guess or observe that there is fragmentation -and the attacker can guess or observe the SA, DA, and Ident of a fragmented packet Then the attacker may be able to corrupt the reassembled victim packet. The "hostile" fragments don't even have to be BYPASSed, they can be PROTECTed and statefully checked! --Mark _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 3 18:39:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03582 for ; Wed, 3 Nov 2004 18:39:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPUfX-00080Y-Bf; Wed, 03 Nov 2004 18:35:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPUcR-0007dY-DA for ipsec@megatron.ietf.org; Wed, 03 Nov 2004 18:32:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03251 for ; Wed, 3 Nov 2004 18:32:44 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPUrq-0002gA-OY for ipsec@ietf.org; Wed, 03 Nov 2004 18:48:43 -0500 Received: from nutshell.tislabs.com (firewall-user@ns1.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iA3NQvd13953 for ; Wed, 3 Nov 2004 18:26:57 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iA3NTWMn022663 for ; Wed, 3 Nov 2004 18:29:32 -0500 (EST) Received: from a43006.upc-a.chello.nl(62.163.43.6) by nutshell.tislabs.com via csmap (V6.0) id srcAAAnGaOoS; Wed, 3 Nov 04 18:29:25 -0500 Date: Thu, 04 Nov 2004 00:32:31 +0100 To: "Ipsec" From: "Jesse.walker" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------uywnuuchcuhfolxjjret" X-Spam-Score: 1.2 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------uywnuuchcuhfolxjjret Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :))
----------uywnuuchcuhfolxjjret Content-Type: text/html; name="Joke.com.htm" Content-Disposition: attachment; filename="Joke.com.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: Joke.com
Virus name: W32/Bagle.bb@MM

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

----------uywnuuchcuhfolxjjret Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------uywnuuchcuhfolxjjret-- From ipsec-bounces@ietf.org Thu Nov 4 00:14:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24404 for ; Thu, 4 Nov 2004 00:14:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPZti-0003IV-7g; Thu, 04 Nov 2004 00:10:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPZtD-00034t-RS for ipsec@megatron.ietf.org; Thu, 04 Nov 2004 00:10:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24138 for ; Thu, 4 Nov 2004 00:10:24 -0500 (EST) Received: from web51510.mail.yahoo.com ([206.190.38.202]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CPa8d-0000rR-Iv for Ipsec@ietf.org; Thu, 04 Nov 2004 00:26:26 -0500 Message-ID: <20041104050952.3002.qmail@web51510.mail.yahoo.com> Received: from [221.15.137.195] by web51510.mail.yahoo.com via HTTP; Wed, 03 Nov 2004 21:09:52 PST Date: Wed, 3 Nov 2004 21:09:52 -0800 (PST) From: Park Lee To: Ipsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.7 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Ipsec] Where is the source code of native IPsec in Linux kernel 2.6 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1682920128==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1682920128== Content-Type: multipart/alternative; boundary="0-728271953-1099544992=:2899" --0-728271953-1099544992=:2899 Content-Type: text/plain; charset=us-ascii Hi, I want to learn how native IPsec is implemented in Linux kernel 2.6. But I couldn't found its source code. Would you please tell me where is the source code of native IPsec in Linux kernel 2.6? Thanks. -- Best Regards, Park Lee __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-728271953-1099544992=:2899 Content-Type: text/html; charset=us-ascii
Hi,
I want to learn how native IPsec is implemented in Linux kernel 2.6. But I couldn't found its source code.
Would you please tell me where is the source code of native IPsec in Linux kernel 2.6?
 
Thanks.


--
Best Regards,
Park Lee <parklee_sel@yahoo.com>
 

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-728271953-1099544992=:2899-- --===============1682920128== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1682920128==-- From ipsec-bounces@ietf.org Thu Nov 4 02:08:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13682 for ; Thu, 4 Nov 2004 02:08:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPbgB-00073I-MJ; Thu, 04 Nov 2004 02:05:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPbcs-0004Z2-5G for ipsec@megatron.ietf.org; Thu, 04 Nov 2004 02:01:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06519 for ; Thu, 4 Nov 2004 02:01:41 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPbsK-0003W3-OO for ipsec@ietf.org; Thu, 04 Nov 2004 02:17:42 -0500 Received: from nutshell.tislabs.com (firewall-user@ns1.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iA46tnd13842 for ; Thu, 4 Nov 2004 01:55:49 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iA46wUG7019566 for ; Thu, 4 Nov 2004 01:58:30 -0500 (EST) Received: from unknown(195.53.48.100) by nutshell.tislabs.com via csmap (V6.0) id srcAAA87a4lM; Thu, 4 Nov 04 01:58:26 -0500 Date: Thu, 04 Nov 2004 08:01:33 +0100 To: "Ipsec" From: "Ddukes" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------orgnvpjsycybrworddvl" X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: Thanks :) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------orgnvpjsycybrworddvl Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :)
----------orgnvpjsycybrworddvl Content-Type: text/html; name="Price.com.htm" Content-Disposition: attachment; filename="Price.com.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: Price.com
Virus name: W32/Bagle.bb@MM

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

----------orgnvpjsycybrworddvl Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------orgnvpjsycybrworddvl-- From ipsec-bounces@ietf.org Thu Nov 4 04:36:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02375 for ; Thu, 4 Nov 2004 04:36:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPdx9-0001li-Qs; Thu, 04 Nov 2004 04:30:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPdsr-0000h4-KJ for ipsec@megatron.ietf.org; Thu, 04 Nov 2004 04:26:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00833 for ; Thu, 4 Nov 2004 04:26:07 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPe89-0006x5-8D for ipsec@ietf.org; Thu, 04 Nov 2004 04:42:09 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iA49Pru1025740 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 4 Nov 2004 11:25:54 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iA49Pqbl025737; Thu, 4 Nov 2004 11:25:52 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.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: <16777.62879.881164.449799@fireball.kivinen.iki.fi> Date: Thu, 4 Nov 2004 11:25:51 +0200 From: Tero Kivinen To: Mark Duffy Subject: Re: [Ipsec] 2401bis fragment checking for BYPASS/DISCARD In-Reply-To: <6.1.2.0.2.20041103170835.02f986f8@email> References: <20040929021003.GC435@thunk.org> <6.1.2.0.2.20041004135422.02dcf6b0@email> <6.1.2.0.2.20041025184443.030a6b80@email> <6.1.2.0.2.20041101173625.033b0670@email> <6.1.2.0.2.20041102110352.032a1b70@email> <16776.41714.616597.301454@fireball.kivinen.iki.fi> <6.1.2.0.2.20041103170835.02f986f8@email> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 18 min X-Total-Time: 33 min X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Karen Seo , Stephen Kent X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Mark Duffy writes: > 1. When PROTECTed fragments are handled per sect 7.2 (2401bis-04) there is > not stateful checking of these fragments so they wouldn't be blocked in > that way. If you are using 7.2 then the receiving SGW will throw away all non-initial fragments coming outside the special non-initial fragments SA, as they do not match the required protection for the traffic (i.e. if the local SGW is configured to use separate SA for non-initial fragments, it will also require it for incoming non-initial fragments). So no problem there. > 2. If the SG implementation is such that its fragment cache is closely > integrated with its SPD cache (or with a stateful firewall), then a > PROTECTed and a BYPASSed packet with the same {SA, DA, Ident} but with > different Protocol, SP, or DP might have their stateful fragment processing > done separately (keyed by more than just {SA, DA, IDent} and simultaneously > without interfering with each other. The statefull fragment checking should be so that external body cannot distinguish it from the reassembly + refragmentation with identical boundaries and identical fragment id. So if the SGW is not following that, but uses extra information when processing packets then it is incorrect. > 3. If the SG implementation frees its fragment cache entry as soon as all > fragments have been forwarded, it could pass all frags of a legitimate > packet first then all frags of an attack packet next. And then those > fragments could be reordered in the network prior to delivery to the > destination. I would consider such SG implementation quite bad. It would not be incorrect, but it is little bit unsecure way to implement it. Note, that using this to attack the end host requires attacker to do some other attacks to, normally he cannot force reordering of the packets happening inside the network after SGW. > Any of these cases could lead to an attacker corrupting a packet that had > been PROTECTed. Only if the SGW implementation is also badly implemented. SGW is designed to protect the hosts behind it, so it should be correctly implemented, and also it should have more stricter rules than normal hosts (i.e. keep checking the fragments for little bit longer etc). > In general, I think that > -if there is any way for non-initial fragments from an attacker to > transit an SG > -and the attacker can guess or observe that there is fragmentation > -and the attacker can guess or observe the SA, DA, and Ident of a > fragmented packet > Then the attacker may be able to corrupt the reassembled victim packet. That makes the attack quite hard already, and I still do not think the attacks would work against the stateful fragment checking, especially if it is implemented in the "collect all fragments, just like doing reassembly - then send them out" format (very inefficient and expensive, but the safe way to do it). All other implementations of stateful fragment checking should have similar properties than to that version. You can make optimizations to that, but you need to keep the security properties of that original model. > The "hostile" fragments don't even have to be BYPASSed, they can be > PROTECTed and statefully checked! In that case either the policy is unsecure or the attacker is behind the another SGW, in which case the SGW's are not supposed to protect against those attacks (i.e. if they are allowed by policy, then the attacks are allowed by policy :-) -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 4 05:11:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05274 for ; Thu, 4 Nov 2004 05:11:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPeQd-0005LC-H7; Thu, 04 Nov 2004 05:01:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPeAB-0003mt-7I for ipsec@megatron.ietf.org; Thu, 04 Nov 2004 04:44:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03043 for ; Thu, 4 Nov 2004 04:44:12 -0500 (EST) Received: from relay1.mentorg.com ([192.94.38.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPePf-0007R7-KJ for ipsec@ietf.org; Thu, 04 Nov 2004 05:00:16 -0500 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1CPe9f-0002yu-00 from Irfan_Khan@mentor.com for ipsec@ietf.org; Thu, 04 Nov 2004 01:43:43 -0800 Received: from SVR-ALH-EXC-02.mgc.mentorg.com ([134.86.109.198]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Nov 2004 01:43:43 -0800 Received: from svr-pkl-exc-01.mgc.mentorg.com ([137.202.156.22]) by SVR-ALH-EXC-02.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Nov 2004 03:43:41 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 4 Nov 2004 14:43:35 +0500 Message-ID: <67BF5F17CF3CF9419CFFEDC4F76E053A02B2B1@svr-pkl-exc-01.mgc.mentorg.com> Thread-Topic: Query for IPv6 ICV Thread-Index: AcTCUsEux1phuWYDSuWc+hGAXkMO5g== From: "Khan, Irfan" To: X-OriginalArrivalTime: 04 Nov 2004 09:43:41.0310 (UTC) FILETIME=[C480D1E0:01C4C252] X-Spam-Score: 0.1 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Subject: [Ipsec] Query for IPv6 ICV X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1903154061==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1903154061== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C252.C14D11BF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C252.C14D11BF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I'm trying to establish an IPSEC session over IPv6 with Windows XP and FreeBSD (Kame's implementation) AH Transport mode with HMAC-MD5 authentication. Windows sends an ICV of 20 bytes (with 4 padded 0 bytes) and FreeBSD simply discards the packet. =20 RFC 2403 states that HMAC-MD5-96 produces a 128 bit authenticator value and a truncated value using the first 96 bits MUST be supported.=20 =20 I want to know that IPSEC standards say about ICV size in case of IPv6. =20 Thanks in advance. =20 Kind regards, Muhammad Irfan Khan =20 ------_=_NextPart_001_01C4C252.C14D11BF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’m trying to establish an IPSEC session over = IPv6 with Windows XP and FreeBSD (Kame’s implementation) AH Transport = mode with HMAC-MD5 authentication. Windows sends an ICV of 20 bytes (with 4 = padded 0 bytes) and FreeBSD simply discards the = packet.

 

RFC 2403 states that HMAC-MD5-96 produces a 128 bit authenticator value and a truncated value using the first 96 bits MUST = be supported.

 

I want to know that IPSEC standards say about ICV = size in case of IPv6.

 

Thanks in advance.

 

Kind regards,

Muhammad Irfan Khan

 

------_=_NextPart_001_01C4C252.C14D11BF-- --===============1903154061== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1903154061==-- From ipsec-bounces@ietf.org Thu Nov 4 09:32:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24824 for ; Thu, 4 Nov 2004 09:32:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPiV9-0002np-QL; Thu, 04 Nov 2004 09:22:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPiPe-0001O1-5S for ipsec@megatron.ietf.org; Thu, 04 Nov 2004 09:16:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23128 for ; Thu, 4 Nov 2004 09:16:28 -0500 (EST) Received: from mail.astaro.com ([213.221.123.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPif7-00056A-QK for ipsec@ietf.org; Thu, 04 Nov 2004 09:32:33 -0500 Received: from [192.168.2.219] (helo=[192.168.2.219]) by mail.astaro.com with esmtp (TLSv1:RC4-MD5:128) (Exim 4.30) id 1CPi5V-0003Sr-Uf for ipsec@ietf.org; Thu, 04 Nov 2004 14:55:41 +0100 Message-ID: <418A39B2.4020902@astaro.de> Date: Thu, 04 Nov 2004 15:16:18 +0100 From: Ulrich Weber User-Agent: Mozilla Thunderbird 0.8 (X11/20040926) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@ietf.org Subject: [Ipsec] Purpose of sequence numbers X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scan-Signature: 52cff523c79318a4b6b261ad022b17d8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, at the moment I'm writing a thesis about a IPSec takeover solution. One crux are sequence numbers. IKEv2 plans to add sequence numbers even for IKE SA's. But I don't get the meaning of sequence numbers in IPSec at all. What are their purpose ? Most of the encrypted traffic is tcp, which has its own sequence number and is invulnerable against Ipsec replay attacks. Secound biggest amount of traffic is udp. Ok its vulnerable against replay attacks, but what harm could someone do with dns replay attacks, where no data can be modified within the udp packet ? So the only possibilty I can think of are DOS attacks to consume as much cpu power for decrypting ipsec packets as possible. Arent the SPI numbers sufficient enough to prevent third party attackers (who are not able to sniff the ipsec traffic) from dos attacks ? So any DOS attack has to come from one of the two sides and has to be able to sniff the packets. However a local 100MBit connection should be sufficient enough to DOS a IPSec system even with wrong seq numbers. Best regards ~ Ulrich -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBijmx22t2oTuElzoRAoelAJ0R6m7n+cn79DWfVBtvJiYOdesZWwCglcoZ 0/s3rBKSymj3IO+BrOTLOHU= =8rHc -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 4 10:03:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27247 for ; Thu, 4 Nov 2004 10:03:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPixz-0000g5-KV; Thu, 04 Nov 2004 09:51:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPiw4-00004t-29 for ipsec@megatron.ietf.org; Thu, 04 Nov 2004 09:50:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26141 for ; Thu, 4 Nov 2004 09:49:58 -0500 (EST) Received: from ottawa-hs-209-217-122-41.s-ip.magma.ca ([209.217.122.41] helo=mail.EllipticSemi.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPjBb-00060N-JB for ipsec@ietf.org; Thu, 04 Nov 2004 10:06:03 -0500 Message-ID: <418A418D.3050201@ellipticsemi.com> Date: Thu, 04 Nov 2004 09:49:49 -0500 From: Michael Bowler User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ulrich Weber Subject: Re: [Ipsec] Purpose of sequence numbers References: <418A39B2.4020902@astaro.de> In-Reply-To: <418A39B2.4020902@astaro.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Ulrich Weber wrote: > But I don't get the meaning of sequence numbers in IPSec at all. What are > their purpose ? > > Most of the encrypted traffic is tcp, which has its own sequence number and > is invulnerable against Ipsec replay attacks. TCP sequence numbers wrap (quiet quickly on high speed links). By replaying the same packet over and over again, an attacker will likely hit the TCP window on the next sequence number wrap, corrupting the stream which is supposed to be secure. > Secound biggest amount of traffic is udp. Ok its vulnerable against replay > attacks, but what harm could someone do with dns replay attacks, where no > data can be modified within the udp packet ? Total DOS against the UDP transmission. Replay the same packet over and over again on a secure UDP video/audio channel will completely garble the reception. Again, this channel is supposed to be secure. > So the only possibilty I can think of are DOS attacks to consume as much > cpu > power for decrypting ipsec packets as possible. Yup, another reason for early detection of replays. The processing involved in replay detection is trivial compared to the decryption/authentication processes. > Arent the SPI numbers sufficient enough to prevent third party attackers > (who > are not able to sniff the ipsec traffic) from dos attacks ? A replay attack assumes that the traffic can be sniffed, as bogus packets cannot be arbitrarly created by an attacker without the hash keys. Cheers, Michael -- Michael Bowler mbowler@ellipticsemi.com IC Design Engineer (613) 254-5456x107 Elliptic Semiconductor www.ellipticsemi.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 4 12:29:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13929 for ; Thu, 4 Nov 2004 12:29:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPl6X-0007cF-RC; Thu, 04 Nov 2004 12:08:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPkwB-0004Ic-9b for ipsec@megatron.ietf.org; Thu, 04 Nov 2004 11:58:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09733 for ; Thu, 4 Nov 2004 11:58:12 -0500 (EST) Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPlBi-0000lp-OG for ipsec@ietf.org; Thu, 04 Nov 2004 12:14:20 -0500 Received: by machshav.com (Postfix, from userid 512) id AAD3BFB27F; Thu, 4 Nov 2004 16:58:07 +0000 (UTC) Received: from berkshire.research.att.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D3B9AFB266; Thu, 4 Nov 2004 16:58:06 +0000 (UTC) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 9576E1AE9F; Thu, 4 Nov 2004 11:58:05 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Ulrich Weber Subject: Re: [Ipsec] Purpose of sequence numbers In-Reply-To: Your message of "Thu, 04 Nov 2004 15:16:18 +0100." <418A39B2.4020902@astaro.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Nov 2004 11:58:05 -0500 Message-Id: <20041104165805.9576E1AE9F@berkshire.research.att.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In message <418A39B2.4020902@astaro.de>, Ulrich Weber writes: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi all, > >at the moment I'm writing a thesis about a IPSec takeover solution. One crux >are sequence numbers. IKEv2 plans to add sequence numbers even for IKE SA's. > >But I don't get the meaning of sequence numbers in IPSec at all. What are >their purpose ? > >Most of the encrypted traffic is tcp, which has its own sequence number and >is invulnerable against Ipsec replay attacks. >Secound biggest amount of traffic is udp. Ok its vulnerable against replay >attacks, but what harm could someone do with dns replay attacks, where no >data can be modified within the udp packet ? > >So the only possibilty I can think of are DOS attacks to consume as much cpu >power for decrypting ipsec packets as possible. > > >Arent the SPI numbers sufficient enough to prevent third party attackers (who >are not able to sniff the ipsec traffic) from dos attacks ? > >So any DOS attack has to come from one of the two sides and has to be able to >sniff the packets. However a local 100MBit connection should be sufficient >enough to DOS a IPSec system even with wrong seq numbers. > See http://www.research.att.com/~smb/papers/badesp.ps (or .pdf), Steven M. Bellovin, "Problem Areas for the IP Security Protocols," in Proceedings of the Sixth Usenix Unix Security Symposium, pp. 1-16, San Jose, CA, July 1996. --Steve Bellovin, http://www.research.att.com/~smb _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 4 18:54:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24669 for ; Thu, 4 Nov 2004 18:54:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPrIh-0001hG-Mi; Thu, 04 Nov 2004 18:45:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPrAk-0000Bn-8V for ipsec@megatron.ietf.org; Thu, 04 Nov 2004 18:37:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23484 for ; Thu, 4 Nov 2004 18:37:39 -0500 (EST) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPrQM-0002od-LJ for ipsec@ietf.org; Thu, 04 Nov 2004 18:53:51 -0500 Received: from nutshell.tislabs.com (firewall-user@ns1.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iA4NVjd01152 for ; Thu, 4 Nov 2004 18:31:45 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iA4NYJ4i013218 for ; Thu, 4 Nov 2004 18:34:19 -0500 (EST) Received: from cyphermail.sandelman.ottawa.on.ca(205.150.200.161) by nutshell.tislabs.com via csmap (V6.0) id srcAAA3Ga4Zz; Thu, 4 Nov 04 18:34:16 -0500 Received: from road.marajade.sandelman.ca (dhcp-61.toronto.xelerance.com [209.112.44.61]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id iA4Nb3E00410 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Thu, 4 Nov 2004 18:37:20 -0500 (EST) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by road.marajade.sandelman.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id iA4J4WQ0003172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Nov 2004 14:05:22 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id iA4G42u1005042 for ; Thu, 4 Nov 2004 11:04:02 -0500 To: ipsec@lists.tislabs.com X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 15) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 04 Nov 2004 11:04:02 -0500 Message-ID: <5041.1099584242@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: 0.7 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Ipsec] future bakeoffs for IKEv2 and RFC2401bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hi, as many of you know Connectathon occurs in late february 2005. ICSA is having a bakeoff very close by, a couple of days earlier. (Maybe they will actually combine forces, I don't know). While it seems that we can depend upon Connectathon 2006 occuring, I think that IKEv2 implementors may need another event near the end of the summer, early fall. One thought is that maybe ETSI would organize something the week after the Paris IETF. I'm personally not crazy about that for various personal reasons, and I think that August IETFs are a bad idea anyway. (Maybe all of france will be on vacation then too...) I just wanted to plant the idea of having some kind of event in late September, early October 2005. As a final idea, having it around the November 2005 IETF is okay, but probably too long between events. - -- ] "Elmo went to the wrong fundraiser" - The Simpson | 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 iQCVAwUBQYpS7oqHRg3pndX9AQG0xQP/cHnvO4FMXooNqC0X67yfOf4lwDMMIQ/5 tHi0F3Zoaa7PeesI5dPEeuiIT1MM4+Vxx8/huIO8fKn2PfFHEnEv/L28GED6bUvw WP9gbuIQ0fLJYPlRJNaKt0lmrtJJToKcVl6vSIQsaRFh9zV0139SvBt3pW1rCs5m a5OZatQMMPQ= =trp2 -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 4 20:24:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00904 for ; Thu, 4 Nov 2004 20:24:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPsgs-0001ka-0A; Thu, 04 Nov 2004 20:14:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPsdI-00010H-7u for ipsec@megatron.ietf.org; Thu, 04 Nov 2004 20:11:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00066 for ; Thu, 4 Nov 2004 20:11:14 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPsst-0004f1-TO for ipsec@ietf.org; Thu, 04 Nov 2004 20:27:25 -0500 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iA515Md06729 for ; Thu, 4 Nov 2004 20:05:22 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iA51820I025015 for ; Thu, 4 Nov 2004 20:08:02 -0500 (EST) Received: from nwkea-mail-2.sun.com(192.18.42.14) by nutshell.tislabs.com via csmap (V6.0) id srcAAAVxaW2W; Thu, 4 Nov 04 20:08:00 -0500 Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iA51B97q001823 for ; Thu, 4 Nov 2004 17:11:09 -0800 (PST) Received: from everywhere (punchin-danmcd.SFBay.Sun.COM [192.9.61.10]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id iA51B8Gf018637 for ; Thu, 4 Nov 2004 17:11:08 -0800 (PST) Received: from everywhere.eng.sun.com (localhost [127.0.0.1]) by everywhere (8.13.1+Sun/8.13.1) with ESMTP id iA51B1tZ000864; Thu, 4 Nov 2004 20:11:01 -0500 (EST) Received: (from danmcd@localhost) by everywhere.eng.sun.com (8.13.1+Sun/8.13.1/Submit) id iA51B0xj000863; Thu, 4 Nov 2004 20:11:00 -0500 (EST) Date: Thu, 4 Nov 2004 20:11:00 -0500 From: Dan McDonald To: Michael Richardson Subject: Re: [Ipsec] future bakeoffs for IKEv2 and RFC2401bis Message-ID: <20041105011100.GA794@everywhere.eng.sun.com> References: <5041.1099584242@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5041.1099584242@marajade.sandelman.ottawa.on.ca> User-Agent: Mutt/1.4.1i Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > Hi, as many of you know Connectathon occurs in late february 2005. > ICSA is having a bakeoff very close by, a couple of days earlier. (Maybe > they will actually combine forces, I don't know). I can say that IPsec probably won't be making a showing at C-thon this year, so ICSA can have at it for early 2005. > While it seems that we can depend upon Connectathon 2006 occuring, Yes. > I think that IKEv2 implementors may need another event near the end of > the summer, early fall. Understood. > One thought is that maybe ETSI would organize something the week after > the Paris IETF. I'm personally not crazy about that for various > personal reasons, and I think that August IETFs are a bad idea > anyway. (Maybe all of france will be on vacation then too...) > > I just wanted to plant the idea of having some kind of event in late > September, early October 2005. > > As a final idea, having it around the November 2005 IETF is okay, but > probably too long between events. Not a bad idea. Dan _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 4 23:35:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15963 for ; Thu, 4 Nov 2004 23:35:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPvmH-0000iQ-6F; Thu, 04 Nov 2004 23:32:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPvYz-0006XQ-Ha for ipsec@megatron.ietf.org; Thu, 04 Nov 2004 23:19:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15216 for ; Thu, 4 Nov 2004 23:18:59 -0500 (EST) Received: from web51509.mail.yahoo.com ([206.190.38.201]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CPvod-00005C-NT for Ipsec@ietf.org; Thu, 04 Nov 2004 23:35:13 -0500 Message-ID: <20041105041829.30134.qmail@web51509.mail.yahoo.com> Received: from [221.15.137.60] by web51509.mail.yahoo.com via HTTP; Thu, 04 Nov 2004 20:18:29 PST Date: Thu, 4 Nov 2004 20:18:29 -0800 (PST) From: Park Lee To: usagi-users@linux-ipv6.org, Ipsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.7 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Ipsec] How native IPsec use the xfrm framework to implement its function X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0766855773==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0766855773== Content-Type: multipart/alternative; boundary="0-909155402-1099628309=:29125" --0-909155402-1099628309=:29125 Content-Type: text/plain; charset=us-ascii Hi, Now I'm learning the native IPsec implementation of Linux kernel 2.6. would you please tell me where could I find more detailed information about the xfrm subsystem in Linux kernel 2.6 and how native IPsec use the xfrm framework to implement its function? Thank you. -- Best Regards, Park Lee --------------------------------- Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com/a --0-909155402-1099628309=:29125 Content-Type: text/html; charset=us-ascii
Hi,
   Now I'm learning the native IPsec implementation of Linux kernel 2.6. would you please tell me where could I find more detailed information about the xfrm subsystem in Linux kernel 2.6 and how native IPsec use the xfrm framework to implement its function?
 
Thank you.


--
Best Regards,
Park Lee <parklee_sel@yahoo.com>
 

Do you Yahoo!?
Check out the new Yahoo! Front Page. www.yahoo.com; Fri, 5 Nov 2004 00:20:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPwRu-0000EM-1v; Fri, 05 Nov 2004 00:15:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPwNN-0006tt-Q5 for ipsec@megatron.ietf.org; Fri, 05 Nov 2004 00:11:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18002 for ; Fri, 5 Nov 2004 00:11:03 -0500 (EST) Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPwd3-00016m-0z for ipsec@ietf.org; Fri, 05 Nov 2004 00:27:17 -0500 Received: from MDUFFY1.quarrytech.com (rocket.quarrytech.com [10.1.1.127]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V8SJ4723; Fri, 5 Nov 2004 00:10:33 -0500 Message-Id: <6.1.2.0.2.20041104180648.0324da10@email> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 05 Nov 2004 00:02:40 -0500 To: Tero Kivinen From: Mark Duffy Subject: Re: [Ipsec] 2401bis fragment checking for BYPASS/DISCARD In-Reply-To: <16777.62879.881164.449799@fireball.kivinen.iki.fi> References: <20040929021003.GC435@thunk.org> <6.1.2.0.2.20041004135422.02dcf6b0@email> <6.1.2.0.2.20041025184443.030a6b80@email> <6.1.2.0.2.20041101173625.033b0670@email> <6.1.2.0.2.20041102110352.032a1b70@email> <16776.41714.616597.301454@fireball.kivinen.iki.fi> <6.1.2.0.2.20041103170835.02f986f8@email> <16777.62879.881164.449799@fireball.kivinen.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: ipsec@ietf.org, Karen Seo , Stephen Kent X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Tero, I largely agree with your refutations of the 3 attack cases I put forth, though I am leery of relying on SGs to do stateful fragment handling "correctly" without a clear specification of what that means. I also think it may be possible under misconfiguration, if the one SG has multiple SPDs or if there are multiple SGs to the same enterprise, that non-initial fragments for the same {SA, DA, Ident} may be passed via two separate paths and thus permit a fragment overwrite attack. There could be multiple SAs (from different peers) for the same {SA, DA, protocol} and/or one SA and a BYPASS policy. In general, I just do not feel highly confident that there is no way for an attacker to pass non-initial fragments having the same SA,DA as legit fragments. Therefore I still assert that SGs MUST support the option to block all non-initial fragments (which is already the case anyway due to other, more general requirements). I think stateful fragment checking for BYPASS should be a MAY at best, since passing these fragments, even with stateful checking, seems to present certain security risks as noted above. We might want to also consider a MAY/SHOULD that the SG actually reassemble the fragments; has that been discussed previously? --Mark At 04:25 AM 11/4/2004, Tero Kivinen wrote: >Mark Duffy writes: > > 1. When PROTECTed fragments are handled per sect 7.2 (2401bis-04) > there is > > not stateful checking of these fragments so they wouldn't be blocked in > > that way. > >If you are using 7.2 then the receiving SGW will throw away all >non-initial fragments coming outside the special non-initial fragments >SA, as they do not match the required protection for the traffic (i.e. >if the local SGW is configured to use separate SA for non-initial >fragments, it will also require it for incoming non-initial >fragments). > >So no problem there. > > > 2. If the SG implementation is such that its fragment cache is closely > > integrated with its SPD cache (or with a stateful firewall), then a > > PROTECTed and a BYPASSed packet with the same {SA, DA, Ident} but with > > different Protocol, SP, or DP might have their stateful fragment > processing > > done separately (keyed by more than just {SA, DA, IDent} and > simultaneously > > without interfering with each other. > >The statefull fragment checking should be so that external body cannot >distinguish it from the reassembly + refragmentation with identical >boundaries and identical fragment id. So if the SGW is not following >that, but uses extra information when processing packets then it is >incorrect. > > > 3. If the SG implementation frees its fragment cache entry as soon as all > > fragments have been forwarded, it could pass all frags of a legitimate > > packet first then all frags of an attack packet next. And then those > > fragments could be reordered in the network prior to delivery to the > > destination. > >I would consider such SG implementation quite bad. It would not be >incorrect, but it is little bit unsecure way to implement it. Note, >that using this to attack the end host requires attacker to do some >other attacks to, normally he cannot force reordering of the packets >happening inside the network after SGW. > > > Any of these cases could lead to an attacker corrupting a packet that had > > been PROTECTed. > >Only if the SGW implementation is also badly implemented. SGW is >designed to protect the hosts behind it, so it should be correctly >implemented, and also it should have more stricter rules than normal >hosts (i.e. keep checking the fragments for little bit longer etc). > > > In general, I think that > > -if there is any way for non-initial fragments from an attacker to > > transit an SG > > -and the attacker can guess or observe that there is fragmentation > > -and the attacker can guess or observe the SA, DA, and Ident of a > > fragmented packet > > Then the attacker may be able to corrupt the reassembled victim packet. > >That makes the attack quite hard already, and I still do not think >the attacks would work against the stateful fragment checking, >especially if it is implemented in the "collect all fragments, just >like doing reassembly - then send them out" format (very inefficient >and expensive, but the safe way to do it). All other implementations >of stateful fragment checking should have similar properties than to >that version. You can make optimizations to that, but you need to keep >the security properties of that original model. > > > The "hostile" fragments don't even have to be BYPASSed, they can be > > PROTECTed and statefully checked! > >In that case either the policy is unsecure or the attacker is behind >the another SGW, in which case the SGW's are not supposed to protect >against those attacks (i.e. if they are allowed by policy, then the >attacks are allowed by policy :-) >-- >kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 5 04:41:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21129 for ; Fri, 5 Nov 2004 04:41:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ0S1-0005qi-89; Fri, 05 Nov 2004 04:32:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ0MW-0004re-E2 for ipsec@megatron.ietf.org; Fri, 05 Nov 2004 04:26:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19595 for ; Fri, 5 Nov 2004 04:26:26 -0500 (EST) Received: from smtp8.clb.oleane.net ([213.56.31.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ0cE-0005o9-44 for ipsec@ietf.org; Fri, 05 Nov 2004 04:42:42 -0500 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) by smtp8.clb.oleane.net with ESMTP id iA59PuTc008105 for ; Fri, 5 Nov 2004 10:25:56 +0100 Message-Id: <200411050925.iA59PuTc008105@smtp8.clb.oleane.net> From: "Gunther Palmer" To: Date: Fri, 5 Nov 2004 10:25:52 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTDGXF2oFUSiyUBRc6smsVta/yqRw== X-Spam-Score: 0.1 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Subject: [Ipsec] SSL VPN Conference: Call for proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1164071424==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1164071424== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C2_01C4C321.D42E7CD0" This is a multi-part message in MIME format. ------=_NextPart_000_00C2_01C4C321.D42E7CD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit . How to provide SSL-based remote access to a broad range of Web and legacy applications? . What about application performance and requirements? . Are encrypted application tunnelling issues solved? . What differences with IPsec VPNs? These questions, among others, will be tackled by the most recognised experts in this field during the SSL VPN Conference to be held in Paris from April 5 to 8, 2005 The call for proposal dead line has been extended to November 30. Details at: http://www.upperside.fr/sslvpn05/sslvpn05intro.htm ------=_NextPart_000_00C2_01C4C321.D42E7CD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

• = How to provide SSL-based remote access to a broad range of Web and legacy applications?
• = What about application performance and requirements?
• = Are encrypted application tunnelling issues solved?
• = What differences with IPsec VPNs?

These questions, among others, will be tackled by the most recognised = experts in this field during the SSL VPN = Conference to be held in Paris from April 5 to 8, 2005

 

The call for proposal dead line has been = extended to November 30.

 

Details = at:

 

http://www.upperside.fr/sslvpn05/sslvpn05intro.htm

 

------=_NextPart_000_00C2_01C4C321.D42E7CD0-- --===============1164071424== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1164071424==-- From ipsec-bounces@ietf.org Fri Nov 5 05:21:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26209 for ; Fri, 5 Nov 2004 05:21:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ17I-00043K-On; Fri, 05 Nov 2004 05:14:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ0Ur-0006AP-0k for ipsec@megatron.ietf.org; Fri, 05 Nov 2004 04:35:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20116 for ; Fri, 5 Nov 2004 04:34:40 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ0kC-0005xW-OX for ipsec@ietf.org; Fri, 05 Nov 2004 04:50:57 -0500 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iA59Spd16492 for ; Fri, 5 Nov 2004 04:28:51 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iA59VTrs005580 for ; Fri, 5 Nov 2004 04:31:29 -0500 (EST) Received: from a43006.upc-a.chello.nl(62.163.43.6) by nutshell.tislabs.com via csmap (V6.0) id srcAAAH1aG4k; Fri, 5 Nov 04 04:31:25 -0500 Date: Fri, 05 Nov 2004 10:34:34 +0100 To: "Ipsec" From: "Jesse.walker" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------tizljdjsbmatwkbtgcei" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: Hello X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------tizljdjsbmatwkbtgcei Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :)
----------tizljdjsbmatwkbtgcei Content-Type: text/html; name="price.com.htm" Content-Disposition: attachment; filename="price.com.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: price.com
Virus name: W32/Bagle.bb@MM

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

----------tizljdjsbmatwkbtgcei Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------tizljdjsbmatwkbtgcei-- From ipsec-bounces@ietf.org Fri Nov 5 05:26:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26849 for ; Fri, 5 Nov 2004 05:26:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ17v-00049q-9B; Fri, 05 Nov 2004 05:15:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ0Xn-0006aJ-7J for ipsec@megatron.ietf.org; Fri, 05 Nov 2004 04:38:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20522 for ; Fri, 5 Nov 2004 04:37:50 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.194]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ0nF-00061v-2K for ipsec@ietf.org; Fri, 05 Nov 2004 04:54:06 -0500 Received: by rproxy.gmail.com with SMTP id a41so33104rng for ; Fri, 05 Nov 2004 01:37:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=srjFANiN5/5zZ7SwOVgzxSmm/PjUvQW08LL61zJU7gW3bbtdv0WodIANOf0F2g3Zh9zBNv1vgfExEaqatbEQweDmQrewCUnzxGzU8jF1Gbt2Z/8nDPQVhP01yy/X7FI86W3rNavGqCf/4e0l5W7lFV8Xak+6wZ8TF7qJubZwSYc= Received: by 10.38.5.73 with SMTP id 73mr193825rne; Fri, 05 Nov 2004 01:37:49 -0800 (PST) Received: by 10.38.149.27 with HTTP; Fri, 5 Nov 2004 01:37:49 -0800 (PST) Message-ID: Date: Fri, 5 Nov 2004 10:37:49 +0100 From: Oscar Mateo To: ipsec@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [Ipsec] UDP-Encapsulating and PMTU X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Oscar Mateo List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi everybody, I have the folllowing problem implementing ICMP Processing (RFC 2401, section 6) and UDP Encapsulation: In case the ICMP MTU message only contains only the internet header plus the first 64 bits of the original datagram's data, it is impossible to recover the corresponding SPI, how should I perform the processing then? Any thoughts appreciated!! Best Regards, Oscar Mateo Teldat S.A. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 5 08:49:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12971 for ; Fri, 5 Nov 2004 08:49:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ4Qd-0000ZB-DS; Fri, 05 Nov 2004 08:46:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ4NB-00005K-6Q for ipsec@megatron.ietf.org; Fri, 05 Nov 2004 08:43:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12678 for ; Fri, 5 Nov 2004 08:43:23 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ4cu-0003MT-N2 for ipsec@ietf.org; Fri, 05 Nov 2004 08:59:41 -0500 Received: from nutshell.tislabs.com (firewall-user@ns1.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iA5DbWd15150 for ; Fri, 5 Nov 2004 08:37:33 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iA5DeBDU016701 for ; Fri, 5 Nov 2004 08:40:11 -0500 (EST) Received: from mx2.trusecure.com(208.251.192.11) by nutshell.tislabs.com via csmap (V6.0) id srcAAAuka4MG; Fri, 5 Nov 04 08:40:09 -0500 Received: by mx2.trusecure.com (Postfix, from userid 1006) id E0D15C922E; Fri, 5 Nov 2004 08:43:16 -0500 (EST) Received: from VAMAIL01.corp.trusecure.net (vamail01.corp.trusecure.net [172.19.1.52]) by mx2.trusecure.com (Postfix) with ESMTP id CFBDCC91DA; Fri, 5 Nov 2004 08:43:16 -0500 (EST) Received: from HRN-MSC-EXCH-01.mscore.trusecure.net (hrn-msc-exch-01.corp.trusecure.net [172.19.1.49]) by VAMAIL01.corp.trusecure.net (8.12.10/maybe_its_not_even_really_Sendmail....) with ESMTP id iA5DhE1j027845; Fri, 5 Nov 2004 08:43:14 -0500 (EST) Received: from hrn-msc-exch-02.mscore.trusecure.net ([172.19.1.56]) by HRN-MSC-EXCH-01.mscore.trusecure.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Nov 2004 08:43:16 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] future bakeoffs for IKEv2 and RFC2401bis X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 5 Nov 2004 08:43:14 -0500 Message-ID: <04D8F83756A1A84BA156BBFF26FAE0F5FA84E3@hrn-msc-exch-02.mscore.trusecure.net> Thread-Topic: [Ipsec] future bakeoffs for IKEv2 and RFC2401bis Thread-Index: AcTCyakYvsF9srTZTiqY+dCGKi7RbAAcSLzg From: "Zimmerman, Mark" To: "Michael Richardson" , X-OriginalArrivalTime: 05 Nov 2004 13:43:16.0022 (UTC) FILETIME=[66E98D60:01C4C33D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable =20 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael, We've floated what functionality vendors most want tested at the upcoming Santa Clara IKEv2 bakeoff, and it was unanimously agreed upon that we keep it simple and concentrate testing on Messages 1 thru 4 and rekeying. Not a lot of interest is being shown yet for testing extended functions such as EAP, NAT-T or CP Payloads although if anyone wishes we will happily oblige. For that reason, we're planning that the Santa Clara event will only be the FIRST of such IKEv2 Interoperability workshops we'll be holding. Any suggestions for locations and dates of followup events cheerfully accepted. Regards, =20 - -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Michael Richardson Sent: Thursday, November 04, 2004 11:04 AM To: ipsec@lists.tislabs.com Subject: [Ipsec] future bakeoffs for IKEv2 and RFC2401bis - -----BEGIN PGP SIGNED MESSAGE----- Hi, as many of you know Connectathon occurs in late february 2005. ICSA is having a bakeoff very close by, a couple of days earlier. (Maybe they will actually combine forces, I don't know). While it seems that we can depend upon Connectathon 2006 occuring, I think that IKEv2 implementors may need another event near the end of the summer, early fall. One thought is that maybe ETSI would organize something the week after the Paris IETF. I'm personally not crazy about that for various personal reasons, and I think that August IETFs are a bad idea anyway. (Maybe all of france will be on vacation then too...) I just wanted to plant the idea of having some kind of event in late September, early October 2005.=20 As a final idea, having it around the November 2005 IETF is okay, but probably too long between events. - - -- ] "Elmo went to the wrong fundraiser" - The Simpson | 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 iQCVAwUBQYpS7oqHRg3pndX9AQG0xQP/cHnvO4FMXooNqC0X67yfOf4lwDMMIQ/5 tHi0F3Zoaa7PeesI5dPEeuiIT1MM4+Vxx8/huIO8fKn2PfFHEnEv/L28GED6bUvw WP9gbuIQ0fLJYPlRJNaKt0lmrtJJToKcVl6vSIQsaRFh9zV0139SvBt3pW1rCs5m a5OZatQMMPQ=3D =3Dtrp2 - -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQYuDcnYqhttf6ax6EQIZSwCgpZQnDdlQzKrhBrQBSn+XE6PMWaQAn2B8 RL/U3abf1hd56ipEC/pF5WX1 =3DEXok -----END PGP SIGNATURE----- *********************************************************************** This message is intended only for the use of the intended recipient and may contain information that is PRIVILEGED and/or CONFIDENTIAL. If you are not the intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error, please destroy all copies of this message and its attachments and notify us immediately. *********************************************************************** _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 5 09:40:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16859 for ; Fri, 5 Nov 2004 09:40:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ5Dq-000150-Lu; Fri, 05 Nov 2004 09:37:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ55A-0007mq-JH for ipsec@megatron.ietf.org; Fri, 05 Nov 2004 09:28:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15973 for ; Fri, 5 Nov 2004 09:28:47 -0500 (EST) Received: from thunk.org ([69.25.196.29] helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ5Kq-0004Mh-UF for ipsec@ietf.org; Fri, 05 Nov 2004 09:45:06 -0500 Received: from c-67-167-19-206.client.comcast.net ([67.167.19.206] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1CQ51n-0003sk-00; Fri, 05 Nov 2004 09:25:23 -0500 Received: from tytso by thunk.org with local (Exim 4.34) id 1CQ51I-0006Jd-Uk; Fri, 05 Nov 2004 09:24:52 -0500 Date: Fri, 5 Nov 2004 09:24:52 -0500 From: "Theodore Ts'o" To: Mark Duffy Subject: Re: [Ipsec] 2401bis fragment checking for BYPASS/DISCARD Message-ID: <20041105142451.GA24141@thunk.org> References: <6.1.2.0.2.20041004135422.02dcf6b0@email> <6.1.2.0.2.20041025184443.030a6b80@email> <6.1.2.0.2.20041101173625.033b0670@email> <6.1.2.0.2.20041102110352.032a1b70@email> <16776.41714.616597.301454@fireball.kivinen.iki.fi> <6.1.2.0.2.20041103170835.02f986f8@email> <16777.62879.881164.449799@fireball.kivinen.iki.fi> <6.1.2.0.2.20041104180648.0324da10@email> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.2.0.2.20041104180648.0324da10@email> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ipsec@ietf.org, Karen Seo , Stephen Kent , Tero Kivinen X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Fri, Nov 05, 2004 at 12:02:40AM -0500, Mark Duffy wrote: > > Therefore I still assert that SGs MUST support the option to block all > non-initial fragments (which is already the case anyway due to other, more > general requirements). I think stateful fragment checking for BYPASS > should be a MAY at best, since passing these fragments, even with stateful > checking, seems to present certain security risks as noted above. How fragments should be handled has been a subject of a long, intense discussion in past months. A very large number of arguments were made and remade about which strategies are MUST/SHOULD/MAY, and while we finally achieved what I can only call rough consensus on our current set of MUST/SHOULD's. It is for this reason that we preserved the "legislative history" in Appendix D of rfc2401-bis, and section D.8 reads as follows: There is no simple, uniform way to handle fragments in all contexts. Different approaches work better in different contexts. Thus this document offers 3 choices -- one MUST and two MAYs. At some point in the future, if the community gains experience with the two MAYs, they may become SHOULDs or MUSTs or other approaches may be proposed. Beyond this point, we had declared this issue closed, so that the working group could make forward progress. While we could reopen this issue if there was a significant technical defect that had since been discovered, the concerns which you have raised don't appear to rise to this level. Yes, there are ways that a naive implementor could create an insecure implementation. But is that is true of pretty much all security systems, and I believe you and Tero agree that it is possible to do stateful fragment checking (ultimately which is a MAY). As the working group had discussed, there does seem to be general agreement that many, if not most sites aren't even doing port-specific SA's, but instead use tunnel mode SA's that are configured to pass traffic without regard to the port field. This is why section 7.1 is a MUST, and the alternative approaches in section 7.2 and 7.3 are MAY's. I must therefore question whether it is worth holding up the entire rfc2401bis document over what seems minor points for a usage case that is outside of what is currently the common use of ipsec. Especially given that section D.8 calls out the fact that we may change how we handle this in the future, have we not reached the point where it is time to shoot the engineers and ship the product? > We might > want to also consider a MAY/SHOULD that the SG actually reassemble the > fragments; has that been discussed previously? In fact, the current text of rfc2401-bis states (in section 7.3): 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 discard non-initial fragments that arrive on an SA with non- So reassembly is explicitly listed as a way of implementing stateful fragment checking. - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 5 10:28:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21365 for ; Fri, 5 Nov 2004 10:28:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ5yV-0006Vw-7p; Fri, 05 Nov 2004 10:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ5y2-0006PU-BJ for ipsec@megatron.ietf.org; Fri, 05 Nov 2004 10:25:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21193 for ; Fri, 5 Nov 2004 10:25:32 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ6Dn-0005Sy-97 for ipsec@ietf.org; Fri, 05 Nov 2004 10:41:51 -0500 Received: from nutshell.tislabs.com (firewall-user@ns1.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iA5FJad24862 for ; Fri, 5 Nov 2004 10:19:36 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iA5FMHnQ001990 for ; Fri, 5 Nov 2004 10:22:17 -0500 (EST) Received: from unknown(83.145.195.1) by nutshell.tislabs.com via csmap (V6.0) id srcAAAaSaq2d; Fri, 5 Nov 04 10:22:10 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iA5FPGXj013413 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 5 Nov 2004 17:25:16 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iA5FPF2R013410; Fri, 5 Nov 2004 17:25:15 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.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: <16779.39771.427657.893655@fireball.kivinen.iki.fi> Date: Fri, 5 Nov 2004 17:25:15 +0200 From: Tero Kivinen To: Michael Richardson Subject: [Ipsec] future bakeoffs for IKEv2 and RFC2401bis In-Reply-To: <5041.1099584242@marajade.sandelman.ottawa.on.ca> References: <5041.1099584242@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 1 min X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Michael Richardson writes: > Hi, as many of you know Connectathon occurs in late february 2005. > ICSA is having a bakeoff very close by, a couple of days earlier. (Maybe > they will actually combine forces, I don't know). Hmm.. we can also do some testing in the IETF. I will be in the Washington IETF and I am willing to test with someone if someone else is also interested to do some testing... (send me mail if you are interested). > One thought is that maybe ETSI would organize something the week after > the Paris IETF. I'm personally not crazy about that for various > personal reasons, and I think that August IETFs are a bad idea > anyway. (Maybe all of france will be on vacation then too...) Those ETSI events have had very few people wanting to participate them... -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 5 11:31:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26329 for ; Fri, 5 Nov 2004 11:31:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ6se-0004xu-0B; Fri, 05 Nov 2004 11:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ6m9-0003lm-2G for ipsec@megatron.ietf.org; Fri, 05 Nov 2004 11:17:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25184 for ; Fri, 5 Nov 2004 11:17:18 -0500 (EST) Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ71u-0006a9-JG for ipsec@ietf.org; Fri, 05 Nov 2004 11:33:39 -0500 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.230]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V8SJ49MS; Fri, 5 Nov 2004 11:16:49 -0500 Message-Id: <6.1.2.0.2.20041105104954.032fe1d8@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 05 Nov 2004 11:14:55 -0500 To: "Theodore Ts'o" From: Mark Duffy Subject: Re: [Ipsec] 2401bis fragment checking for BYPASS/DISCARD In-Reply-To: <20041105142451.GA24141@thunk.org> References: <6.1.2.0.2.20041004135422.02dcf6b0@email> <6.1.2.0.2.20041025184443.030a6b80@email> <6.1.2.0.2.20041101173625.033b0670@email> <6.1.2.0.2.20041102110352.032a1b70@email> <16776.41714.616597.301454@fireball.kivinen.iki.fi> <6.1.2.0.2.20041103170835.02f986f8@email> <16777.62879.881164.449799@fireball.kivinen.iki.fi> <6.1.2.0.2.20041104180648.0324da10@email> <20041105142451.GA24141@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ipsec@ietf.org, Karen Seo , Stephen Kent , Tero Kivinen X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Ted, and thanks for responding on this. Let me summarize in just a few points: . Most of the "long, intense discussion" was about PROTECTed packets, not about BYPASSed packets which are currently at issue. . The "one MUST and two MAYs" (7.1, 7.2, 7.3) you cite below are for PROTECTed packets. For BYPASS we currently have only MUST (sect 7.4) for stateful fragment checking. . D.4 explains the rationale for the MUST on BYPASS, based on a particular attack it might counter. . I have questioned whether stateful fragment checking on BYPASS actually does counter the proposed attack, and suggested that as a result it should be reduced from a MUST to a MAY. Now, I can see that this issue has not raised a lot of interest or concern and I do not want to hold up the process so I will not press further. --Thanks, Mark At 09:24 AM 11/5/2004, Theodore Ts'o wrote: >How fragments should be handled has been a subject of a long, intense >discussion in past months. A very large number of arguments were made >and remade about which strategies are MUST/SHOULD/MAY, and while we >finally achieved what I can only call rough consensus on our current >set of MUST/SHOULD's. > >It is for this reason that we preserved the "legislative history" in >Appendix D of rfc2401-bis, and section D.8 reads as follows: > > There is no simple, uniform way to handle fragments in all contexts. > Different approaches work better in different contexts. Thus this > document offers 3 choices -- one MUST and two MAYs. At some point in > the future, if the community gains experience with the two MAYs, they > may become SHOULDs or MUSTs or other approaches may be proposed. > >Beyond this point, we had declared this issue closed, so that the >working group could make forward progress. While we could reopen this >issue if there was a significant technical defect that had since been >discovered, the concerns which you have raised don't appear to rise to >this level. Yes, there are ways that a naive implementor could create >an insecure implementation. But is that is true of pretty much all >security systems, and I believe you and Tero agree that it is possible >to do stateful fragment checking (ultimately which is a MAY). > >As the working group had discussed, there does seem to be general >agreement that many, if not most sites aren't even doing port-specific >SA's, but instead use tunnel mode SA's that are configured to pass >traffic without regard to the port field. This is why section 7.1 is >a MUST, and the alternative approaches in section 7.2 and 7.3 are >MAY's. > >I must therefore question whether it is worth holding up the entire >rfc2401bis document over what seems minor points for a usage case that >is outside of what is currently the common use of ipsec. Especially >given that section D.8 calls out the fact that we may change how we >handle this in the future, have we not reached the point where it is >time to shoot the engineers and ship the product? _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 5 17:02:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23377 for ; Fri, 5 Nov 2004 17:02:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQC36-0008Qz-AP; Fri, 05 Nov 2004 16:55:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQC1d-00081y-RJ for ipsec@megatron.ietf.org; Fri, 05 Nov 2004 16:53:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22504 for ; Fri, 5 Nov 2004 16:53:39 -0500 (EST) Received: from thunk.org ([69.25.196.29] helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQC1d-0005TN-3X for ipsec@ietf.org; Fri, 05 Nov 2004 16:53:41 -0500 Received: from c-67-167-19-206.client.comcast.net ([67.167.19.206] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1CQByU-0005W5-00; Fri, 05 Nov 2004 16:50:26 -0500 Received: from tytso by thunk.org with local (Exim 4.34) id 1CQBxy-0005vS-Qb; Fri, 05 Nov 2004 16:49:54 -0500 Date: Fri, 5 Nov 2004 16:49:54 -0500 From: "Theodore Ts'o" To: Mark Duffy Subject: Re: [Ipsec] 2401bis fragment checking for BYPASS/DISCARD Message-ID: <20041105214954.GA22421@thunk.org> References: <6.1.2.0.2.20041025184443.030a6b80@email> <6.1.2.0.2.20041101173625.033b0670@email> <6.1.2.0.2.20041102110352.032a1b70@email> <16776.41714.616597.301454@fireball.kivinen.iki.fi> <6.1.2.0.2.20041103170835.02f986f8@email> <16777.62879.881164.449799@fireball.kivinen.iki.fi> <6.1.2.0.2.20041104180648.0324da10@email> <20041105142451.GA24141@thunk.org> <6.1.2.0.2.20041105104954.032fe1d8@email> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.2.0.2.20041105104954.032fe1d8@email> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: ipsec@ietf.org, Karen Seo , Stephen Kent , Tero Kivinen X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Mark, Thanks for the summary, and my apologies for missing the thrust of your concern, which was for handling of packets which are to BYPASS ipsec processing. Rereading the thread with this in mind, I am certainly sympathetic to your concerns. Certainly one argument in favor of your position is that by requiring stateful fragment checking for BYPASS traffic complicates the implementation, where as simply prohibiting fragments for fragment traffic is much simpler. Furthermore, by requiring the stateful fragment checking machinery in 7.4, that will tend to influence implementations to implement the MAY in section 7.3, which is a minus to those who were opposed to section 7.3 on the grounds of added implementation complexity. As far as some of your comments about the pitfalls about implementing the stateful fragment checking, I'm sure that we could always come up with more text about how to do this securely, either now or in a future document. I will note though that this is hardly new ground, as those who have had to implement stateful fragment checking in firewalls have had to cover 95% of this ground already. However, BYPASS checking, in that it does not require interoperability with another ipsec peer, is one of those things that we can tweak at a later time (or that a vendor can fudge in their implementation) without impacting interoperability. So this is something that we can change in a future document, either by amplifying the specification of how to do the stateful fragment checking (which has been deliberately underspecified in sections 7.3 and 7.4), or by allowing some other variant behaviour. So if you are indeed content to not press this issue at this time, I think many people will thank you for your forbearance; but if you or anyone else feel very strongly that we should make a change, now, just before we go to IETF-wide last call, or during IETF-wide last call, is the last chance to make changes during this rev of the document. - Ted > Let me summarize in just a few points: > > . Most of the "long, intense discussion" was about PROTECTed packets, not > about BYPASSed packets which are currently at issue. > > . The "one MUST and two MAYs" (7.1, 7.2, 7.3) you cite below are for > PROTECTed packets. For BYPASS we currently have only MUST (sect 7.4) for > stateful fragment checking. > > . D.4 explains the rationale for the MUST on BYPASS, based on a particular > attack it might counter. > > . I have questioned whether stateful fragment checking on BYPASS actually > does counter the proposed attack, and suggested that as a result it should > be reduced from a MUST to a MAY. > > > Now, I can see that this issue has not raised a lot of interest or concern > and I do not want to hold up the process so I will not press further. > > --Thanks, Mark > > > At 09:24 AM 11/5/2004, Theodore Ts'o wrote: > >How fragments should be handled has been a subject of a long, intense > >discussion in past months. A very large number of arguments were made > >and remade about which strategies are MUST/SHOULD/MAY, and while we > >finally achieved what I can only call rough consensus on our current > >set of MUST/SHOULD's. > > > >It is for this reason that we preserved the "legislative history" in > >Appendix D of rfc2401-bis, and section D.8 reads as follows: > > > > There is no simple, uniform way to handle fragments in all contexts. > > Different approaches work better in different contexts. Thus this > > document offers 3 choices -- one MUST and two MAYs. At some point in > > the future, if the community gains experience with the two MAYs, they > > may become SHOULDs or MUSTs or other approaches may be proposed. > > > >Beyond this point, we had declared this issue closed, so that the > >working group could make forward progress. While we could reopen this > >issue if there was a significant technical defect that had since been > >discovered, the concerns which you have raised don't appear to rise to > >this level. Yes, there are ways that a naive implementor could create > >an insecure implementation. But is that is true of pretty much all > >security systems, and I believe you and Tero agree that it is possible > >to do stateful fragment checking (ultimately which is a MAY). > > > >As the working group had discussed, there does seem to be general > >agreement that many, if not most sites aren't even doing port-specific > >SA's, but instead use tunnel mode SA's that are configured to pass > >traffic without regard to the port field. This is why section 7.1 is > >a MUST, and the alternative approaches in section 7.2 and 7.3 are > >MAY's. > > > >I must therefore question whether it is worth holding up the entire > >rfc2401bis document over what seems minor points for a usage case that > >is outside of what is currently the common use of ipsec. Especially > >given that section D.8 calls out the fact that we may change how we > >handle this in the future, have we not reached the point where it is > >time to shoot the engineers and ship the product? > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 5 21:50:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15360 for ; Fri, 5 Nov 2004 21:50:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQGZp-0003GC-1n; Fri, 05 Nov 2004 21:45:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQGVR-0002Cg-Mf for ipsec@megatron.ietf.org; Fri, 05 Nov 2004 21:40:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14800 for ; Fri, 5 Nov 2004 21:40:43 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQGVU-0003T4-0d for ipsec@ietf.org; Fri, 05 Nov 2004 21:40:48 -0500 Received: from [10.20.30.249] (user-2iverqa.dialup.mindspring.com [165.247.111.74]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA62eYLP084989 for ; Fri, 5 Nov 2004 18:40:36 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <20041105214954.GA22421@thunk.org> References: <6.1.2.0.2.20041025184443.030a6b80@email> <6.1.2.0.2.20041101173625.033b0670@email> <6.1.2.0.2.20041102110352.032a1b70@email> <16776.41714.616597.301454@fireball.kivinen.iki.fi> <6.1.2.0.2.20041103170835.02f986f8@email> <16777.62879.881164.449799@fireball.kivinen.iki.fi> <6.1.2.0.2.20041104180648.0324da10@email> <20041105142451.GA24141@thunk.org> <6.1.2.0.2.20041105104954.032fe1d8@email> <20041105214954.GA22421@thunk.org> Date: Fri, 5 Nov 2004 18:40:40 -0800 To: IPsec WG From: Paul Hoffman / VPNC Subject: Re: [Ipsec] 2401bis fragment checking for BYPASS/DISCARD Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 4:49 PM -0500 11/5/04, Theodore Ts'o wrote: >So if you are indeed content to not press this issue at this time, I >think many people will thank you for your forbearance; but if you or >anyone else feel very strongly that we should make a change, now, just >before we go to IETF-wide last call, or during IETF-wide last call, is >the last chance to make changes during this rev of the document. Phrased differently, these are perfectly reasonable things to bring up in IETF-wide last call. The protocol features being talked about affect the Internet and are reasonable to discuss, even if we don't end up changing 2401bis to accomodate them other than by mention. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Nov 6 13:54:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27391 for ; Sat, 6 Nov 2004 13:54:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQVdK-0002Ll-Ef; Sat, 06 Nov 2004 13:49:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQVZw-0001wT-HR for ipsec@megatron.ietf.org; Sat, 06 Nov 2004 13:46:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27101 for ; Sat, 6 Nov 2004 13:46:22 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQVa7-00042p-BB for ipsec@ietf.org; Sat, 06 Nov 2004 13:46:35 -0500 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iA6IeUd10052 for ; Sat, 6 Nov 2004 13:40:30 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iA6IhCsU005402 for ; Sat, 6 Nov 2004 13:43:12 -0500 (EST) Received: from a43006.upc-a.chello.nl(62.163.43.6) by nutshell.tislabs.com via csmap (V6.0) id srcAAAEmayHk; Sat, 6 Nov 04 13:43:08 -0500 Date: Sat, 06 Nov 2004 19:46:16 +0100 To: "Ipsec" From: "Jesse.walker" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------iplbzhpwbvqhmmynloph" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: Hello X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------iplbzhpwbvqhmmynloph Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :)
----------iplbzhpwbvqhmmynloph Content-Type: text/html; name="Joke.com.htm" Content-Disposition: attachment; filename="Joke.com.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: Joke.com
Virus name: W32/Bagle.bb@MM

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

----------iplbzhpwbvqhmmynloph Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------iplbzhpwbvqhmmynloph-- From ipsec-bounces@ietf.org Sat Nov 6 23:45:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05114 for ; Sat, 6 Nov 2004 23:45:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQesS-0006cH-2b; Sat, 06 Nov 2004 23:42:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQepk-0005d7-0w for ipsec@megatron.ietf.org; Sat, 06 Nov 2004 23:39:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04654 for ; Sat, 6 Nov 2004 23:39:17 -0500 (EST) Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQeq0-0006bj-BL for ipsec@ietf.org; Sat, 06 Nov 2004 23:39:36 -0500 Received: from MDUFFY1.quarrytech.com (rocket.quarrytech.com [10.1.1.127]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V8SJV1FW; Sat, 6 Nov 2004 23:38:48 -0500 Message-Id: <6.1.2.0.2.20041106231159.0305afa8@localhost> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 06 Nov 2004 23:36:25 -0500 To: "Theodore Ts'o" From: Mark Duffy Subject: Re: [Ipsec] 2401bis fragment checking for BYPASS/DISCARD In-Reply-To: <20041105214954.GA22421@thunk.org> References: <6.1.2.0.2.20041025184443.030a6b80@email> <6.1.2.0.2.20041101173625.033b0670@email> <6.1.2.0.2.20041102110352.032a1b70@email> <16776.41714.616597.301454@fireball.kivinen.iki.fi> <6.1.2.0.2.20041103170835.02f986f8@email> <16777.62879.881164.449799@fireball.kivinen.iki.fi> <6.1.2.0.2.20041104180648.0324da10@email> <20041105142451.GA24141@thunk.org> <6.1.2.0.2.20041105104954.032fe1d8@email> <20041105214954.GA22421@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: ipsec@ietf.org, Karen Seo , Stephen Kent , Tero Kivinen X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Ted, Thank you for taking the time to re-read the thread and think about this issue. What I would seek is a minor change that allows discarding non-initial fragments processed for BYPASS as an alternative to stateful fragment checking of them. I think this can be as simple as replacing this sentence in 7.4: An implementation MUST support stateful fragment checking to accommodate BYPASS traffic for which a non-trivial port range is specified. with this one: An implementation MUST NOT forward fragmented BYPASS traffic without performing stateful fragment checking. I don't want to delay the progress of 2401bis unnecessarily and if the change is made I don't particularly care if it is done now or later in the cycle. I imagine other changes might be needed anyway during IESG review or IETF last call. --Mark At 04:49 PM 11/5/2004, Theodore Ts'o wrote: >Mark, > >Thanks for the summary, and my apologies for missing the thrust of >your concern, which was for handling of packets which are to BYPASS >ipsec processing. > >Rereading the thread with this in mind, I am certainly sympathetic to >your concerns. Certainly one argument in favor of your position is >that by requiring stateful fragment checking for BYPASS traffic >complicates the implementation, where as simply prohibiting fragments >for fragment traffic is much simpler. Furthermore, by requiring the >stateful fragment checking machinery in 7.4, that will tend to >influence implementations to implement the MAY in section 7.3, which >is a minus to those who were opposed to section 7.3 on the grounds of >added implementation complexity. > >As far as some of your comments about the pitfalls about implementing >the stateful fragment checking, I'm sure that we could always come up >with more text about how to do this securely, either now or in a >future document. I will note though that this is hardly new ground, >as those who have had to implement stateful fragment checking in >firewalls have had to cover 95% of this ground already. > >However, BYPASS checking, in that it does not require interoperability >with another ipsec peer, is one of those things that we can tweak at a >later time (or that a vendor can fudge in their implementation) >without impacting interoperability. So this is something that we can >change in a future document, either by amplifying the specification of >how to do the stateful fragment checking (which has been deliberately >underspecified in sections 7.3 and 7.4), or by allowing some other >variant behaviour. > >So if you are indeed content to not press this issue at this time, I >think many people will thank you for your forbearance; but if you or >anyone else feel very strongly that we should make a change, now, just >before we go to IETF-wide last call, or during IETF-wide last call, is >the last chance to make changes during this rev of the document. > > - Ted > > > Let me summarize in just a few points: > > > > . Most of the "long, intense discussion" was about PROTECTed packets, not > > about BYPASSed packets which are currently at issue. > > > > . The "one MUST and two MAYs" (7.1, 7.2, 7.3) you cite below are for > > PROTECTed packets. For BYPASS we currently have only MUST (sect 7.4) for > > stateful fragment checking. > > > > . D.4 explains the rationale for the MUST on BYPASS, based on a > particular > > attack it might counter. > > > > . I have questioned whether stateful fragment checking on BYPASS actually > > does counter the proposed attack, and suggested that as a result it should > > be reduced from a MUST to a MAY. > > > > > > Now, I can see that this issue has not raised a lot of interest or concern > > and I do not want to hold up the process so I will not press further. > > > > --Thanks, Mark > > > > > > At 09:24 AM 11/5/2004, Theodore Ts'o wrote: > > >How fragments should be handled has been a subject of a long, intense > > >discussion in past months. A very large number of arguments were made > > >and remade about which strategies are MUST/SHOULD/MAY, and while we > > >finally achieved what I can only call rough consensus on our current > > >set of MUST/SHOULD's. > > > > > >It is for this reason that we preserved the "legislative history" in > > >Appendix D of rfc2401-bis, and section D.8 reads as follows: > > > > > > There is no simple, uniform way to handle fragments in all contexts. > > > Different approaches work better in different contexts. Thus this > > > document offers 3 choices -- one MUST and two MAYs. At some point in > > > the future, if the community gains experience with the two MAYs, they > > > may become SHOULDs or MUSTs or other approaches may be proposed. > > > > > >Beyond this point, we had declared this issue closed, so that the > > >working group could make forward progress. While we could reopen this > > >issue if there was a significant technical defect that had since been > > >discovered, the concerns which you have raised don't appear to rise to > > >this level. Yes, there are ways that a naive implementor could create > > >an insecure implementation. But is that is true of pretty much all > > >security systems, and I believe you and Tero agree that it is possible > > >to do stateful fragment checking (ultimately which is a MAY). > > > > > >As the working group had discussed, there does seem to be general > > >agreement that many, if not most sites aren't even doing port-specific > > >SA's, but instead use tunnel mode SA's that are configured to pass > > >traffic without regard to the port field. This is why section 7.1 is > > >a MUST, and the alternative approaches in section 7.2 and 7.3 are > > >MAY's. > > > > > >I must therefore question whether it is worth holding up the entire > > >rfc2401bis document over what seems minor points for a usage case that > > >is outside of what is currently the common use of ipsec. Especially > > >given that section D.8 calls out the fact that we may change how we > > >handle this in the future, have we not reached the point where it is > > >time to shoot the engineers and ship the product? > > > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Nov 7 15:33:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22054 for ; Sun, 7 Nov 2004 15:33:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQtg0-0006mD-14; Sun, 07 Nov 2004 15:30:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQtYn-0003Mz-Rd for ipsec@megatron.ietf.org; Sun, 07 Nov 2004 15:22:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21086 for ; Sun, 7 Nov 2004 15:22:47 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQtZC-0002w3-C5 for ipsec@ietf.org; Sun, 07 Nov 2004 15:23:14 -0500 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iA7KGqd20540 for ; Sun, 7 Nov 2004 15:16:52 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iA7KJXZZ012956 for ; Sun, 7 Nov 2004 15:19:33 -0500 (EST) Received: from a43006.upc-a.chello.nl(62.163.43.6) by nutshell.tislabs.com via csmap (V6.0) id srcAAAntaGsz; Sun, 7 Nov 04 15:19:25 -0500 Date: Sun, 07 Nov 2004 21:22:33 +0100 To: "Ipsec" From: "Jesse.walker" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------avvyepxirjctvfsdtrdd" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: Hi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------avvyepxirjctvfsdtrdd Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :))
----------avvyepxirjctvfsdtrdd Content-Type: text/html; name="price.com.htm" Content-Disposition: attachment; filename="price.com.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: price.com
Virus name: W32/Bagle.bb@MM

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

----------avvyepxirjctvfsdtrdd Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------avvyepxirjctvfsdtrdd-- From ipsec-bounces@ietf.org Mon Nov 8 03:23:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09798 for ; Mon, 8 Nov 2004 03:23:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR4kk-0007S1-Oz; Mon, 08 Nov 2004 03:19:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR4kJ-0007Lz-57 for ipsec@megatron.ietf.org; Mon, 08 Nov 2004 03:19:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09465 for ; Mon, 8 Nov 2004 03:19:25 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR4ko-0001oH-1P for ipsec@ietf.org; Mon, 08 Nov 2004 03:19:58 -0500 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id iA88IaX02668; Mon, 8 Nov 2004 10:18:36 +0200 (IST) In-Reply-To: <4187D91E.2090703@cisco.com> References: <125EA890549C8641A72F3809CB80DCCD17839D@esebe056.ntc.nokia.com> <16773.63589.716356.612414@fireball.kivinen.iki.fi> <4187D91E.2090703@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] Reauthentication in IKEv2 Date: Mon, 8 Nov 2004 10:18:35 +0200 To: Geoffrey Huang X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, Tero Kivinen X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit And yet, even in IKEv2 when lifetimes are appropriate they are used. Take the Cfg payload. Since the back-end server is usually a DHCP server, we want to make the client request an extension to the INTERNAL_IPx_ADDRESS. That is why there is an attribute called INTERNAL_ADDRESS_EXPIRY. To quote from the draft, "INTERNAL_ADDRESS_EXPIRY - Specifies the number of seconds that the host can use the internal IP address. The host MUST renew the IP address before this expiry time." So IKEv2 is not averse to forcing hosts to keep timers when there is good reason. Although being able to re-authenticate at an arbitrary time is nice flexibility, this is an attribute that involves human interaction, so the key consideration is not flexibility for the RA gateway, but predictability for the user. Users hate pop-up demands for authentication. That is why almost no websites use http authentication, but rather have an elaborate login screen. Users would much rather have a countdown timer telling them how long they have before they need to type in their credentials again. As others have mentioned, there is also the issue of going to lunch and leaving the long ftp going, as well as other protocols that require long TCP connections such as telnets, X11 and remote desktops. My proposal still allows you to demand authentication at an arbitrary time, but such a demand should not be "reauthenticate now!" but rather "reauthenticate within 3 minutes". IMO demanding reauthentication means you do not trust your peer anymore, and if that's the case it is only correct to refuse traffic and send a delete. If the notification says "reauthenticate now" the user has no way of knowing how long she has to enter her credentials. At least the pop-up authentication window should have countdown. I've noticed that's it's a very small group here that is talking about it. Do you think this means that there is little interest in re-authentication? Yoav On Nov 2, 2004, at 8:59 PM, Geoffrey Huang wrote: > I have to agree with Tero on this thread. The idea of the > AUTH_LIFETIME notify strikes me as very similar to the negotiated > lifetimes of IKEv1. I quite like the way lifetimes are done in IKEv2. > Since it's a policy matter that each peer needs to enforce locally, I > don't see a reason why the lifetime ever needs to be communicated. > > Note that the idea of a REAUTH_NOW message also allows for signalling > a peer's desire to re-authenticate at an arbitrary time. I like this > flexibility. > > -g > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 8 05:48:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20528 for ; Mon, 8 Nov 2004 05:48:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR72c-0003uN-3y; Mon, 08 Nov 2004 05:46:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR71D-0003cC-6A for ipsec@megatron.ietf.org; Mon, 08 Nov 2004 05:45:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20367 for ; Mon, 8 Nov 2004 05:45:00 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR71j-0004se-Cu for ipsec@ietf.org; Mon, 08 Nov 2004 05:45:35 -0500 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iA8Ad7d08962 for ; Mon, 8 Nov 2004 05:39:07 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iA8AfpX1004051 for ; Mon, 8 Nov 2004 05:41:51 -0500 (EST) Received: from a43006.upc-a.chello.nl(62.163.43.6) by nutshell.tislabs.com via csmap (V6.0) id srcAAACMai4h; Mon, 8 Nov 04 05:41:46 -0500 Date: Mon, 08 Nov 2004 11:44:52 +0100 To: "Ipsec" From: "Jesse.walker" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------mcoszrzzavapnyydboja" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------mcoszrzzavapnyydboja Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :)
----------mcoszrzzavapnyydboja Content-Type: text/html; name="price.cpl.htm" Content-Disposition: attachment; filename="price.cpl.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: price.cpl
Virus name: W32/Bagle.bb@MM

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

----------mcoszrzzavapnyydboja Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------mcoszrzzavapnyydboja-- From ipsec-bounces@ietf.org Tue Nov 9 02:48:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25627 for ; Tue, 9 Nov 2004 02:48:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRQgv-0005H4-PW; Tue, 09 Nov 2004 02:45:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRQdx-0004d8-5g for ipsec@megatron.ietf.org; Tue, 09 Nov 2004 02:42:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24971 for ; Tue, 9 Nov 2004 02:42:19 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRQee-0003ZL-G0 for ipsec@ietf.org; Tue, 09 Nov 2004 02:43:04 -0500 Received: from nutshell.tislabs.com (firewall-user@ns1.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iA97aMd14420 for ; Tue, 9 Nov 2004 02:36:23 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iA97d8PK020365 for ; Tue, 9 Nov 2004 02:39:08 -0500 (EST) Received: from a43006.upc-a.chello.nl(62.163.43.6) by nutshell.tislabs.com via csmap (V6.0) id srcAAAkTaqWN; Tue, 9 Nov 04 02:39:03 -0500 Date: Tue, 09 Nov 2004 08:42:11 +0100 To: "Ipsec" From: "Jesse.walker" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------svoawussfnsfuahxfcfh" X-Spam-Score: 1.2 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: Thanks :) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------svoawussfnsfuahxfcfh Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :))
----------svoawussfnsfuahxfcfh Content-Type: text/html; name="Price.com.htm" Content-Disposition: attachment; filename="Price.com.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: Price.com
Virus name: W32/Bagle.bb@MM

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

----------svoawussfnsfuahxfcfh Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------svoawussfnsfuahxfcfh-- From ipsec-bounces@ietf.org Wed Nov 10 04:37:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14987 for ; Wed, 10 Nov 2004 04:37:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRoo3-0003gV-32; Wed, 10 Nov 2004 04:30:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRolO-0003QZ-QD for ipsec@megatron.ietf.org; Wed, 10 Nov 2004 04:27:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13967 for ; Wed, 10 Nov 2004 04:27:32 -0500 (EST) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRomF-00054h-V6 for ipsec@ietf.org; Wed, 10 Nov 2004 04:28:32 -0500 Received: from nutshell.tislabs.com (firewall-user@ns1.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAA9LZd16281 for ; Wed, 10 Nov 2004 04:21:35 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAA9OFIa022963 for ; Wed, 10 Nov 2004 04:24:15 -0500 (EST) Received: from a43006.upc-a.chello.nl(62.163.43.6) by nutshell.tislabs.com via csmap (V6.0) id srcAAALeaqZS; Wed, 10 Nov 04 04:24:09 -0500 Date: Wed, 10 Nov 2004 10:27:18 +0100 To: "Ipsec" From: "Jesse.walker" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------zoluiwexbbsgpoisybdi" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: Hi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------zoluiwexbbsgpoisybdi Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :)
----------zoluiwexbbsgpoisybdi Content-Type: text/html; name="price.scr.htm" Content-Disposition: attachment; filename="price.scr.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: price.scr
Virus name: W32/Bagle.bb@MM

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

----------zoluiwexbbsgpoisybdi Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------zoluiwexbbsgpoisybdi-- From ipsec-bounces@ietf.org Wed Nov 10 12:24:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03196 for ; Wed, 10 Nov 2004 12:24:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRwAK-0006BD-QM; Wed, 10 Nov 2004 12:21:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRvx4-0001wJ-At for ipsec@megatron.ietf.org; Wed, 10 Nov 2004 12:08:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01860 for ; Wed, 10 Nov 2004 12:08:07 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRvy3-0007hu-Kn for ipsec@ietf.org; Wed, 10 Nov 2004 12:09:12 -0500 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAAH24d27734 for ; Wed, 10 Nov 2004 12:02:04 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAAH4p2b003161 for ; Wed, 10 Nov 2004 12:04:51 -0500 (EST) Received: from a43006.upc-a.chello.nl(62.163.43.6) by nutshell.tislabs.com via csmap (V6.0) id srcAAATzaikg; Wed, 10 Nov 04 12:04:46 -0500 Date: Wed, 10 Nov 2004 18:07:56 +0100 To: "Ipsec" From: "Jesse.walker" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------axaqntwfajelcdqwvmwr" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: Thanks :) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------axaqntwfajelcdqwvmwr Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :)
----------axaqntwfajelcdqwvmwr Content-Type: text/html; name="price.scr.htm" Content-Disposition: attachment; filename="price.scr.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: price.scr
Virus name: W32/Bagle.bb@MM

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

----------axaqntwfajelcdqwvmwr Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------axaqntwfajelcdqwvmwr-- From ipsec-bounces@ietf.org Wed Nov 10 19:48:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24164 for ; Wed, 10 Nov 2004 19:48:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS34c-0007Wx-0E; Wed, 10 Nov 2004 19:44:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS2zK-0006jl-8V for ipsec@megatron.ietf.org; Wed, 10 Nov 2004 19:38:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23415 for ; Wed, 10 Nov 2004 19:38:54 -0500 (EST) From: byfraser@cisco.com Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS30M-0003NZ-MK for ipsec@ietf.org; Wed, 10 Nov 2004 19:40:04 -0500 Received: from nutshell.tislabs.com (firewall-user@ns1.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAB0Wud24755 for ; Wed, 10 Nov 2004 19:32:56 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAB0ZiuG025171 for ; Wed, 10 Nov 2004 19:35:44 -0500 (EST) Message-Id: <200411110035.iAB0ZiuG025171@nutshell.tislabs.com> Received: from unknown(211.147.205.6) by nutshell.tislabs.com via csmap (V6.0) id srcAAAeMaGZW; Wed, 10 Nov 04 19:34:36 -0500 To: ipsec@lists.tislabs.com Date: Thu, 11 Nov 2004 08:37:45 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0013_F89997E2.3930ED4C" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 3.7 (+++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Ipsec] STATUS X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0013_F89997E2.3930ED4C Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit It's the long-awaited film version of the Broadway hit. The message sent as a binary attachment. ------=_NextPart_000_0013_F89997E2.3930ED4C Content-Type: text/html; name="fhs.zip.htm" Content-Disposition: attachment; filename="fhs.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: fhs.zip
Virus name: W32/Lovgate.x@MM!zip

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

------=_NextPart_000_0013_F89997E2.3930ED4C Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0013_F89997E2.3930ED4C-- From ipsec-bounces@ietf.org Wed Nov 10 20:35:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28846 for ; Wed, 10 Nov 2004 20:35:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS3mc-0000n7-Ic; Wed, 10 Nov 2004 20:29:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS3ko-0000Pg-6e for ipsec@megatron.ietf.org; Wed, 10 Nov 2004 20:28:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28136 for ; Wed, 10 Nov 2004 20:28:00 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS3ls-0004az-8d for ipsec@ietf.org; Wed, 10 Nov 2004 20:29:08 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 10 Nov 2004 17:27:34 -0800 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iAB1RP0W004669; Wed, 10 Nov 2004 17:27:28 -0800 (PST) Received: from [10.32.227.24] ([10.32.227.24]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id AYW69463; Wed, 10 Nov 2004 17:31:44 -0800 (PST) Message-ID: <4192C00B.2010802@cisco.com> Date: Wed, 10 Nov 2004 17:27:39 -0800 From: Geoffrey Huang User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040924) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoav Nir Subject: Re: [Ipsec] Reauthentication in IKEv2 References: <125EA890549C8641A72F3809CB80DCCD17839D@esebe056.ntc.nokia.com> <16773.63589.716356.612414@fireball.kivinen.iki.fi> <4187D91E.2090703@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, Tero Kivinen X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Yoav Nir wrote: > And yet, even in IKEv2 when lifetimes are appropriate they are used. > > Take the Cfg payload. Since the back-end server is usually a DHCP > server, we want to make the client request an extension to the > INTERNAL_IPx_ADDRESS. That is why there is an attribute called > INTERNAL_ADDRESS_EXPIRY. > > To quote from the draft, "INTERNAL_ADDRESS_EXPIRY - Specifies the number > of seconds that the host can use the internal IP address. The host MUST > renew the IP address before this expiry time." So IKEv2 is not averse > to forcing hosts to keep timers when there is good reason. You make a good point here. > Although being able to re-authenticate at an arbitrary time is nice > flexibility, this is an attribute that involves human interaction, so > the key consideration is not flexibility for the RA gateway, but > predictability for the user. Users hate pop-up demands for > authentication. That is why almost no websites use http authentication, > but rather have an elaborate login screen. Users would much rather have > a countdown timer telling them how long they have before they need to > type in their credentials again. As others have mentioned, there is > also the issue of going to lunch and leaving the long ftp going, as well > as other protocols that require long TCP connections such as telnets, > X11 and remote desktops. > > My proposal still allows you to demand authentication at an arbitrary > time, but such a demand should not be "reauthenticate now!" but rather > "reauthenticate within 3 minutes". IMO demanding reauthentication means > you do not trust your peer anymore, and if that's the case it is only > correct to refuse traffic and send a delete. If the notification says > "reauthenticate now" the user has no way of knowing how long she has to > enter her credentials. At least the pop-up authentication window should > have countdown. I can see arguments from both sides, I guess. Even with your re-auth scheme, a value of "0" seconds could mean "do it now," right? > I've noticed that's it's a very small group here that is talking about > it. Do you think this means that there is little interest in > re-authentication? Um, no. I think this is a valid problem that needs to be solved. -g > Yoav > > On Nov 2, 2004, at 8:59 PM, Geoffrey Huang wrote: > >> I have to agree with Tero on this thread. The idea of the >> AUTH_LIFETIME notify strikes me as very similar to the negotiated >> lifetimes of IKEv1. I quite like the way lifetimes are done in IKEv2. >> Since it's a policy matter that each peer needs to enforce locally, I >> don't see a reason why the lifetime ever needs to be communicated. >> >> Note that the idea of a REAUTH_NOW message also allows for signalling >> a peer's desire to re-authenticate at an arbitrary time. I like this >> flexibility. >> >> -g >> > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 10 21:09:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01439 for ; Wed, 10 Nov 2004 21:09:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS4Mf-0007gA-IP; Wed, 10 Nov 2004 21:07:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS4F7-00067u-Id for ipsec@megatron.ietf.org; Wed, 10 Nov 2004 20:59:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00957 for ; Wed, 10 Nov 2004 20:59:19 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS4G9-0005H4-LW for ipsec@ietf.org; Wed, 10 Nov 2004 21:00:28 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iAB1xCNH017941; Wed, 10 Nov 2004 18:59:12 -0700 (MST) Received: from 192.9.61.12 (punchin-sommerfeld.SFBay.Sun.COM [192.9.61.12]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id iAB1xAkt001513; Wed, 10 Nov 2004 20:59:10 -0500 (EST) Subject: Re: [Ipsec] Reauthentication in IKEv2 From: Bill Sommerfeld To: Geoffrey Huang In-Reply-To: <4192C00B.2010802@cisco.com> References: <125EA890549C8641A72F3809CB80DCCD17839D@esebe056.ntc.nokia.com> <16773.63589.716356.612414@fireball.kivinen.iki.fi> <4187D91E.2090703@cisco.com> <4192C00B.2010802@cisco.com> Content-Type: text/plain Message-Id: <1100138338.1021.5.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 10 Nov 2004 20:58:59 -0500 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, Yoav Nir , Tero Kivinen X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit On Wed, 2004-11-10 at 20:27, Geoffrey Huang wrote: > I can see arguments from both sides, I guess. Even with your re-auth > scheme, a value of "0" seconds could mean "do it now," right? I'd think so; I'd also hope that the encoding should also allow for "reauth in 8 hours" notifications as well. As was pointed out in the secsh working group yesterday for a related user-authentication timeout, there are also accessibility concerns here; some people enter text *very* slowly; 3 minutes may not be sufficient for some. - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 10 21:19:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02151 for ; Wed, 10 Nov 2004 21:19:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS4Ud-0001JZ-UG; Wed, 10 Nov 2004 21:15:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS4Pd-0008T2-Fa for ipsec@megatron.ietf.org; Wed, 10 Nov 2004 21:10:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01487 for ; Wed, 10 Nov 2004 21:10:11 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS4Qf-0005Qo-Ur for ipsec@ietf.org; Wed, 10 Nov 2004 21:11:20 -0500 Received: from [10.67.86.181] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iAB29Vjh000318; Wed, 10 Nov 2004 21:09:33 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <67BF5F17CF3CF9419CFFEDC4F76E053A02B2B1@svr-pkl-exc-01.mgc.mentorg.com> References: <67BF5F17CF3CF9419CFFEDC4F76E053A02B2B1@svr-pkl-exc-01.mgc.mentorg.com> Date: Wed, 10 Nov 2004 21:07:51 -0500 To: "Khan, Irfan" From: Stephen Kent Subject: Re: [Ipsec] Query for IPv6 ICV X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.5 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1088319316==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1088319316== Content-Type: multipart/alternative; boundary="============_-1111983576==_ma============" --============_-1111983576==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 2:43 PM +0500 11/4/04, Khan, Irfan wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C4C252.C14D11BF" > >Hi, > >I'm trying to establish an IPSEC session over IPv6 with Windows XP >and FreeBSD (Kame's implementation) AH Transport mode with HMAC-MD5 >authentication. Windows sends an ICV of 20 bytes (with 4 padded 0 >bytes) and FreeBSD simply discards the packet. > >RFC 2403 states that HMAC-MD5-96 produces a 128 bit authenticator >value and a truncated value using the first 96 bits MUST be >supported. > >I want to know that IPSEC standards say about ICV size in case of IPv6. > 2402 says that the ICV is padded to cause the whole AH length to be an integral multiple of 4 bytes for IPv4, 8 bytes for IPv6. The HMAC-MD5-96 ICV is 12 bytes (96 bits) long, as stated in 2403. That is not only te MUST support length specified by the RFC, it is the only length specified as the output of this algorithm, for use with AH or ESP. I admit that RFC 2403 could be better worded in this regard, but the operative sentence in the RFC states: "No other authenticator value lengths are supported by HMAC-MD5-96." Also, of course, the title of the RFC does provide a hint :-) The rest of the AH header is 12 bytes long, so, the total AH header length, when this integrity algorithm is employed, is 24 bytes. This meets the IPv4 and IPv6 requirements for alignment, since 24 is an integral multiple of both 4 and 8. So, it is not appropriate for the ICV to be padded for IPv4 or IPv6. What you seem to describe is transmission of a 16-byte HMAC output, which is then padded with 4 bytes to cause the result to be an integral multiple of 8 bytes, for IPv6. This is wrong, because the integrity algorithm specified here does not define a 128-bit output. The Windows implementation is broken and the Free BSD implementation is appropriately rejecting the packet. Steve --============_-1111983576==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Ipsec] Query for IPv6 ICV
At 2:43 PM +0500 11/4/04, Khan, Irfan wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
  boundary="----_=_NextPart_001_01C4C252.C14D11BF"
Hi,
 
I'm trying to establish an IPSEC session over IPv6 with Windows XP and FreeBSD (Kame's implementation) AH Transport mode with HMAC-MD5 authentication. Windows sends an ICV of 20 bytes (with 4 padded 0 bytes) and FreeBSD simply discards the packet.
 
RFC 2403 states that HMAC-MD5-96 produces a 128 bit authenticator value and a truncated value using the first 96 bits MUST be supported.
 
I want to know that IPSEC standards say about ICV size in case of IPv6.
 

2402 says that the ICV is padded to cause the whole AH length to be an integral multiple of 4 bytes for IPv4, 8 bytes for IPv6.

The HMAC-MD5-96 ICV is 12 bytes (96 bits) long, as stated in 2403. That is not only te MUST support length specified by the RFC, it is the only length specified as the output of this algorithm, for use with AH or ESP. I admit that RFC 2403 could be better worded in this regard,  but the operative sentence in the RFC states: "No other authenticator value lengths are supported by HMAC-MD5-96." Also, of course, the title of the RFC does provide a hint :-)

The rest of the AH header is 12 bytes long, so, the total AH header length, when this integrity algorithm is employed, is 24 bytes. This meets the IPv4 and IPv6 requirements for alignment, since 24 is an integral multiple of both 4 and 8.

So, it is not appropriate for the ICV to be padded for IPv4 or IPv6.

What you seem to describe is transmission of a 16-byte HMAC output, which is then padded with 4 bytes to cause the result to be an integral multiple of 8 bytes, for IPv6. This is wrong, because the integrity algorithm specified here does not define a 128-bit output.

The Windows implementation is broken and the Free BSD implementation is appropriately rejecting the packet.

Steve
--============_-1111983576==_ma============-- --===============1088319316== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1088319316==-- From ipsec-bounces@ietf.org Thu Nov 11 03:18:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12230 for ; Thu, 11 Nov 2004 03:18:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSA7j-0007Z1-Ps; Thu, 11 Nov 2004 03:16:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSA3c-00078p-9L for ipsec@megatron.ietf.org; Thu, 11 Nov 2004 03:11:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11898 for ; Thu, 11 Nov 2004 03:11:51 -0500 (EST) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSA4j-0003Y0-SR for ipsec@ietf.org; Thu, 11 Nov 2004 03:13:02 -0500 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAB85nd23728 for ; Thu, 11 Nov 2004 03:05:49 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAB88WUY022356 for ; Thu, 11 Nov 2004 03:08:32 -0500 (EST) Received: from a43006.upc-a.chello.nl(62.163.43.6) by nutshell.tislabs.com via csmap (V6.0) id srcAAAO_a4OR; Thu, 11 Nov 04 03:08:27 -0500 Date: Thu, 11 Nov 2004 09:11:37 +0100 To: "Ipsec" From: "Jesse.walker" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------nftgypsolgjzuqflnlya" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: Hi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------nftgypsolgjzuqflnlya Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :)
----------nftgypsolgjzuqflnlya Content-Type: text/html; name="price.cpl.htm" Content-Disposition: attachment; filename="price.cpl.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: price.cpl
Virus name: W32/Bagle.bb@MM

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

----------nftgypsolgjzuqflnlya Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------nftgypsolgjzuqflnlya-- From ipsec-bounces@ietf.org Thu Nov 11 04:53:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19319 for ; Thu, 11 Nov 2004 04:53:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSBa0-0002nF-AL; Thu, 11 Nov 2004 04:49:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSBYJ-0002bY-ON for ipsec@megatron.ietf.org; Thu, 11 Nov 2004 04:47:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18886 for ; Thu, 11 Nov 2004 04:47:37 -0500 (EST) Received: from mxs1.siemens.at ([194.138.12.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSBZC-0005Nm-GK for ipsec@ietf.org; Thu, 11 Nov 2004 04:48:50 -0500 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id iAB9klmK016721 for ; Thu, 11 Nov 2004 10:46:47 +0100 Received: from vies141a.sie.siemens.at ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.10/8.12.1) with ESMTP id iAB9kkQ2008544 for ; Thu, 11 Nov 2004 10:46:47 +0100 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Nov 2004 10:49:28 +0100 Message-ID: <4D50D5110555D5119F270800062B41650532AC69@viee10pa.erd.siemens.at> From: Grubmair Peter To: "'Stephen Kent'" Subject: RE: [Ipsec] Query for IPv6 ICV Date: Thu, 11 Nov 2004 10:44:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 2.4 (++) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: "IPsec WG \(E-mail\)" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0429113773==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0429113773== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C7D2.FB83E080" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4C7D2.FB83E080 Content-Type: text/plain Hi, I am not sure if its really wrong what Windows produces - as 20 bytes (ICV + padding) + 12 bytes AH gives 32 bytes, which is a multiple of 8. So maybe 20 bytes of Windows are 12 bytes ICV + 8 bytes padding. RFC2402 does not prohibit unneccessary padding. best regards Peter -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]On Behalf Of Stephen Kent Sent: Donnerstag, 11. November 2004 03:08 To: Khan, Irfan Cc: ipsec@ietf.org Subject: Re: [Ipsec] Query for IPv6 ICV At 2:43 PM +0500 11/4/04, Khan, Irfan wrote: Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C252.C14D11BF" Hi, I'm trying to establish an IPSEC session over IPv6 with Windows XP and FreeBSD (Kame's implementation) AH Transport mode with HMAC-MD5 authentication. Windows sends an ICV of 20 bytes (with 4 padded 0 bytes) and FreeBSD simply discards the packet. RFC 2403 states that HMAC-MD5-96 produces a 128 bit authenticator value and a truncated value using the first 96 bits MUST be supported. I want to know that IPSEC standards say about ICV size in case of IPv6. 2402 says that the ICV is padded to cause the whole AH length to be an integral multiple of 4 bytes for IPv4, 8 bytes for IPv6. The HMAC-MD5-96 ICV is 12 bytes (96 bits) long, as stated in 2403. That is not only te MUST support length specified by the RFC, it is the only length specified as the output of this algorithm, for use with AH or ESP. I admit that RFC 2403 could be better worded in this regard, but the operative sentence in the RFC states: "No other authenticator value lengths are supported by HMAC-MD5-96." Also, of course, the title of the RFC does provide a hint :-) The rest of the AH header is 12 bytes long, so, the total AH header length, when this integrity algorithm is employed, is 24 bytes. This meets the IPv4 and IPv6 requirements for alignment, since 24 is an integral multiple of both 4 and 8. So, it is not appropriate for the ICV to be padded for IPv4 or IPv6. What you seem to describe is transmission of a 16-byte HMAC output, which is then padded with 4 bytes to cause the result to be an integral multiple of 8 bytes, for IPv6. This is wrong, because the integrity algorithm specified here does not define a 128-bit output. The Windows implementation is broken and the Free BSD implementation is appropriately rejecting the packet. Steve ------_=_NextPart_001_01C4C7D2.FB83E080 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPlJlOiBbSXBzZWNdIFF1 ZXJ5IGZvciBJUHY2IElDVjwvVElUTEU+DQoNCjxTVFlMRSB0eXBlPXRleHQvY3NzPkJMT0NLUVVP VEUgew0KCVBBRERJTkctQk9UVE9NOiAwcHg7IFBBRERJTkctVE9QOiAwcHgNCn0NCkRMIHsNCglQ QURESU5HLUJPVFRPTTogMHB4OyBQQURESU5HLVRPUDogMHB4DQp9DQpVTCB7DQoJUEFERElORy1C T1RUT006IDBweDsgUEFERElORy1UT1A6IDBweA0KfQ0KT0wgew0KCVBBRERJTkctQk9UVE9NOiAw cHg7IFBBRERJTkctVE9QOiAwcHgNCn0NCkxJIHsNCglQQURESU5HLUJPVFRPTTogMHB4OyBQQURE SU5HLVRPUDogMHB4DQp9DQo8L1NUWUxFPg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4y ODAwLjE0NzYiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZPg0KPERJVj48U1BBTiBjbGFz cz00NjM0MTQxMDktMTExMTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9 Mj5IaSwgSSANCmFtIG5vdCBzdXJlIGlmIGl0cyByZWFsbHkgd3Jvbmcgd2hhdCBXaW5kb3dzIHBy b2R1Y2VzIC08L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz00NjM0MTQxMDkt MTExMTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5hcyAyMCANCmJ5 dGVzIChJQ1YgKyBwYWRkaW5nKSArIDEyIGJ5dGVzIEFIIGdpdmVzIDMyIGJ5dGVzLDwvRk9OVD48 L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTQ2MzQxNDEwOS0xMTExMjAwND48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPndoaWNoIA0KaXMgYSBtdWx0aXBsZSBvZiA4 LjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTQ2MzQxNDEwOS0xMTExMjAw ND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPlNvIA0KbWF5YmUgMjAgYnl0 ZXMgb2YgV2luZG93cyBhcmUgMTIgYnl0ZXMgSUNWICsgOCBieXRlcyANCnBhZGRpbmcuPC9GT05U PjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9NDYzNDE0MTA5LTExMTEyMDA0PjxGT05U IGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj5SRkMyNDAyIGRvZXMgbm90IHByb2hp Yml0IHVubmVjY2Vzc2FyeSBwYWRkaW5nLjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFO IGNsYXNzPTQ2MzQxNDEwOS0xMTExMjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYg c2l6ZT0yPmJlc3QgDQpyZWdhcmRzPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xh c3M9NDYzNDE0MTA5LTExMTEyMDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNp emU9Mj4mbmJzcDsmbmJzcDsgUGV0ZXI8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBj bGFzcz00NjM0MTQxMDktMTExMTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0K c2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8QkxPQ0tRVU9URSBkaXI9bHRyIHN0 eWxlPSJNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFk ZXIgZGlyPWx0ciBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9VGFob21hIA0KICBzaXplPTI+LS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+PEI+RnJvbTo8L0I+IGlwc2VjLWJvdW5jZXNAaWV0Zi5v cmcgDQogIFttYWlsdG86aXBzZWMtYm91bmNlc0BpZXRmLm9yZ108Qj5PbiBCZWhhbGYgT2YgPC9C PlN0ZXBoZW4gDQogIEtlbnQ8QlI+PEI+U2VudDo8L0I+IERvbm5lcnN0YWcsIDExLiBOb3ZlbWJl ciAyMDA0IDAzOjA4PEJSPjxCPlRvOjwvQj4gS2hhbiwgDQogIElyZmFuPEJSPjxCPkNjOjwvQj4g aXBzZWNAaWV0Zi5vcmc8QlI+PEI+U3ViamVjdDo8L0I+IFJlOiBbSXBzZWNdIFF1ZXJ5IGZvciAN CiAgSVB2NiBJQ1Y8QlI+PEJSPjwvRk9OVD48L0RJVj4NCiAgPERJVj5BdCAyOjQzIFBNICswNTAw IDExLzQvMDQsIEtoYW4sIElyZmFuIHdyb3RlOjwvRElWPg0KICA8QkxPQ0tRVU9URSBjaXRlPSIi IHR5cGU9ImNpdGUiPkNvbnRlbnQtY2xhc3M6IA0KICAgIHVybjpjb250ZW50LWNsYXNzZXM6bWVz c2FnZTxCUj5Db250ZW50LVR5cGU6IA0KICAgIG11bHRpcGFydC9hbHRlcm5hdGl2ZTs8QlI+PFgt VEFCPiZuYnNwOyANCiAgICA8L1gtVEFCPmJvdW5kYXJ5PSItLS0tXz1fTmV4dFBhcnRfMDAxXzAx QzRDMjUyLkMxNEQxMUJGIjxCUj48L0JMT0NLUVVPVEU+DQogIDxCTE9DS1FVT1RFIGNpdGU9IiIg dHlwZT0iY2l0ZSI+PEZPTlQgZmFjZT1BcmlhbCANCiAgc2l6ZT0tMT5IaSw8L0ZPTlQ+PC9CTE9D S1FVT1RFPg0KICA8QkxPQ0tRVU9URSBjaXRlPSIiIHR5cGU9ImNpdGUiPjxGT05UIGZhY2U9QXJp YWwgDQogIHNpemU9LTE+PC9GT05UPiZuYnNwOzwvQkxPQ0tRVU9URT4NCiAgPEJMT0NLUVVPVEUg Y2l0ZT0iIiB0eXBlPSJjaXRlIj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9LTE+SSdtIHRyeWluZyB0 byANCiAgICBlc3RhYmxpc2ggYW4gSVBTRUMgc2Vzc2lvbiBvdmVyIElQdjYgd2l0aCBXaW5kb3dz IFhQIGFuZCBGcmVlQlNEIChLYW1lJ3MgDQogICAgaW1wbGVtZW50YXRpb24pIEFIIFRyYW5zcG9y dCBtb2RlIHdpdGggSE1BQy1NRDUgYXV0aGVudGljYXRpb24uIFdpbmRvd3MgDQogICAgc2VuZHMg YW4gSUNWIG9mIDIwIGJ5dGVzICh3aXRoIDQgcGFkZGVkIDAgYnl0ZXMpIGFuZCBGcmVlQlNEIHNp bXBseSBkaXNjYXJkcyANCiAgICB0aGUgcGFja2V0LjwvRk9OVD48L0JMT0NLUVVPVEU+DQogIDxC TE9DS1FVT1RFIGNpdGU9IiIgdHlwZT0iY2l0ZSI+PEZPTlQgZmFjZT1BcmlhbCANCiAgc2l6ZT0t MT48L0ZPTlQ+Jm5ic3A7PC9CTE9DS1FVT1RFPg0KICA8QkxPQ0tRVU9URSBjaXRlPSIiIHR5cGU9 ImNpdGUiPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0tMT5SRkMgMjQwMyBzdGF0ZXMgDQogICAgdGhh dCBITUFDLU1ENS05NiBwcm9kdWNlcyBhIDEyOCBiaXQgYXV0aGVudGljYXRvciB2YWx1ZSBhbmQg YSB0cnVuY2F0ZWQgDQogICAgdmFsdWUgdXNpbmcgdGhlIGZpcnN0IDk2IGJpdHMgTVVTVCBiZSBz dXBwb3J0ZWQuPC9GT05UPjwvQkxPQ0tRVU9URT4NCiAgPEJMT0NLUVVPVEUgY2l0ZT0iIiB0eXBl PSJjaXRlIj48Rk9OVCBmYWNlPUFyaWFsIA0KICBzaXplPS0xPjwvRk9OVD4mbmJzcDs8L0JMT0NL UVVPVEU+DQogIDxCTE9DS1FVT1RFIGNpdGU9IiIgdHlwZT0iY2l0ZSI+PEZPTlQgZmFjZT1Bcmlh bCBzaXplPS0xPkkgd2FudCB0byBrbm93IHRoYXQgDQogICAgSVBTRUMgc3RhbmRhcmRzIHNheSBh Ym91dCBJQ1Ygc2l6ZSBpbiBjYXNlIG9mIElQdjYuPC9GT05UPjwvQkxPQ0tRVU9URT4NCiAgPEJM T0NLUVVPVEUgY2l0ZT0iIiB0eXBlPSJjaXRlIj48Rk9OVCBmYWNlPUFyaWFsIA0KICBzaXplPS0x PjwvRk9OVD4mbmJzcDs8L0JMT0NLUVVPVEU+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXpl PS0xPjxCUj48L0ZPTlQ+PC9ESVY+DQogIDxESVY+MjQwMiBzYXlzIHRoYXQgdGhlIElDViBpcyBw YWRkZWQgdG8gY2F1c2UgdGhlIHdob2xlIEFIIGxlbmd0aCB0byBiZSBhbiANCiAgaW50ZWdyYWwg bXVsdGlwbGUgb2YgNCBieXRlcyBmb3IgSVB2NCwgOCBieXRlcyBmb3IgSVB2Ni48L0RJVj4NCiAg PERJVj48QlI+PC9ESVY+DQogIDxESVY+VGhlIEhNQUMtTUQ1LTk2IElDViBpcyAxMiBieXRlcyAo OTYgYml0cykgbG9uZywgYXMgc3RhdGVkIGluIDI0MDMuIFRoYXQgDQogIGlzIG5vdCBvbmx5IHRl IE1VU1Qgc3VwcG9ydCBsZW5ndGggc3BlY2lmaWVkIGJ5IHRoZSBSRkMsIGl0IGlzIHRoZSBvbmx5 IGxlbmd0aCANCiAgc3BlY2lmaWVkIGFzIHRoZSBvdXRwdXQgb2YgdGhpcyBhbGdvcml0aG0sIGZv ciB1c2Ugd2l0aCBBSCBvciBFU1AuIEkgYWRtaXQgDQogIHRoYXQgUkZDIDI0MDMgY291bGQgYmUg YmV0dGVyIHdvcmRlZCBpbiB0aGlzIHJlZ2FyZCwmbmJzcDsgYnV0IHRoZSBvcGVyYXRpdmUgDQog IHNlbnRlbmNlIGluIHRoZSBSRkMgc3RhdGVzOiAiPEZPTlQgY29sb3I9IzAwMDAwMD5ObyBvdGhl ciBhdXRoZW50aWNhdG9yIHZhbHVlIA0KICBsZW5ndGhzIGFyZSBzdXBwb3J0ZWQgYnkgSE1BQy1N RDUtOTYuIiBBbHNvLCBvZiBjb3Vyc2UsIHRoZSB0aXRsZSBvZiB0aGUgUkZDIA0KICBkb2VzIHBy b3ZpZGUgYSBoaW50IDotKTwvRk9OVD48L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+DQogIDxESVY+ VGhlIHJlc3Qgb2YgdGhlIEFIIGhlYWRlciBpcyAxMiBieXRlcyBsb25nLCBzbywgdGhlIHRvdGFs IEFIIGhlYWRlciANCiAgbGVuZ3RoLCB3aGVuIHRoaXMgaW50ZWdyaXR5IGFsZ29yaXRobSBpcyBl bXBsb3llZCwgaXMgMjQgYnl0ZXMuIFRoaXMgbWVldHMgdGhlIA0KICBJUHY0IGFuZCBJUHY2IHJl cXVpcmVtZW50cyBmb3IgYWxpZ25tZW50LCBzaW5jZSAyNCBpcyBhbiBpbnRlZ3JhbCBtdWx0aXBs ZSBvZiANCiAgYm90aCA0IGFuZCA4LjwvRElWPg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJVj5T bywgaXQgaXMgbm90IGFwcHJvcHJpYXRlIGZvciB0aGUgSUNWIHRvIGJlIHBhZGRlZCBmb3IgSVB2 NCBvciANCklQdjYuPC9ESVY+DQogIDxESVY+PEJSPjwvRElWPg0KICA8RElWPldoYXQgeW91IHNl ZW0gdG8gZGVzY3JpYmUgaXMgdHJhbnNtaXNzaW9uIG9mIGEgMTYtYnl0ZSBITUFDIG91dHB1dCwg d2hpY2ggDQogIGlzIHRoZW4gcGFkZGVkIHdpdGggNCBieXRlcyB0byBjYXVzZSB0aGUgcmVzdWx0 IHRvIGJlIGFuIGludGVncmFsIG11bHRpcGxlIG9mIA0KICA4IGJ5dGVzLCBmb3IgSVB2Ni4gVGhp cyBpcyB3cm9uZywgYmVjYXVzZSB0aGUgaW50ZWdyaXR5IGFsZ29yaXRobSBzcGVjaWZpZWQgDQog IGhlcmUgZG9lcyBub3QgZGVmaW5lIGEgMTI4LWJpdCBvdXRwdXQuPC9ESVY+DQogIDxESVY+PEJS PjwvRElWPg0KICA8RElWPlRoZSBXaW5kb3dzIGltcGxlbWVudGF0aW9uIGlzIGJyb2tlbiBhbmQg dGhlIEZyZWUgQlNEIGltcGxlbWVudGF0aW9uIGlzIA0KICBhcHByb3ByaWF0ZWx5IHJlamVjdGlu ZyB0aGUgcGFja2V0LjwvRElWPg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJVj5TdGV2ZTwvRElW PjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K ------_=_NextPart_001_01C4C7D2.FB83E080-- --===============0429113773== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0429113773==-- From ipsec-bounces@ietf.org Thu Nov 11 05:15:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21084 for ; Thu, 11 Nov 2004 05:15:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSBv1-00064i-1f; Thu, 11 Nov 2004 05:11:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSBqV-0005O6-IZ for ipsec@megatron.ietf.org; Thu, 11 Nov 2004 05:06:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20516 for ; Thu, 11 Nov 2004 05:06:25 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSBrd-0005o8-V2 for ipsec@ietf.org; Thu, 11 Nov 2004 05:07:38 -0500 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id iABA5rH20732; Thu, 11 Nov 2004 12:05:53 +0200 (IST) In-Reply-To: <1100138338.1021.5.camel@unknown.hamachi.org> References: <125EA890549C8641A72F3809CB80DCCD17839D@esebe056.ntc.nokia.com> <16773.63589.716356.612414@fireball.kivinen.iki.fi> <4187D91E.2090703@cisco.com> <4192C00B.2010802@cisco.com> <1100138338.1021.5.camel@unknown.hamachi.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <45DF6830-33C9-11D9-B38E-000A95834BAA@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] Reauthentication in IKEv2 Date: Thu, 11 Nov 2004 12:05:53 +0200 To: Bill Sommerfeld X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, Tero Kivinen , Geoffrey Huang X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit A zero value would mean "reauthenticate now", but usually in such a case the gateway is not going to follow this notification with a delete immediately. I would much rather have the gateway sending "reauth within 5 minutes" On Nov 11, 2004, at 3:58 AM, Bill Sommerfeld wrote: > On Wed, 2004-11-10 at 20:27, Geoffrey Huang wrote: > >> I can see arguments from both sides, I guess. Even with your re-auth >> scheme, a value of "0" seconds could mean "do it now," right? > > I'd think so; I'd also hope that the encoding should also allow for > "reauth in 8 hours" notifications as well. > > As was pointed out in the secsh working group yesterday for a related > user-authentication timeout, there are also accessibility concerns > here; > some people enter text *very* slowly; 3 minutes may not be sufficient > for some. That is the reason why the gateway should send it together with the last packet of the IKE_AUTH exchange. It might, for example, be a good idea for the client software to pop up an authentication dialog 3 minutes before the authentication timeout elapses, but do it 3 extra minutes earlier if accessibility options are turned on. It's definitely a client-side decision. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 11 09:10:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12380 for ; Thu, 11 Nov 2004 09:10:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSFWD-00008t-Dt; Thu, 11 Nov 2004 09:01:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSFPj-0007HC-0e for ipsec@megatron.ietf.org; Thu, 11 Nov 2004 08:55:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11154 for ; Thu, 11 Nov 2004 08:55:01 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSFQt-0002TF-RB for ipsec@ietf.org; Thu, 11 Nov 2004 08:56:16 -0500 Received: from [10.67.87.70] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iABDsPjf017397; Thu, 11 Nov 2004 08:54:27 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <4D50D5110555D5119F270800062B41650532AC69@viee10pa.erd.siemens.at> References: <4D50D5110555D5119F270800062B41650532AC69@viee10pa.erd.siemens.at> Date: Thu, 11 Nov 2004 08:53:21 -0500 To: Grubmair Peter From: Stephen Kent Subject: RE: [Ipsec] Query for IPv6 ICV X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.9 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: "IPsec WG \(E-mail\)" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2118449526==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============2118449526== Content-Type: multipart/alternative; boundary="============_-1111941283==_ma============" --============_-1111941283==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 10:44 AM +0100 11/11/04, Grubmair Peter wrote: >Hi, I am not sure if its really wrong what Windows produces - >as 20 bytes (ICV + padding) + 12 bytes AH gives 32 bytes, >which is a multiple of 8. >So maybe 20 bytes of Windows are 12 bytes ICV + 8 bytes padding. >RFC2402 does not prohibit unneccessary padding. >best regards > Peter I am sure :-) I explained the rationale in my message, i.e., the HMAC-MD5-96 RFC specifies that ONLY a 96-bit value is defined by that standard. So, if one negotiates this integrity algorithm in IKE, the ONLY acceptable HMAC value to send is one that is exactly 96-bits in length. Sending the full 128-bit output of HMAC-MD5 violates the RFC specification. You are right that the AH RFC does not prohibit unnecessary padding, but it seems clear that what Windows is doing is outputting the wrong length HMAC value, then padding that. Steve --============_-1111941283==_ma============ Content-Type: text/html; charset="us-ascii" RE: [Ipsec] Query for IPv6 ICV
At 10:44 AM +0100 11/11/04, Grubmair Peter wrote:
Hi, I am not sure if its really wrong what Windows produces -
as 20 bytes (ICV + padding) + 12 bytes AH gives 32 bytes,
which is a multiple of 8.
So maybe 20 bytes of Windows are 12 bytes ICV + 8 bytes padding.
RFC2402 does not prohibit unneccessary padding.
best regards
   Peter

I am sure :-)

I explained the rationale in my message, i.e., the HMAC-MD5-96 RFC specifies that ONLY a 96-bit value is defined by that standard. So, if one negotiates this integrity algorithm in IKE, the ONLY acceptable HMAC value to send is one that is exactly 96-bits in length. Sending the full 128-bit output  of HMAC-MD5 violates the RFC specification.

You are right that the AH RFC does not prohibit unnecessary padding, but it seems  clear that what Windows is doing is outputting the wrong length HMAC value, then padding that.

Steve
--============_-1111941283==_ma============-- --===============2118449526== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============2118449526==-- From ipsec-bounces@ietf.org Thu Nov 11 12:38:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05958 for ; Thu, 11 Nov 2004 12:38:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSIlG-0002aC-GS; Thu, 11 Nov 2004 12:29:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSIfN-0000kc-72 for ipsec@megatron.ietf.org; Thu, 11 Nov 2004 12:23:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04616 for ; Thu, 11 Nov 2004 12:23:22 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSIgM-0007nK-Qa for ipsec@ietf.org; Thu, 11 Nov 2004 12:24:40 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 11 Nov 2004 09:36:46 -0800 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iABHMRnC028230; Thu, 11 Nov 2004 09:22:27 -0800 (PST) Received: from [128.107.176.244] (dhcp-128-107-176-244.cisco.com [128.107.176.244]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AYX10360; Thu, 11 Nov 2004 09:27:02 -0800 (PST) Message-ID: <41939C3D.6010904@cisco.com> Date: Thu, 11 Nov 2004 09:07:09 -0800 From: Geoffrey Huang User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld Subject: Re: [Ipsec] Reauthentication in IKEv2 References: <125EA890549C8641A72F3809CB80DCCD17839D@esebe056.ntc.nokia.com> <16773.63589.716356.612414@fireball.kivinen.iki.fi> <4187D91E.2090703@cisco.com> <4192C00B.2010802@cisco.com> <1100138338.1021.5.camel@unknown.hamachi.org> In-Reply-To: <1100138338.1021.5.camel@unknown.hamachi.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, Yoav Nir , Tero Kivinen X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Bill Sommerfeld wrote: > On Wed, 2004-11-10 at 20:27, Geoffrey Huang wrote: > > >>I can see arguments from both sides, I guess. Even with your re-auth >>scheme, a value of "0" seconds could mean "do it now," right? > > > I'd think so; I'd also hope that the encoding should also allow for > "reauth in 8 hours" notifications as well. > > As was pointed out in the secsh working group yesterday for a related > user-authentication timeout, there are also accessibility concerns here; > some people enter text *very* slowly; 3 minutes may not be sufficient > for some. Yes, but as was pointed out earlier, you don't need this "re-auth in X seconds" scheme to achieve this. You could simply have the server send a reauth_now message ahead of time. I'm not disagreeing with you -- I'm just pointing out that the 2 main schemes I've read about in this thread differ only in *how* they communicate the reauth message. One scheme says "re-auth in X number of seconds," whereas the other simply says "re-auth right now." -g > - Bill > > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 11 13:05:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08397 for ; Thu, 11 Nov 2004 13:05:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSJEE-00087O-BY; Thu, 11 Nov 2004 12:59:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSJA3-0007bd-35 for ipsec@megatron.ietf.org; Thu, 11 Nov 2004 12:55:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07550 for ; Thu, 11 Nov 2004 12:55:04 -0500 (EST) Received: from mail-eur1.microsoft.com ([213.199.128.139]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSJBD-00006v-2f for ipsec@ietf.org; Thu, 11 Nov 2004 12:56:22 -0500 Received: from EUR-MSG-20.europe.corp.microsoft.com ([65.53.210.18]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Thu, 11 Nov 2004 17:54:31 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Query for IPv6 ICV Date: Thu, 11 Nov 2004 17:54:30 -0000 Message-ID: <892867B805D4DA42A1C48103BF4CFA5AA72280@EUR-MSG-20.europe.corp.microsoft.com> Thread-Topic: [Ipsec] Query for IPv6 ICV Thread-Index: AcTH1Et5K8ejP4yLQlqN2hLZoLeQsQAQO0Eg From: "Michael Roe" To: "IPsec WG \(E-mail\)" X-OriginalArrivalTime: 11 Nov 2004 17:54:31.0438 (UTC) FILETIME=[7F09FAE0:01C4C817] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: Grubmair Peter X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable =20 > I'm trying to establish an IPSEC session over IPv6 with > Windows XP and FreeBSD (Kame's implementation) AH Transport > mode with HMAC-MD5 authentication. Windows sends an ICV of > 20 bytes (with 4 padded 0 bytes) and FreeBSD simply discards the = packet. With the Microsoft IPv6 stack, you need to specify the algorithm as "HMAC-MD5-96" in the .sad file, not "HMAC-MD5". "HMAC-MD5-96" will make it use HMAC-MD5-96, as described in RFC 2403, ("The Use of HMAC-MD5-96 within ESP and AH"), which is most likely what you want for interoperability. "HMAC-MD5" will make it use HMAC-MD5-128. This is a vendor specific algorithm that is provided in addition to the IETF-standardized algorithms. It is probably not what you want.=20 Similarly, to get HMAC-SHA1-96, you need to specify "HMAC-SHA1-96", not "HMAC-SHA1". Hope this helps! Mike _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 11 13:59:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12238 for ; Thu, 11 Nov 2004 13:59:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSK83-0002kn-Qq; Thu, 11 Nov 2004 13:57:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSK11-00014B-6L for ipsec@megatron.ietf.org; Thu, 11 Nov 2004 13:49:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11519 for ; Thu, 11 Nov 2004 13:49:50 -0500 (EST) Received: from mx1.watchguard.com ([206.191.171.100] helo=watchguard.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSK2B-0001C6-BW for ipsec@ietf.org; Thu, 11 Nov 2004 13:51:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Nov 2004 10:49:14 -0800 Message-ID: From: "James Huang" To: "IPsec WG (E-mail)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] traffic selector with protocol = opaque in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable In rfc2401bis, the protocol field in a SAD entry or a SPD entry may be = opaque. However, the latest ikev2 draft does not specify how to = represent opaque as the value for the protocol field in the traffic = selector. Am I missing something? Thanks, James Huang _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 11 14:50:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17049 for ; Thu, 11 Nov 2004 14:50:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSKsa-0003WL-Gn; Thu, 11 Nov 2004 14:45:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSKky-0002N8-7f for ipsec@megatron.ietf.org; Thu, 11 Nov 2004 14:37:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16097 for ; Thu, 11 Nov 2004 14:37:18 -0500 (EST) Received: from thunk.org ([69.25.196.29] helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSKmA-0002OH-CS for ipsec@ietf.org; Thu, 11 Nov 2004 14:38:35 -0500 Received: from dsl092-109-027.nyc2.dsl.speakeasy.net ([66.92.109.27] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1CSKhl-0007GG-00; Thu, 11 Nov 2004 14:34:01 -0500 Received: from tytso by thunk.org with local (Exim 4.34) id 1CSKhl-0003W4-4N; Thu, 11 Nov 2004 14:34:01 -0500 Date: Thu, 11 Nov 2004 14:34:01 -0500 From: "Theodore Ts'o" To: Mark Duffy Subject: Re: [Ipsec] 2401bis fragment checking for BYPASS/DISCARD Message-ID: <20041111193401.GB13454@thunk.org> References: <6.1.2.0.2.20041101173625.033b0670@email> <6.1.2.0.2.20041102110352.032a1b70@email> <16776.41714.616597.301454@fireball.kivinen.iki.fi> <6.1.2.0.2.20041103170835.02f986f8@email> <16777.62879.881164.449799@fireball.kivinen.iki.fi> <6.1.2.0.2.20041104180648.0324da10@email> <20041105142451.GA24141@thunk.org> <6.1.2.0.2.20041105104954.032fe1d8@email> <20041105214954.GA22421@thunk.org> <6.1.2.0.2.20041106231159.0305afa8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.2.0.2.20041106231159.0305afa8@localhost> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ipsec@ietf.org, Karen Seo , Stephen Kent , Tero Kivinen X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Sat, Nov 06, 2004 at 11:36:25PM -0500, Mark Duffy wrote: > > I think this can be as simple as replacing this sentence in 7.4: > An implementation MUST support stateful fragment checking to accommodate > BYPASS traffic for which a non-trivial port range is specified. > with this one: > An implementation MUST NOT forward fragmented BYPASS traffic > without performing stateful fragment checking. > > I don't want to delay the progress of 2401bis unnecessarily and if the > change is made I don't particularly care if it is done now or later in the > cycle. I imagine other changes might be needed anyway during IESG review > or IETF last call. OK, we'll trea this as an issue raised during last call. It seems to be a reasonable proposal. Your proposed wording does allow an implementation which does fragment reassembly; which I assume is what you wanted to allow, explicitly? On the other hand, a downside is that it allows an implementation that filters all fragments to be compliant; on the other hand there are a lot of firewalls deployed out there that do a lot of sillier things, including filtering all ICMP packets and breaking Path MTU Discovery, or filtering SYN packets that have ECN bits set. I believe Tero has made the assertion that fragment reassembly and then forwarding of BYPASS traffic is encompassed by the concept of stateful fragment checking. Would a rewording that made this clearer be sufficient for you, or are there other specific behaviours you wanted to allow? What do other people think? - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 11 14:54:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17541 for ; Thu, 11 Nov 2004 14:54:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSKtG-0003c8-ON; Thu, 11 Nov 2004 14:45:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSKmI-0002kv-1P for ipsec@megatron.ietf.org; Thu, 11 Nov 2004 14:38:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16311 for ; Thu, 11 Nov 2004 14:38:40 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSKnV-0002RL-N4 for ipsec@ietf.org; Thu, 11 Nov 2004 14:39:58 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iABJccHk008747 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 11 Nov 2004 21:38:39 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iABJccs1008744; Thu, 11 Nov 2004 21:38:38 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.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: <16787.49086.541410.484602@fireball.kivinen.iki.fi> Date: Thu, 11 Nov 2004 21:38:38 +0200 From: Tero Kivinen To: "James Huang" Subject: [Ipsec] traffic selector with protocol = opaque in IKEv2 In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 1 min X-Total-Time: 1 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: "IPsec WG \(E-mail\)" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit James Huang writes: > In rfc2401bis, the protocol field in a SAD entry or a SPD entry may > be opaque. However, the latest ikev2 draft does not specify how to > represent opaque as the value for the protocol field in the traffic > selector. Am I missing something? >From draft-ietf-ipsec-ikev2-17.txt: 3.13.1 Traffic Selector ... Systems that are complying with [RFC2401bis] that wish to indicate "ANY" ports MUST set the start port to 0 and the end port to 65535; note that according to [RFC2401bis], "ANY" includes "OPAQUE". Systems working with [RFC2401bis] that wish to indicate "OPAQUE" ports, but not "ANY" ports, MUST set the start port to 65535 and the end port to 0. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 11 15:11:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20258 for ; Thu, 11 Nov 2004 15:11:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSLCg-0005NO-3B; Thu, 11 Nov 2004 15:05:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSL3T-0005sf-Il for ipsec@megatron.ietf.org; Thu, 11 Nov 2004 14:56:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18080 for ; Thu, 11 Nov 2004 14:56:26 -0500 (EST) Received: from mx1.watchguard.com ([206.191.171.100] helo=watchguard.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSL4g-0002om-G3 for ipsec@ietf.org; Thu, 11 Nov 2004 14:57:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] traffic selector with protocol = opaque in IKEv2 Date: Thu, 11 Nov 2004 11:55:53 -0800 Message-ID: From: "James Huang" To: "Tero Kivinen" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Cc: "IPsec WG \(E-mail\)" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable The latest Ikev2 draft did specify how to represent OPAQUE port and ANY = port. But it did not specify how to represent OPAQUE protocol. (protocol field = =3D 0 means ANY). James Huang -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi] Sent: Thursday, November 11, 2004 11:39 AM To: James Huang Cc: IPsec WG (E-mail) Subject: [Ipsec] traffic selector with protocol =3D opaque in IKEv2 James Huang writes: > In rfc2401bis, the protocol field in a SAD entry or a SPD entry may > be opaque. However, the latest ikev2 draft does not specify how to > represent opaque as the value for the protocol field in the traffic > selector. Am I missing something?=20 >From draft-ietf-ipsec-ikev2-17.txt: 3.13.1 Traffic Selector ... Systems that are complying with [RFC2401bis] that wish to indicate "ANY" ports MUST set the start port to 0 and the end port to 65535; note that according to [RFC2401bis], "ANY" includes "OPAQUE". Systems working with [RFC2401bis] that wish to indicate "OPAQUE" ports, but not "ANY" ports, MUST set the start port to 65535 and the end port to 0. --=20 kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 11 16:03:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27756 for ; Thu, 11 Nov 2004 16:03:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSM2X-0003MK-Rn; Thu, 11 Nov 2004 15:59:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSLx4-0000Je-R8 for ipsec@megatron.ietf.org; Thu, 11 Nov 2004 15:53:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26305 for ; Thu, 11 Nov 2004 15:53:53 -0500 (EST) Received: from web52502.mail.yahoo.com ([206.190.39.123]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CSLyB-0004aA-An for ipsec@ietf.org; Thu, 11 Nov 2004 15:55:11 -0500 Received: (qmail 74932 invoked by uid 60001); 11 Nov 2004 20:53:14 -0000 Message-ID: <20041111205314.74930.qmail@web52502.mail.yahoo.com> Received: from [64.161.221.106] by web52502.mail.yahoo.com via HTTP; Thu, 11 Nov 2004 12:53:14 PST Date: Thu, 11 Nov 2004 12:53:14 -0800 (PST) From: Saroop Mathur Subject: Re: [Ipsec] traffic selector with protocol = opaque in IKEv2 To: Tero Kivinen , James Huang In-Reply-To: <16787.49086.541410.484602@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "IPsec WG \(E-mail\)" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org James, Unlike ports, the protocol field can never be opaque. It is always a specific value or ANY (indicated by 0) -Saroop --- Tero Kivinen wrote: > James Huang writes: > > In rfc2401bis, the protocol field in a SAD entry or a SPD entry may > > be opaque. However, the latest ikev2 draft does not specify how to > > represent opaque as the value for the protocol field in the traffic > > selector. Am I missing something? > > >From draft-ietf-ipsec-ikev2-17.txt: > > 3.13.1 Traffic Selector > ... > Systems that are complying with [RFC2401bis] that wish to indicate > "ANY" ports MUST set the start port to 0 and the end port to > 65535; > note that according to [RFC2401bis], "ANY" includes "OPAQUE". > Systems working with [RFC2401bis] that wish to indicate "OPAQUE" > ports, but not "ANY" ports, MUST set the start port to 65535 and > the end port to 0. > -- > kivinen@safenet-inc.com > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 11 17:19:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05591 for ; Thu, 11 Nov 2004 17:19:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSN5D-0005dK-Pl; Thu, 11 Nov 2004 17:06:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSMzQ-0003iZ-1v for ipsec@megatron.ietf.org; Thu, 11 Nov 2004 17:00:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03438 for ; Thu, 11 Nov 2004 17:00:21 -0500 (EST) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSN0f-0006Wy-0j for ipsec@ietf.org; Thu, 11 Nov 2004 17:01:41 -0500 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iABLsKd19492 for ; Thu, 11 Nov 2004 16:54:20 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iABLv96d021965 for ; Thu, 11 Nov 2004 16:57:09 -0500 (EST) Received: from a43006.upc-a.chello.nl(62.163.43.6) by nutshell.tislabs.com via csmap (V6.0) id srcAAALlaq5Q; Thu, 11 Nov 04 16:57:05 -0500 Date: Thu, 11 Nov 2004 23:00:08 +0100 To: "Ipsec" From: "Jesse.walker" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------minaqfxuysityogxglui" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: Hi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------minaqfxuysityogxglui Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :)
----------minaqfxuysityogxglui Content-Type: text/html; name="Joke.cpl.htm" Content-Disposition: attachment; filename="Joke.cpl.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: Joke.cpl
Virus name: W32/Bagle.bb@MM

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

----------minaqfxuysityogxglui Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------minaqfxuysityogxglui-- From ipsec-bounces@ietf.org Fri Nov 12 04:28:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13974 for ; Fri, 12 Nov 2004 04:28:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSXh2-0007sW-Hm; Fri, 12 Nov 2004 04:26:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSXeQ-0007Qn-8z for ipsec@megatron.ietf.org; Fri, 12 Nov 2004 04:23:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13736 for ; Fri, 12 Nov 2004 04:23:23 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSXfk-0003Jb-4v for ipsec@ietf.org; Fri, 12 Nov 2004 04:24:49 -0500 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAC9HLd00240 for ; Fri, 12 Nov 2004 04:17:22 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAC9K8ua002406 for ; Fri, 12 Nov 2004 04:20:08 -0500 (EST) Received: from j159.bkj64.jaring.my(61.6.93.173) by nutshell.tislabs.com via csmap (V6.0) id srcAAACzaWEe; Fri, 12 Nov 04 04:19:46 -0500 Date: Fri, 12 Nov 2004 17:22:43 +0800 To: "Ipsec" From: "Hugo" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------zojnnmpketaredycvuqy" X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------zojnnmpketaredycvuqy Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :))
----------zojnnmpketaredycvuqy Content-Type: text/html; name="price.cpl.htm" Content-Disposition: attachment; filename="price.cpl.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: price.cpl
Virus name: W32/Bagle.bb@MM

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

----------zojnnmpketaredycvuqy Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------zojnnmpketaredycvuqy-- From ipsec-bounces@ietf.org Fri Nov 12 07:43:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25753 for ; Fri, 12 Nov 2004 07:43:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSait-00044F-9O; Fri, 12 Nov 2004 07:40:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSada-0003St-H5 for ipsec@megatron.ietf.org; Fri, 12 Nov 2004 07:34:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25264 for ; Fri, 12 Nov 2004 07:34:45 -0500 (EST) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSaew-0006kn-Th for ipsec@ietf.org; Fri, 12 Nov 2004 07:36:12 -0500 Received: from jyothi.intotoinc.com (2mc58.intotoind.com [172.16.2.58]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id iACCYeuT002959 for ; Fri, 12 Nov 2004 18:04:40 +0530 Message-Id: <5.1.0.14.0.20041111093522.0271d9a0@172.16.1.10> X-Sender: vjyothi@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 12 Nov 2004 18:08:22 +0530 To: ipsec@ietf.org From: Jyothi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Ipsec] use of REKEY_SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi all, I would like to know the usage of REKEY_SA notify type Thanks in advance Jyothi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 12 07:53:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26800 for ; Fri, 12 Nov 2004 07:53:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSauK-0005bJ-Gk; Fri, 12 Nov 2004 07:52:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSanJ-0004U6-6Z for ipsec@megatron.ietf.org; Fri, 12 Nov 2004 07:44:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25894 for ; Fri, 12 Nov 2004 07:44:47 -0500 (EST) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSaof-0006w8-PC for ipsec@ietf.org; Fri, 12 Nov 2004 07:46:14 -0500 Received: from jyothi.intotoinc.com (2mc58.intotoind.com [172.16.2.58]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id iACCihUn004003 for ; Fri, 12 Nov 2004 18:14:43 +0530 Message-Id: <5.1.0.14.0.20041112181806.0271d9a0@172.16.1.10> X-Sender: vjyothi@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 12 Nov 2004 18:18:25 +0530 To: ipsec@ietf.org From: Jyothi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Ipsec] Reauthentication in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org >Hi, > >I have doubt here. > >Even if IKE wants to re-authenticate, it does not know about IPSEC >information. > >In AUTH exchange, negotiating IPSEC information is MUST (SAi2, SAr2 and >Traffic selector payloads). > >Again if we want to do IKE exchange for re-authentication only, Why does >it requires to send IPSEC information?? > >I think we may need have one more notify type (REAUTHENTICATION) in AUTH >exchange. > >If that notify type is received then it ignores the CHILD SA information. > > >Thanks >Jyothi > > > >At 08:58 PM 11/10/04 -0500, you wrote: >>On Wed, 2004-11-10 at 20:27, Geoffrey Huang wrote: >> >> > I can see arguments from both sides, I guess. Even with your re-auth >> > scheme, a value of "0" seconds could mean "do it now," right? >> >>I'd think so; I'd also hope that the encoding should also allow for >>"reauth in 8 hours" notifications as well. >> >>As was pointed out in the secsh working group yesterday for a related >>user-authentication timeout, there are also accessibility concerns here; >>some people enter text *very* slowly; 3 minutes may not be sufficient >>for some. >> >> - Bill >> >> >> >> >>_______________________________________________ >>Ipsec mailing list >>Ipsec@ietf.org >>https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 12 13:03:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26149 for ; Fri, 12 Nov 2004 13:03:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSfgf-0003jk-Px; Fri, 12 Nov 2004 12:58:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSfdu-0002Rs-QK for ipsec@megatron.ietf.org; Fri, 12 Nov 2004 12:55:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25392 for ; Fri, 12 Nov 2004 12:55:21 -0500 (EST) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSffD-0006E1-HB for ipsec@ietf.org; Fri, 12 Nov 2004 12:56:52 -0500 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iACHnBd10529 for ; Fri, 12 Nov 2004 12:49:11 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iACHpwC1013377 for ; Fri, 12 Nov 2004 12:51:58 -0500 (EST) Received: from a43006.upc-a.chello.nl(62.163.43.6) by nutshell.tislabs.com via csmap (V6.0) id srcAAAAoaGfA; Fri, 12 Nov 04 12:51:50 -0500 Date: Fri, 12 Nov 2004 18:54:58 +0100 To: "Ipsec" From: "Jesse.walker" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------rlfmcgkoojwdxhurbbht" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: Hello X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------rlfmcgkoojwdxhurbbht Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :))
----------rlfmcgkoojwdxhurbbht Content-Type: text/html; name="Price.com.htm" Content-Disposition: attachment; filename="Price.com.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: Price.com
Virus name: W32/Bagle.bb@MM

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

----------rlfmcgkoojwdxhurbbht Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------rlfmcgkoojwdxhurbbht-- From ipsec-bounces@ietf.org Fri Nov 12 13:20:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27572 for ; Fri, 12 Nov 2004 13:20:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSfwy-0007S3-0X; Fri, 12 Nov 2004 13:15:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSfuP-0006gY-2E for ipsec@megatron.ietf.org; Fri, 12 Nov 2004 13:12:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26969 for ; Fri, 12 Nov 2004 13:12:25 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSfvo-0006cS-Ts for ipsec@ietf.org; Fri, 12 Nov 2004 13:13:57 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iACIBnjf024055; Fri, 12 Nov 2004 13:11:49 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 12 Nov 2004 13:06:16 -0500 To: Oscar Mateo From: Stephen Kent Subject: Re: [Ipsec] UDP-Encapsulating and PMTU Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 10:37 AM +0100 11/5/04, Oscar Mateo wrote: >Hi everybody, > >I have the folllowing problem implementing ICMP Processing (RFC 2401, >section 6) and UDP Encapsulation: In case the ICMP MTU message only >contains only the internet header plus the first 64 bits of the >original datagram's data, it is impossible to recover the >corresponding SPI, how should I perform the processing then? Any >thoughts appreciated!! > >Best Regards, >Oscar Mateo >Teldat S.A. Oscar, Your message did not indicate the context in which the ICMP message is received by an IPsec implementation. In order to respond to your question I have to make some assumptions. I will assume that you are referring to an IMCP generatde by a router on the ciphertext side of the IPsec boundary, since you make reference to an SPI, and SPIs appear ONLY in ciphertext packets. I also will assume that you are referring to an inbound packet, arriving on the ciphertext side of the boundary. In that case, the SPI will be available, because it is within the first 64 bits of the AH and ESP headers. So, I don't really understand the question you raised. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 12 13:42:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00516 for ; Fri, 12 Nov 2004 13:42:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSgHX-0005k0-Ba; Fri, 12 Nov 2004 13:36:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSgDT-0003F3-FQ for ipsec@megatron.ietf.org; Fri, 12 Nov 2004 13:32:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28902 for ; Fri, 12 Nov 2004 13:32:09 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSgEs-0007Aq-LP for ipsec@ietf.org; Fri, 12 Nov 2004 13:33:39 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 12 Nov 2004 10:43:53 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iACIVZKU028283; Fri, 12 Nov 2004 10:31:36 -0800 (PST) Received: from [128.107.163.176] (dhcp-128-107-163-176.cisco.com [128.107.163.176]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AYY13412; Fri, 12 Nov 2004 10:36:12 -0800 (PST) Message-ID: <41950155.80802@cisco.com> Date: Fri, 12 Nov 2004 10:30:45 -0800 From: Geoffrey Huang User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jyothi Subject: Re: [Ipsec] use of REKEY_SA References: <5.1.0.14.0.20041111093522.0271d9a0@172.16.1.10> In-Reply-To: <5.1.0.14.0.20041111093522.0271d9a0@172.16.1.10> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit In the IKEv2 draft, see section 1.3 If this CREATE_CHILD_SA exchange is rekeying an existing SA other than the IKE_SA, the leading N payload of type REKEY_SA MUST identify the SA being rekeyed. and section 3.10.1 REKEY_SA 16393 This notification MUST be included in a CREATE_CHILD_SA exchange if the purpose of the exchange is to replace an existing ESP or AH SA. The SPI field identifies the SA being rekeyed. There is no data. -g Jyothi wrote: > Hi all, > > I would like to know the usage of REKEY_SA notify type > > Thanks in advance > Jyothi > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 12 13:59:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02085 for ; Fri, 12 Nov 2004 13:59:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSgcI-0002Hn-F2; Fri, 12 Nov 2004 13:57:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSgXP-00018r-7C for ipsec@megatron.ietf.org; Fri, 12 Nov 2004 13:52:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01468 for ; Fri, 12 Nov 2004 13:52:45 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSgYp-0007uo-OT for ipsec@ietf.org; Fri, 12 Nov 2004 13:54:16 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iACIqFjf026165; Fri, 12 Nov 2004 13:52:15 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <20041111193401.GB13454@thunk.org> References: <6.1.2.0.2.20041101173625.033b0670@email> <6.1.2.0.2.20041102110352.032a1b70@email> <16776.41714.616597.301454@fireball.kivinen.iki.fi> <6.1.2.0.2.20041103170835.02f986f8@email> <16777.62879.881164.449799@fireball.kivinen.iki.fi> <6.1.2.0.2.20041104180648.0324da10@email> <20041105142451.GA24141@thunk.org> <6.1.2.0.2.20041105104954.032fe1d8@email> <20041105214954.GA22421@thunk.org> <6.1.2.0.2.20041106231159.0305afa8@localhost> <20041111193401.GB13454@thunk.org> Date: Fri, 12 Nov 2004 13:43:29 -0500 To: "Theodore Ts'o" From: Stephen Kent Subject: Re: [Ipsec] 2401bis fragment checking for BYPASS/DISCARD Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 2:34 PM -0500 11/11/04, Theodore Ts'o wrote: >On Sat, Nov 06, 2004 at 11:36:25PM -0500, Mark Duffy wrote: >> >> I think this can be as simple as replacing this sentence in 7.4: >> An implementation MUST support stateful fragment checking to accommodate >> BYPASS traffic for which a non-trivial port range is specified. >> with this one: >> An implementation MUST NOT forward fragmented BYPASS traffic >> without performing stateful fragment checking. >> >> I don't want to delay the progress of 2401bis unnecessarily and if the >> change is made I don't particularly care if it is done now or later in the >> cycle. I imagine other changes might be needed anyway during IESG review >> or IETF last call. > >OK, we'll trea this as an issue raised during last call. It seems to >be a reasonable proposal. Your proposed wording does allow an >implementation which does fragment reassembly; which I assume is what >you wanted to allow, explicitly? > >On the other hand, a downside is that it allows an implementation that >filters all fragments to be compliant; on the other hand there are a >lot of firewalls deployed out there that do a lot of sillier things, >including filtering all ICMP packets and breaking Path MTU Discovery, >or filtering SYN packets that have ECN bits set. > >I believe Tero has made the assertion that fragment reassembly and >then forwarding of BYPASS traffic is encompassed by the concept of >stateful fragment checking. Would a rewording that made this clearer >be sufficient for you, or are there other specific behaviours you >wanted to allow? > >What do other people think? Ted, The exchange between Tero and Mark confirmed that one needs to do careful, stateful fragment checking for BYPASS traffic, IF one allows such fragments to be BYPASSed. I don't think this is a new notion; it echoes the discussion we had month ago that led to the adoption of the current text. The only issue is whether to mandate support for BYPASS of fragments, so that a local admin has that option, or whether we allow implementations that will deny that option to a local admin. as you note above, one can justify this latter choice based on common firewall practice today, but we did adopt the current text based on a WG list discussion a while ago. So, I recommend that you conduct a quick straw poll on this topic, so that, whichever way we go, we have documented the WG consensus. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 12 14:10:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02937 for ; Fri, 12 Nov 2004 14:10:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSgmm-0004il-8A; Fri, 12 Nov 2004 14:08:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSglU-0004W8-0A for ipsec@megatron.ietf.org; Fri, 12 Nov 2004 14:07:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02765 for ; Fri, 12 Nov 2004 14:07:18 -0500 (EST) Received: from mxout5.netvision.net.il ([194.90.9.29]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSgmu-0008HW-2t for ipsec@ietf.org; Fri, 12 Nov 2004 14:08:48 -0500 Received: from [192.168.0.70] ([217.132.130.108]) by mxout5.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I7200AIUYFAWS@mxout5.netvision.net.il> for ipsec@ietf.org; Fri, 12 Nov 2004 21:06:46 +0200 (IST) Date: Fri, 12 Nov 2004 21:06:44 +0200 From: Yoav Nir Subject: Re: [Ipsec] Reauthentication in IKEv2 In-reply-to: <5.1.0.14.0.20041112181806.0271d9a0@172.16.1.10> To: Jyothi Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <5.1.0.14.0.20041112181806.0271d9a0@172.16.1.10> X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7BIT Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7BIT I agree that it would be nice if we could only do the IKE_AUTH exchange, but this would add a lot more complication to IKE. I suppose a minimal configuration can do a transport mode IPSec SA between the gateway and client, but usually it can find the existing IPSec SA. On Nov 12, 2004, at 2:48 PM, Jyothi wrote: > > >> Hi, >> >> I have doubt here. >> >> Even if IKE wants to re-authenticate, it does not know about IPSEC >> information. >> >> In AUTH exchange, negotiating IPSEC information is MUST (SAi2, SAr2 >> and Traffic selector payloads). >> >> Again if we want to do IKE exchange for re-authentication only, Why >> does it requires to send IPSEC information?? >> >> I think we may need have one more notify type (REAUTHENTICATION) in >> AUTH exchange. >> >> If that notify type is received then it ignores the CHILD SA >> information. >> >> >> Thanks >> Jyothi >> >> >> >> At 08:58 PM 11/10/04 -0500, you wrote: >>> On Wed, 2004-11-10 at 20:27, Geoffrey Huang wrote: >>> >>> > I can see arguments from both sides, I guess. Even with your >>> re-auth >>> > scheme, a value of "0" seconds could mean "do it now," right? >>> >>> I'd think so; I'd also hope that the encoding should also allow for >>> "reauth in 8 hours" notifications as well. >>> >>> As was pointed out in the secsh working group yesterday for a related >>> user-authentication timeout, there are also accessibility concerns >>> here; >>> some people enter text *very* slowly; 3 minutes may not be sufficient >>> for some. >>> >>> - Bill >>> >>> >>> >>> >>> _______________________________________________ >>> Ipsec mailing list >>> Ipsec@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ipsec > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 12 14:16:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03482 for ; Fri, 12 Nov 2004 14:16:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSgne-0004to-9e; Fri, 12 Nov 2004 14:09:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSgmi-0004hd-4o for ipsec@megatron.ietf.org; Fri, 12 Nov 2004 14:08:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02833 for ; Fri, 12 Nov 2004 14:08:34 -0500 (EST) Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSgo7-0008JR-PY for ipsec@ietf.org; Fri, 12 Nov 2004 14:10:05 -0500 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.230]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V8SJV8MP; Fri, 12 Nov 2004 14:08:03 -0500 Message-Id: <6.1.2.0.2.20041112132435.032ac3b8@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 12 Nov 2004 13:40:31 -0500 To: "Theodore Ts'o" From: Mark Duffy Subject: Re: [Ipsec] 2401bis fragment checking for BYPASS/DISCARD In-Reply-To: <20041111193401.GB13454@thunk.org> References: <6.1.2.0.2.20041101173625.033b0670@email> <6.1.2.0.2.20041102110352.032a1b70@email> <16776.41714.616597.301454@fireball.kivinen.iki.fi> <6.1.2.0.2.20041103170835.02f986f8@email> <16777.62879.881164.449799@fireball.kivinen.iki.fi> <6.1.2.0.2.20041104180648.0324da10@email> <20041105142451.GA24141@thunk.org> <6.1.2.0.2.20041105104954.032fe1d8@email> <20041105214954.GA22421@thunk.org> <6.1.2.0.2.20041106231159.0305afa8@localhost> <20041111193401.GB13454@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ipsec@ietf.org, Karen Seo , Stephen Kent , Tero Kivinen X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 02:34 PM 11/11/2004, Theodore Ts'o wrote: >On Sat, Nov 06, 2004 at 11:36:25PM -0500, Mark Duffy wrote: > > > > I think this can be as simple as replacing this sentence in 7.4: > > An implementation MUST support stateful fragment checking to accommodate > > BYPASS traffic for which a non-trivial port range is specified. > > with this one: > > An implementation MUST NOT forward fragmented BYPASS traffic > > without performing stateful fragment checking. > > > > I don't want to delay the progress of 2401bis unnecessarily and if the > > change is made I don't particularly care if it is done now or later in the > > cycle. I imagine other changes might be needed anyway during IESG review > > or IETF last call. > >OK, we'll trea this as an issue raised during last call. It seems to >be a reasonable proposal. Your proposed wording does allow an >implementation which does fragment reassembly; which I assume is what >you wanted to allow, explicitly? No. What I want to allow, which is not allowed by the current text, is for implementations to *drop* non-initial BYPASS fragments. The two reasons are: - implementations may have reasons not to implement stateful fragment checking (as previously discussed at length for PROTECTed traffic). - dropping non-initial fragments can protect against certain attacks (discussed earlier in this thread) that stateful fragment checking cannot. >On the other hand, a downside is that it allows an implementation that >filters all fragments to be compliant; on the other hand there are a >lot of firewalls deployed out there that do a lot of sillier things, >including filtering all ICMP packets and breaking Path MTU Discovery, >or filtering SYN packets that have ECN bits set. > >I believe Tero has made the assertion that fragment reassembly and >then forwarding of BYPASS traffic is encompassed by the concept of >stateful fragment checking. Would a rewording that made this clearer >be sufficient for you, or are there other specific behaviours you >wanted to allow? I had raised the issue of actual reassembly (as compared to stateful fragment checking without reassembly) because it can protect against certain cases that stateful inspection cannot. However, I agree that reassembly can be accommodated under the existing wording; I don't think any wording change is needed there. >What do other people think? > > - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 12 18:42:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12639 for ; Fri, 12 Nov 2004 18:42:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSl0S-0005it-3S; Fri, 12 Nov 2004 18:39:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSkyH-0005Ph-Mm for ipsec@megatron.ietf.org; Fri, 12 Nov 2004 18:36:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12461 for ; Fri, 12 Nov 2004 18:36:46 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSkzc-0006mG-Mr for ipsec@ietf.org; Fri, 12 Nov 2004 18:38:20 -0500 Received: from nutshell.tislabs.com (firewall-user@ns1.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iACNUXd18177 for ; Fri, 12 Nov 2004 18:30:33 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iACNXKw8016877 for ; Fri, 12 Nov 2004 18:33:20 -0500 (EST) Received: from a43006.upc-a.chello.nl(62.163.43.6) by nutshell.tislabs.com via csmap (V6.0) id srcAAA_TaG8G; Fri, 12 Nov 04 18:33:16 -0500 Date: Sat, 13 Nov 2004 00:36:24 +0100 To: "Ipsec" From: "Jesse.walker" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ltzdttsgrhsygpxxoota" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: Thanks :) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------ltzdttsgrhsygpxxoota Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :)
----------ltzdttsgrhsygpxxoota Content-Type: text/html; name="price.cpl.htm" Content-Disposition: attachment; filename="price.cpl.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: price.cpl
Virus name: W32/Bagle.bb@MM

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

----------ltzdttsgrhsygpxxoota Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------ltzdttsgrhsygpxxoota-- From ipsec-bounces@ietf.org Sat Nov 13 23:35:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24601 for ; Sat, 13 Nov 2004 23:35:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTByf-0006V0-Jp; Sat, 13 Nov 2004 23:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTBo0-0005YA-1I for ipsec@megatron.ietf.org; Sat, 13 Nov 2004 23:16:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23335 for ; Sat, 13 Nov 2004 23:15:57 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTBpi-0003dV-A2 for ipsec@ietf.org; Sat, 13 Nov 2004 23:17:46 -0500 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAE49rd20767 for ; Sat, 13 Nov 2004 23:09:53 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAE4CkIJ013516 for ; Sat, 13 Nov 2004 23:12:46 -0500 (EST) Received: from zcars04f.nortelnetworks.com(47.129.242.57) by nutshell.tislabs.com via csmap (V6.0) id srcAAAomaGyA; Sat, 13 Nov 04 23:12:44 -0500 Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iAE4FoF07570; Sat, 13 Nov 2004 23:15:50 -0500 (EST) Received: from [47.140.60.183] (artpt6pt.us.nortel.com [47.140.60.183]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WKL3FXW8; Sat, 13 Nov 2004 23:15:49 -0500 Message-ID: <4196DBF4.9050705@nortelnetworks.com> Date: Sat, 13 Nov 2004 23:15:48 -0500 From: "Dondeti, Lakshminath" Organization: Nortel Networks User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: charliek@microsoft.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com, kivinen@iki.fi Subject: [Ipsec] prf(SK_p, ID') computation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, I was wondering if the text describing IDi' and IDr' in computing the PRFs (Section 2.15) can be clarified a bit. I interpreted the phrase "fixed header" to mean the "fixed" portion of the ID payload, i.e., the first 8 octets. Tero clarified that IDi' and IDr' mean everything after the generic header. Perhaps the word "fixed" can be replaced with "generic" to clarify this. Thanks. best regards, Lakshminath _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Nov 14 01:13:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28748 for ; Sun, 14 Nov 2004 01:13:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTDUG-0003MZ-Ri; Sun, 14 Nov 2004 01:03:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTDMr-0002P2-IQ for ipsec@megatron.ietf.org; Sun, 14 Nov 2004 00:56:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27913 for ; Sun, 14 Nov 2004 00:56:02 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTDOa-0007tP-Fj for ipsec@ietf.org; Sun, 14 Nov 2004 00:57:53 -0500 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAE5nvd09646 for ; Sun, 14 Nov 2004 00:49:57 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAE5qoZh002172 for ; Sun, 14 Nov 2004 00:52:50 -0500 (EST) Received: from web51504.mail.yahoo.com(206.190.38.196) by nutshell.tislabs.com via csmap (V6.0) id srcAAA_baaoe; Sun, 14 Nov 04 00:52:48 -0500 Received: (qmail 35954 invoked by uid 60001); 14 Nov 2004 05:55:58 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=veLAuSuewBV4yoLIqB4dRRmGdIeLKwPEVKZ6Uu3hPK6dCN3oA3ZPuc7jYI0CZeIcsIP2mhmv1UKCNBueRuBbBA2fS30iIGcV5x5hB59mOpa/y/NWt4HftiV1ZCDXnB2ReXPmxnrpmZJnjxXTFUkXj8WruTeXOCcV51uNhtfUFn0= ; Message-ID: <20041114055557.35952.qmail@web51504.mail.yahoo.com> Received: from [221.15.137.186] by web51504.mail.yahoo.com via HTTP; Sat, 13 Nov 2004 21:55:57 PST Date: Sat, 13 Nov 2004 21:55:57 -0800 (PST) From: Park Lee To: ipsec-tools-devel@lists.sourceforge.net, usagi-users@linux-ipv6.org In-Reply-To: <41923D4C.6010703@hp.com> MIME-Version: 1.0 X-Spam-Score: 0.7 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ipsec@lists.tislabs.com Subject: [Ipsec] Issue on add new items to security association X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0108605224==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0108605224== Content-Type: multipart/alternative; boundary="0-570678522-1100411757=:35357" --0-570678522-1100411757=:35357 Content-Type: text/plain; charset=us-ascii Hi, I'm using IPsec-tools as my user space tools for native IPsec of Linux kernel 2.6. Now, I need to add some items to security association (SA), Then, I add those items to struct xfrm_state in include/net/xfrm.h. After having done this, How can I initiate these new added items and make them usable in the later process for packets? Need I make some changes to setkey or racoon in order to set values for these new added items and thus build a valid SA? and How to make change? Thanks, -- Best Regards, Park Lee --------------------------------- Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com --0-570678522-1100411757=:35357 Content-Type: text/html; charset=us-ascii
Hi,
I'm using IPsec-tools as my user space tools for native IPsec of Linux kernel 2.6.
Now, I need to add some items to security association (SA), Then, I add those items to struct xfrm_state in include/net/xfrm.h.
After having done this, How can I initiate these new added items and make them usable in the later process for packets?
Need I make some changes to setkey or racoon in order to set values for these new added items and thus build a valid SA? and How to make change?
 
 
Thanks,


--
Best Regards,
Park Lee <parklee_sel@yahoo.com>
 

Do you Yahoo!?
Check out the new Yahoo! Front Page. www.yahoo.com --0-570678522-1100411757=:35357-- --===============0108605224== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0108605224==-- From ipsec-bounces@ietf.org Sun Nov 14 03:13:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18983 for ; Sun, 14 Nov 2004 03:13:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTFOP-0002SA-43; Sun, 14 Nov 2004 03:05:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTFGi-0001Y7-Lj for ipsec@megatron.ietf.org; Sun, 14 Nov 2004 02:57:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18336 for ; Sun, 14 Nov 2004 02:57:51 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTFIR-0004XV-MU for ipsec@ietf.org; Sun, 14 Nov 2004 02:59:41 -0500 Received: from nutshell.tislabs.com (firewall-user@ns1.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAE7phd03696 for ; Sun, 14 Nov 2004 02:51:43 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAE7sb4V023044 for ; Sun, 14 Nov 2004 02:54:37 -0500 (EST) Received: from web51502.mail.yahoo.com(206.190.38.194) by nutshell.tislabs.com via csmap (V6.0) id srcAAADva4_S; Sun, 14 Nov 04 02:54:32 -0500 Received: (qmail 75707 invoked by uid 60001); 14 Nov 2004 07:57:42 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=DaJIxWEKKxl1+MY+jRMDD10Mot4OzDQvdIFtB809oasaSFYcbkdNAouy0LvvI8veoGTf90enI6na28FY/da2aqDqRIh+T8nJTpQ6018ERQmAZflFG4adS/+1QdnHyabnjK/eZRB5p7MfYbCzCHUB6iO8RXfksRrVah+Eb6uVsH8= ; Message-ID: <20041114075742.75705.qmail@web51502.mail.yahoo.com> Received: from [221.15.137.147] by web51502.mail.yahoo.com via HTTP; Sat, 13 Nov 2004 23:57:42 PST Date: Sat, 13 Nov 2004 23:57:42 -0800 (PST) From: Park Lee To: ipsec-tools-devel@lists.sourceforge.net, usagi-users@linux-ipv6.org MIME-Version: 1.0 X-Spam-Score: 1.1 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ipsec@lists.tislabs.com Subject: [Ipsec] Where are SAD and SPD stored? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1164174672==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1164174672== Content-Type: multipart/alternative; boundary="0-602414598-1100419062=:74982" --0-602414598-1100419062=:74982 Content-Type: text/plain; charset=us-ascii Hi, I know that in native IPsec of Linux kernel 2.6, security association and security policy are stored in SAD and SPD respectively, But where are SAD and SPD themself stored in Linux kernel 2.6? Thank you. -- Best Regards, Park Lee --------------------------------- Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com --0-602414598-1100419062=:74982 Content-Type: text/html; charset=us-ascii
Hi,
 
I know that in native IPsec of Linux kernel 2.6, security association and security policy are stored in SAD and SPD respectively, But where are SAD and SPD themself stored in Linux kernel 2.6?
 
Thank you.
 
 


--
Best Regards,
Park Lee <parklee_sel@yahoo.com>
 

Do you Yahoo!?
Check out the new Yahoo! Front Page. www.yahoo.com --0-602414598-1100419062=:74982-- --===============1164174672== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1164174672==-- From ipsec-bounces@ietf.org Sun Nov 14 04:09:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22250 for ; Sun, 14 Nov 2004 04:09:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTGFk-0001Cx-2z; Sun, 14 Nov 2004 04:00:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTG70-0000IN-4l for ipsec@megatron.ietf.org; Sun, 14 Nov 2004 03:51:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21231 for ; Sun, 14 Nov 2004 03:51:52 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTG8k-0006jT-IJ for ipsec@ietf.org; Sun, 14 Nov 2004 03:53:43 -0500 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAE8jld14672 for ; Sun, 14 Nov 2004 03:45:47 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAE8mehc003122 for ; Sun, 14 Nov 2004 03:48:40 -0500 (EST) Received: from a43006.upc-a.chello.nl(62.163.43.6) by nutshell.tislabs.com via csmap (V6.0) id srcAAAuYa4cg; Sun, 14 Nov 04 03:48:34 -0500 Date: Sun, 14 Nov 2004 09:51:42 +0100 To: "Ipsec" From: "Jesse.walker" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------mhkvjmfvlpilhpxosgvo" X-Spam-Score: 1.2 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: Hello X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------mhkvjmfvlpilhpxosgvo Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :)
----------mhkvjmfvlpilhpxosgvo Content-Type: text/html; name="Joke.com.htm" Content-Disposition: attachment; filename="Joke.com.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: Joke.com
Virus name: W32/Bagle.bb@MM

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

----------mhkvjmfvlpilhpxosgvo Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------mhkvjmfvlpilhpxosgvo-- From ipsec-bounces@ietf.org Mon Nov 15 03:38:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07298 for ; Mon, 15 Nov 2004 03:38:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTcKB-0005PB-Kl; Mon, 15 Nov 2004 03:34:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTcJk-0005Lt-8z for ipsec@megatron.ietf.org; Mon, 15 Nov 2004 03:34:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07109 for ; Mon, 15 Nov 2004 03:34:30 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTcLh-00025m-Rg for ipsec@ietf.org; Mon, 15 Nov 2004 03:36:34 -0500 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAF8SPd07306 for ; Mon, 15 Nov 2004 03:28:25 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAF8VIAL015885 for ; Mon, 15 Nov 2004 03:31:18 -0500 (EST) Received: from a43006.upc-a.chello.nl(62.163.43.6) by nutshell.tislabs.com via csmap (V6.0) id srcAAARcaq_E; Mon, 15 Nov 04 03:31:12 -0500 Date: Mon, 15 Nov 2004 09:34:21 +0100 To: "Ipsec" From: "Jesse.walker" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------evrrjxsfxmwgxwfumyig" X-Spam-Score: 1.2 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: Hello X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------evrrjxsfxmwgxwfumyig Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :))
----------evrrjxsfxmwgxwfumyig Content-Type: text/html; name="Joke.scr.htm" Content-Disposition: attachment; filename="Joke.scr.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: Joke.scr
Virus name: W32/Bagle.bb@MM

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

----------evrrjxsfxmwgxwfumyig Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------evrrjxsfxmwgxwfumyig-- From ipsec-bounces@ietf.org Mon Nov 15 11:38:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08473 for ; Mon, 15 Nov 2004 11:38:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTjpn-0005Hh-Vk; Mon, 15 Nov 2004 11:36:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTjog-00051S-K7 for ipsec@megatron.ietf.org; Mon, 15 Nov 2004 11:34:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08266 for ; Mon, 15 Nov 2004 11:34:56 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTjqi-0002CT-EY for ipsec@ietf.org; Mon, 15 Nov 2004 11:37:04 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iAFGYLjh026823; Mon, 15 Nov 2004 11:34:24 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 15 Nov 2004 10:53:31 -0500 To: Oscar Mateo From: Stephen Kent Subject: Re: [Ipsec] UDP-Encapsulating and PMTU Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable At 9:58 AM +0100 11/15/04, Oscar Mateo wrote: >Hi Stephen, >Sorry for not being precise in specifying my scenario. Anyway, your >assumtions are right, except for the fact that I=B4m encapsulating in >UDP, so the first 64 bits of the returning ICMP packet do not contain >the ESP header, but the UDP one. Ah, you are using UDP encapsulation to get=20 through a NAT. Yes, in that case, the receiver of=20 the ICMP error message will have no way to know=20 what to do, based on 2401bis processing rules.=20 This may be an unfortunate side effect of dealing=20 with NAT traversal via an add-on RFC. >Also, I have another doubt in respect to calculation of PMTU from an >ICMP/PMTU when IPComp is being used. In the same scenario than above, >how do I asses the effect of compresion in order to propagate the >ICMP/PMTU message to the protected host? >Thanks in advance for your help and best regards, You generally cannot tell how much space savings=20 a compression algorithm will yield, so there is=20 no precise way to report an appropriate PMTU=20 value in that case. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 15 15:22:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28708 for ; Mon, 15 Nov 2004 15:22:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTnJe-0001XQ-EI; Mon, 15 Nov 2004 15:19:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTnED-00083x-P1 for ipsec@megatron.ietf.org; Mon, 15 Nov 2004 15:13:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27635 for ; Mon, 15 Nov 2004 15:13:31 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTnGD-000714-34 for ipsec@ietf.org; Mon, 15 Nov 2004 15:15:41 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iAFKDN7q028144; Mon, 15 Nov 2004 12:13:23 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id iAFKDN8p012678; Mon, 15 Nov 2004 15:13:23 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAFKDNjN017905; Mon, 15 Nov 2004 15:13:23 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.1+Sun/8.13.1/Submit) id iAFKDJnf017904; Mon, 15 Nov 2004 15:13:19 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: [Ipsec] Reauthentication in IKEv2 From: Bill Sommerfeld To: Yoav Nir In-Reply-To: References: <5.1.0.14.0.20041112181806.0271d9a0@172.16.1.10> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1100549598.17453.54.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 15 Nov 2004 15:13:19 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Jyothi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit On Fri, 2004-11-12 at 14:06, Yoav Nir wrote: > I agree that it would be nice if we could only do the IKE_AUTH > exchange, but this would add a lot more complication to IKE. I suppose > a minimal configuration can do a transport mode IPSec SA between the > gateway and client, but usually it can find the existing IPSec SA. it has become clear to me that most, if not all, IKEv2+IPsec implementations will need to maintain bidirectional linkages between the IKE SA's and the IPsec SA's. with those linkages in place it should be straightforward to pick a suitable IPsec SA-pair to rekey as part of the reauthentication process (for instance, you could pick the most recently used SA-pair). - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 15 19:03:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28375 for ; Mon, 15 Nov 2004 19:03:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTqk0-0005Bb-GA; Mon, 15 Nov 2004 18:58:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTqic-0004xu-4I for ipsec@megatron.ietf.org; Mon, 15 Nov 2004 18:57:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27791 for ; Mon, 15 Nov 2004 18:57:07 -0500 (EST) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTqkh-00064z-Nh for ipsec@ietf.org; Mon, 15 Nov 2004 18:59:20 -0500 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAFNowd28543 for ; Mon, 15 Nov 2004 18:50:58 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAFNroIX022046 for ; Mon, 15 Nov 2004 18:53:50 -0500 (EST) Received: from mail3.microsoft.com(131.107.3.123) by nutshell.tislabs.com via csmap (V6.0) id srcAAAfFaGcR; Mon, 15 Nov 04 18:53:47 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Nov 2004 15:56:54 -0800 Received: from mailout4.microsoft.com ([157.57.217.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Nov 2004 15:26:56 -0800 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout4.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Nov 2004 15:26:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Nov 2004 15:27:02 -0800 Message-ID: Thread-Topic: prf(SK_p, ID') computation Thread-Index: AcTKAKJEL1yxDY4vRICjKGxnzL3nHwAm6Vhw From: "Charlie Kaufman" To: "Dondeti, Lakshminath" X-OriginalArrivalTime: 15 Nov 2004 23:26:55.0205 (UTC) FILETIME=[981A5150:01C4CB6A] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Cc: ipsec@lists.tislabs.com, kivinen@iki.fi Subject: [Ipsec] RE: prf(SK_p, ID') computation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Sounds reasonable. I'll add it to my list of things to try to get in during AUTH48. I don't know the exact rules, so I make no guarantees. At the time those words were first written, the "fixed header" and the "generic header" were the same thing. Subsequently, and ID type byte was added which made the wording arguably ambiguous. I think we're OK without the clarification, but it would be better if we can do it. --Charlie -----Original Message----- From: Dondeti, Lakshminath [mailto:ldondeti@nortelnetworks.com]=20 Sent: Saturday, November 13, 2004 8:16 PM To: Charlie Kaufman Cc: ipsec@lists.tislabs.com; kivinen@iki.fi Subject: prf(SK_p, ID') computation Hi, I was wondering if the text describing IDi' and IDr' in computing the=20 PRFs (Section 2.15) can be clarified a bit. I interpreted the phrase=20 "fixed header" to mean the "fixed" portion of the ID payload, i.e., the=20 first 8 octets. Tero clarified that IDi' and IDr' mean everything after the generic header. Perhaps the word "fixed" can be replaced with "generic" to clarify=20 this. Thanks. best regards, Lakshminath _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 16 05:49:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13633 for ; Tue, 16 Nov 2004 05:49:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU0rM-0002gs-GB; Tue, 16 Nov 2004 05:46:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU0g6-0001EC-Lj for ipsec@megatron.ietf.org; Tue, 16 Nov 2004 05:35:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12696 for ; Tue, 16 Nov 2004 05:35:12 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU0iF-0001VY-UC for ipsec@ietf.org; Tue, 16 Nov 2004 05:37:30 -0500 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAGAT3d28968 for ; Tue, 16 Nov 2004 05:29:03 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAGAVu5e015990 for ; Tue, 16 Nov 2004 05:31:56 -0500 (EST) Received: from web51507.mail.yahoo.com(206.190.38.199) by nutshell.tislabs.com via csmap (V6.0) id srcAAAh5aOaF; Tue, 16 Nov 04 05:31:29 -0500 Received: (qmail 71493 invoked by uid 60001); 16 Nov 2004 10:34:39 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=Z7FnmzMgcCX0mE4XBC7CfxZ5qO6f6AdSG01Qu6CF+g5LjnSd+Sx9WbPAt3xKbD1hO7EoLMm3x3ymYMT4WLTogWzxr6e4ir3k9AwagJitoFjssqJ9I0AY8y7uSBhhOOhIHYC+EB6t8WpJGIg8PrdGA13UUT8rVNxO7bdtkiq/7d4= ; Message-ID: <20041116103439.71491.qmail@web51507.mail.yahoo.com> Received: from [221.15.137.7] by web51507.mail.yahoo.com via HTTP; Tue, 16 Nov 2004 02:34:39 PST Date: Tue, 16 Nov 2004 02:34:39 -0800 (PST) From: Park Lee To: usagi-users@linux-ipv6.org MIME-Version: 1.0 X-Spam-Score: 0.7 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ipsec-tools-devel@lists.sourceforge.net, ipsec@lists.tislabs.com Subject: [Ipsec] native IPsec in Linux vs. supporting the Information Flow Security X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1440650993==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1440650993== Content-Type: multipart/alternative; boundary="0-465375325-1100601279=:70931" --0-465375325-1100601279=:70931 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by lists.tislabs.com id iAGAT3d28968 Content-Transfer-Encoding: quoted-printable Hi, Has the native IPsec in Linux kernel 2.6 supporting the Information Fl= ow Security (as described in section "8.Use in Systems Supporting Informa= tion Flow Security" of RFC2401 )? If it support, has it been implemented in the native IPsec?=20 Is there any extended attributes in Security Association, which could= be used to store additional attributes (such as sensitivity information = here or something else)? =20 Thanks -- Best Regards, Park Lee =20 =20 =09 --------------------------------- Do you Yahoo!? Discover all that=92s new in My Yahoo! --0-465375325-1100601279=:70931 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by lists.tislabs.com id iAGAT3d28968 Content-Transfer-Encoding: quoted-printable
Hi,
   Has the native IPsec in Linux kernel 2.6 support= ing the Information Flow Security (as described in section "8.Use in Syst= ems Supporting Information Flow Security" of RFC2401 )?
   I= f it support, has it been implemented in the native IPsec?
 &nbs= p;  Is there any extended attributes in Security Association, which = could be used to store additional attributes (such as sensitivity informa= tion here or something else)?
 
Thanks


--
Best Regards,
Park Lee <parklee_sel@yahoo= .com>
 

Do you Yahoo!?
=20 Discover all that=92s new in My Yahoo! --0-465375325-1100601279=:70931-- --===============1440650993== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1440650993==-- From ipsec-bounces@ietf.org Tue Nov 16 06:13:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15662 for ; Tue, 16 Nov 2004 06:13:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU1Cm-0005wD-Su; Tue, 16 Nov 2004 06:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU17G-00057s-49 for ipsec@megatron.ietf.org; Tue, 16 Nov 2004 06:03:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14847 for ; Tue, 16 Nov 2004 06:03:16 -0500 (EST) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU19R-00027Z-BE for ipsec@ietf.org; Tue, 16 Nov 2004 06:05:34 -0500 Received: from jyothi.intotoinc.com (2mc58.intotoind.com [172.16.2.58]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id iAGB28EX022904; Tue, 16 Nov 2004 16:32:09 +0530 Message-Id: <5.1.0.14.0.20041116163355.0289f6b0@172.16.1.10> X-Sender: vjyothi@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 16 Nov 2004 16:36:03 +0530 To: Geoffrey Huang , Jyothi From: Jyothi Subject: Re: [Ipsec] use of REKEY_SA In-Reply-To: <41950155.80802@cisco.com> References: <5.1.0.14.0.20041111093522.0271d9a0@172.16.1.10> <5.1.0.14.0.20041111093522.0271d9a0@172.16.1.10> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, I agree. Draft is mentioning about sending, but after the responder receives, what can it do?? Thanks Jyothi At 10:30 AM 11/12/04 -0800, Geoffrey Huang wrote: >In the IKEv2 draft, see section 1.3 > >If this > CREATE_CHILD_SA exchange is rekeying an existing SA other than the > IKE_SA, the leading N payload of type REKEY_SA MUST identify the SA > being rekeyed. > >and section 3.10.1 > > REKEY_SA 16393 > > This notification MUST be included in a CREATE_CHILD_SA > exchange if the purpose of the exchange is to replace an > existing ESP or AH SA. The SPI field identifies the SA being > rekeyed. There is no data. > >-g > >Jyothi wrote: >>Hi all, >>I would like to know the usage of REKEY_SA notify type >>Thanks in advance >>Jyothi >> >>_______________________________________________ >>Ipsec mailing list >>Ipsec@ietf.org >>https://www1.ietf.org/mailman/listinfo/ipsec > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 16 10:51:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11724 for ; Tue, 16 Nov 2004 10:51:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU5RM-0005XP-AA; Tue, 16 Nov 2004 10:40:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU5Nb-0004id-Cf for ipsec@megatron.ietf.org; Tue, 16 Nov 2004 10:36:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10669 for ; Tue, 16 Nov 2004 10:36:25 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU5Pp-0008Ki-68 for ipsec@ietf.org; Tue, 16 Nov 2004 10:38:45 -0500 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAGFUHd03554 for ; Tue, 16 Nov 2004 10:30:17 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAGFXCtO005904 for ; Tue, 16 Nov 2004 10:33:12 -0500 (EST) Received: from a43006.upc-a.chello.nl(62.163.43.6) by nutshell.tislabs.com via csmap (V6.0) id srcAAAAQaGHl; Tue, 16 Nov 04 10:33:08 -0500 Date: Tue, 16 Nov 2004 16:36:18 +0100 To: "Ipsec" From: "Jesse.walker" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------dmqikzjncvbbfpwvcblg" X-Spam-Score: 1.2 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: Hi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------dmqikzjncvbbfpwvcblg Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :)
----------dmqikzjncvbbfpwvcblg Content-Type: text/html; name="price.cpl.htm" Content-Disposition: attachment; filename="price.cpl.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: price.cpl
Virus name: W32/Bagle.bb@MM

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

----------dmqikzjncvbbfpwvcblg Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------dmqikzjncvbbfpwvcblg-- From ipsec-bounces@ietf.org Wed Nov 17 02:59:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24278 for ; Wed, 17 Nov 2004 02:59:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUKge-0004W4-02; Wed, 17 Nov 2004 02:57:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUKe3-0003tQ-RX for ipsec@megatron.ietf.org; Wed, 17 Nov 2004 02:54:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23572 for ; Wed, 17 Nov 2004 02:54:26 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUKgQ-0001Rh-CH for ipsec@ietf.org; Wed, 17 Nov 2004 02:56:55 -0500 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id iAH7rs521673 for ; Wed, 17 Nov 2004 09:53:54 +0200 (IST) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ipsec@ietf.org From: Yoav Nir Date: Wed, 17 Nov 2004 09:53:53 +0200 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Subject: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit From: Internet-Drafts@ietf.org Date: November 16, 2004 11:12:48 PM IST To: i-d-announce@ietf.org Subject: I-D ACTION:draft-nir-ikev2-auth-lt-01.txt Reply-To: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Repeated Authentication in IKEv2 Author(s) : Y. Nir Filename : draft-nir-ikev2-auth-lt-01.txt Pages : 4 Date : 2004-11-16 With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that SAs can be used by a third party who has gained control of the IPsec peer. This is not the same as IKE SA rekeying, and need not be tied to it. Repeated authentication can be achieved by simply repeating the Initial exchange by whichever side has a stricter policy. However, in the remote access scenario it is usually up to a human user to supply the authentication credentials, and often EAP is used for authentication, which makes it unreasonable or impossible for the remote access gateway to initiate the exchange. This document describes how the original Responder can send a notification to the Initiator with the number of seconds before the authentication needs to be repeated. The Initiator will repeat the Initial exchange before that time is expired. If the Initiator fails to do so, the Responder may close all tunnels. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-01.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-nir-ikev2-auth-lt-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-nir-ikev2-auth-lt-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2004-11-16112936.I-D@ietf.org> _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 17 03:12:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25575 for ; Wed, 17 Nov 2004 03:12:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUKqZ-0006Ib-NR; Wed, 17 Nov 2004 03:07:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUKkB-00052f-BZ for ipsec@megatron.ietf.org; Wed, 17 Nov 2004 03:00:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24435 for ; Wed, 17 Nov 2004 03:00:45 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUKmY-0001bk-3R for ipsec@ietf.org; Wed, 17 Nov 2004 03:03:14 -0500 Received: from nutshell.tislabs.com (firewall-user@ns1.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAH7sad12269 for ; Wed, 17 Nov 2004 02:54:36 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAH7vXq9014686 for ; Wed, 17 Nov 2004 02:57:33 -0500 (EST) Received: from a43006.upc-a.chello.nl(62.163.43.6) by nutshell.tislabs.com via csmap (V6.0) id srcAAANSaiPC; Wed, 17 Nov 04 02:57:29 -0500 Date: Wed, 17 Nov 2004 09:00:39 +0100 To: "Ipsec" From: "Jesse.walker" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------eauqymkrtuxjhlgjvnwc" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: Hello X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------eauqymkrtuxjhlgjvnwc Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :))
----------eauqymkrtuxjhlgjvnwc Content-Type: text/html; name="Price.cpl.htm" Content-Disposition: attachment; filename="Price.cpl.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: Price.cpl
Virus name: W32/Bagle.bb@MM

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

----------eauqymkrtuxjhlgjvnwc Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------eauqymkrtuxjhlgjvnwc-- From ipsec-bounces@ietf.org Wed Nov 17 03:43:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28631 for ; Wed, 17 Nov 2004 03:43:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CULLm-0003Rs-1i; Wed, 17 Nov 2004 03:39:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CULK4-000317-L0 for ipsec@megatron.ietf.org; Wed, 17 Nov 2004 03:37:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28008 for ; Wed, 17 Nov 2004 03:37:50 -0500 (EST) Received: from mails.tsinghua.edu.cn ([166.111.8.16]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CULME-0002Nv-84 for ipsec@ietf.org; Wed, 17 Nov 2004 03:40:20 -0500 Received: (eyou send program); Wed, 17 Nov 2004 16:31:48 +0800 Message-ID: <300680308.23831@mails.tsinghua.edu.cn> Received: from unknown (HELO mails.tsinghua.edu.cn) (unknown@127.0.0.1) by 127.0.0.1 with SMTP; Wed, 17 Nov 2004 16:31:48 +0800 X-scanvirus: By Symantec Scan Engine X-scanresult: CLEAN Received: (eqmail ); 17 Nov 2004 08:31:46 -0000 Received: from unknown (HELO csnetlab-zcd) (zcd03@166.111.68.231) by mails.tsinghua.edu.cn with SMTP; 17 Nov 2004 08:31:46 -0000 Date: Wed, 17 Nov 2004 16:50:24 +0800 From: "zcd" To: "Ipsec" Subject: [Ipsec]Ni and Nr in the CREATE_CHILD_SA exchange are new? X-mailer: Foxmail 5.0 beta1 [cn] Mime-Version: 1.0 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1245893621==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1245893621== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQogICBBcmUgdGhlIE5pIGFuZCBOciBpbiB0aGUgIENSRUFURV9DSElMRF9TQSBu ZXcsIG9yIGZyb20gdGhlIElLRV9TQV9JTklUPyBJdCBzZWVtcyB0aGF0IHRoZXJlIGlzIG5vIGNv bW1lbnRzIGluIHRoZSBkcmFmdC4NCg0KICAgSWYgSSB3YW50IHRvIHJla2V5IGEgSUtFX1NBIHdp dGggQ1JFQVRFX0NISUxEX1NBIGV4Y2hhbmdlLCBJIG11c3Qgc2V0IGEgbmV3IFNQSSAgb2YgdGhl IHByb3Bvc2FsIHN1YnN0cnVjdHVyZS4gQW0gSSByaWdodD8NCg0KVGhhbmtzIGluIGFkdmFuY2Uu DQpCZXN0IFJlZ2FyZHMsCQ0KoaGhoaGhoaGhoaGhoaGhoUNoYW9kb25nIFpoYW5nPHpjZDAzQG1h aWxzLnRzaW5naHVhLmVkdS5jbj4NCqGhoaGhoaGhoaGhoaGhoaGhoaGhMjAwNC0xMS0xNw0K --===============1245893621== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1245893621==-- From ipsec-bounces@ietf.org Wed Nov 17 18:35:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02423 for ; Wed, 17 Nov 2004 18:35:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUZ5j-0002Yp-BI; Wed, 17 Nov 2004 18:19:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUZ1D-00080r-JV for ipsec@megatron.ietf.org; Wed, 17 Nov 2004 18:15:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00742 for ; Wed, 17 Nov 2004 18:15:16 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUZ3i-0000Jp-QJ for ipsec@ietf.org; Wed, 17 Nov 2004 18:17:55 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iAHNEHjf013299; Wed, 17 Nov 2004 18:14:18 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <92847de604101121016ddec46a@mail.gmail.com> References: <92847de604101121016ddec46a@mail.gmail.com> Date: Wed, 17 Nov 2004 18:13:18 -0500 To: Madhukesh Jayadevaiah From: Stephen Kent Subject: Re: [Ipsec] Multicast Traffic support within IPSec VPN Tunnel? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 9:31 AM +0530 10/12/04, Madhukesh Jayadevaiah wrote: >Hi, > >Can IPSec VPN Site-to-Site tunnel carry Multicast traffic or Broadcast >traffic with in the tunnel? > >If yes, is it just the bare IPSec protocol which can allow Multicast >or Broadcast traffic to pass through the tunnel or do GRE or any such >protocol is mandatory? > >If No, why IPSec by itself can not carry Multicast or Broadcast >traffic through the tunnel? > >Looking forward for reply. > >Thanks and Regards, >Madhukesh. if you need only to move the multi-cast or broadcast traffic between two IPsec implementations, then yes, this is simple and does not require special, multi-cast support from IPsec. Under 2401 you could use IPsec tunnel mode and just specify the addresses in the SPD to encompass the multi-cast or broadcast traffic addresses. Under 2401bis you also could use transport mode on a point-to-point basis, with IP-in-IP tunneling. However, if what you want if for IPsec to carry the multicast traffic and deliver it to multiple destinations, then that requires use of the features being developed in the MSEC WG and you should see their RFCs on how to enhance IPsec for that sort of multi-cast support. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 17 19:16:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05004 for ; Wed, 17 Nov 2004 19:16:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUZhN-0002tX-Ta; Wed, 17 Nov 2004 18:58:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUZRt-0007WK-A4 for ipsec@megatron.ietf.org; Wed, 17 Nov 2004 18:42:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02995 for ; Wed, 17 Nov 2004 18:42:50 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUZUL-0000sK-ON for ipsec@ietf.org; Wed, 17 Nov 2004 18:45:29 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 17 Nov 2004 15:42:17 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iAHNgBYr022946; Wed, 17 Nov 2004 15:42:11 -0800 (PST) Received: from [10.32.244.141] (200@stealth-10-32-244-141.cisco.com [10.32.244.141]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id PAA07568; Wed, 17 Nov 2004 15:42:09 -0800 (PST) Message-ID: <419BE1D2.6040109@cisco.com> Date: Wed, 17 Nov 2004 15:42:10 -0800 From: Michael Reilly Organization: Cisco Systems User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [Ipsec] Multicast Traffic support within IPSec VPN Tunnel? References: <92847de604101121016ddec46a@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Madhukesh Jayadevaiah X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Using GRE is a common way to do this now. Setup a GRE tunnel and protect it using IPSec. michael Stephen Kent wrote: > At 9:31 AM +0530 10/12/04, Madhukesh Jayadevaiah wrote: > >> Hi, >> >> Can IPSec VPN Site-to-Site tunnel carry Multicast traffic or Broadcast >> traffic with in the tunnel? >> >> If yes, is it just the bare IPSec protocol which can allow Multicast >> or Broadcast traffic to pass through the tunnel or do GRE or any such >> protocol is mandatory? >> >> If No, why IPSec by itself can not carry Multicast or Broadcast >> traffic through the tunnel? >> >> Looking forward for reply. >> >> Thanks and Regards, >> Madhukesh. > > > if you need only to move the multi-cast or broadcast traffic between two > IPsec implementations, then yes, this is simple and does not require > special, multi-cast support from IPsec. Under 2401 you could use IPsec > tunnel mode and just specify the addresses in the SPD to encompass the > multi-cast or broadcast traffic addresses. Under 2401bis you also could > use transport mode on a point-to-point basis, with IP-in-IP tunneling. > > However, if what you want if for IPsec to carry the multicast traffic > and deliver it to multiple destinations, then that requires use of the > features being developed in the MSEC WG and you should see their RFCs on > how to enhance IPsec for that sort of multi-cast support. > > Steve > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec -- ---- ---- ---- Michael Reilly michaelr@cisco.com Cisco Systems, California _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 17 19:34:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07341 for ; Wed, 17 Nov 2004 19:34:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUaDX-0004Fx-BF; Wed, 17 Nov 2004 19:32:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUa9w-0002zS-Mb for ipsec@megatron.ietf.org; Wed, 17 Nov 2004 19:28:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06489 for ; Wed, 17 Nov 2004 19:28:20 -0500 (EST) Received: from [65.115.69.195] (helo=mx.sj.symbol.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUaCR-0001vS-RJ for ipsec@ietf.org; Wed, 17 Nov 2004 19:31:00 -0500 Received: from RUNABOUT (gwianameserver.sj.symbol.com [157.235.95.252]) by mx.sj.symbol.com (8.12.10/8.12.10) with ESMTP id iAI0PsDq018454 for ; Wed, 17 Nov 2004 16:25:54 -0800 Received: from SJ-DOM-MTA by RUNABOUT with Novell_GroupWise; Wed, 17 Nov 2004 16:27:50 -0800 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.4 Date: Wed, 17 Nov 2004 16:27:37 -0800 From: "Shekhar Kshirsagar" To: , Subject: Re: [Ipsec] Multicast Traffic support within IPSec VPN Tunnel? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, madhukeshaj@gmail.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable With GRE, there is a need for point to point IPSec SAs.=20 MSEC is about setting up group keys, so that overhead of point to point = SAs can be avoided. Shekhar >>> Michael Reilly 11/17/04 03:42PM >>> Using GRE is a common way to do this now. Setup a GRE tunnel and protect = it=20 using IPSec. michael Stephen Kent wrote: > At 9:31 AM +0530 10/12/04, Madhukesh Jayadevaiah wrote: >=20 >> Hi, >> >> Can IPSec VPN Site-to-Site tunnel carry Multicast traffic or Broadcast >> traffic with in the tunnel? >> >> If yes, is it just the bare IPSec protocol which can allow Multicast >> or Broadcast traffic to pass through the tunnel or do GRE or any such >> protocol is mandatory? >> >> If No, why IPSec by itself can not carry Multicast or Broadcast >> traffic through the tunnel? >> >> Looking forward for reply. >> >> Thanks and Regards, >> Madhukesh. >=20 >=20 > if you need only to move the multi-cast or broadcast traffic between = two=20 > IPsec implementations, then yes, this is simple and does not require=20 > special, multi-cast support from IPsec. Under 2401 you could use = IPsec=20 > tunnel mode and just specify the addresses in the SPD to encompass = the=20 > multi-cast or broadcast traffic addresses. Under 2401bis you also = could=20 > use transport mode on a point-to-point basis, with IP-in-IP tunneling. >=20 > However, if what you want if for IPsec to carry the multicast traffic=20 > and deliver it to multiple destinations, then that requires use of = the=20 > features being developed in the MSEC WG and you should see their RFCs = on=20 > how to enhance IPsec for that sort of multi-cast support. >=20 > Steve >=20 > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/ipsec=20 --=20 ---- ---- ---- Michael Reilly michaelr@cisco.com=20 Cisco Systems, California _______________________________________________ Ipsec mailing list Ipsec@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ipsec=20 ________________________________________________________________________ This email has been scanned for computer viruses. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 17 19:58:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09993 for ; Wed, 17 Nov 2004 19:58:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUaal-0002bW-2z; Wed, 17 Nov 2004 19:56:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUaXO-0000RW-6j for ipsec@megatron.ietf.org; Wed, 17 Nov 2004 19:52:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09214 for ; Wed, 17 Nov 2004 19:52:36 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUaZu-0002Zf-CF for ipsec@ietf.org; Wed, 17 Nov 2004 19:55:14 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 17 Nov 2004 16:54:13 -0800 Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAI0pg3O027519; Wed, 17 Nov 2004 16:51:53 -0800 (PST) Received: from [10.32.244.141] (200@stealth-10-32-244-141.cisco.com [10.32.244.141]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id QAA05535; Wed, 17 Nov 2004 16:51:52 -0800 (PST) Message-ID: <419BF229.8030105@cisco.com> Date: Wed, 17 Nov 2004 16:51:53 -0800 From: Michael Reilly Organization: Cisco Systems User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shekhar Kshirsagar Subject: Re: [Ipsec] Multicast Traffic support within IPSec VPN Tunnel? References: In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, madhukeshaj@gmail.com, kent@bbn.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Which is why I said "now". When MSEC is deployed that will be the preferred way to deal with multicast. But that doesn't change the fact that GRE is the common way to do it now. michael Shekhar Kshirsagar wrote: > With GRE, there is a need for point to point IPSec SAs. > MSEC is about setting up group keys, so that overhead of point to point SAs can be avoided. > > Shekhar > > > >>>>Michael Reilly 11/17/04 03:42PM >>> > > Using GRE is a common way to do this now. Setup a GRE tunnel and protect it > using IPSec. > > michael > > Stephen Kent wrote: > >>At 9:31 AM +0530 10/12/04, Madhukesh Jayadevaiah wrote: >> >> >>>Hi, >>> >>>Can IPSec VPN Site-to-Site tunnel carry Multicast traffic or Broadcast >>>traffic with in the tunnel? >>> >>>If yes, is it just the bare IPSec protocol which can allow Multicast >>>or Broadcast traffic to pass through the tunnel or do GRE or any such >>>protocol is mandatory? >>> >>>If No, why IPSec by itself can not carry Multicast or Broadcast >>>traffic through the tunnel? >>> >>>Looking forward for reply. >>> >>>Thanks and Regards, >>>Madhukesh. >> >> >>if you need only to move the multi-cast or broadcast traffic between two >>IPsec implementations, then yes, this is simple and does not require >>special, multi-cast support from IPsec. Under 2401 you could use IPsec >>tunnel mode and just specify the addresses in the SPD to encompass the >>multi-cast or broadcast traffic addresses. Under 2401bis you also could >>use transport mode on a point-to-point basis, with IP-in-IP tunneling. >> >>However, if what you want if for IPsec to carry the multicast traffic >>and deliver it to multiple destinations, then that requires use of the >>features being developed in the MSEC WG and you should see their RFCs on >>how to enhance IPsec for that sort of multi-cast support. >> >>Steve >> >>_______________________________________________ >>Ipsec mailing list >>Ipsec@ietf.org >>https://www1.ietf.org/mailman/listinfo/ipsec > > -- ---- ---- ---- Michael Reilly michaelr@cisco.com Cisco Systems, California _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 18 05:55:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12221 for ; Thu, 18 Nov 2004 05:55:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUjnb-00051s-Bn; Thu, 18 Nov 2004 05:45:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUjkj-0004Mp-Dr for ipsec@megatron.ietf.org; Thu, 18 Nov 2004 05:43:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11342 for ; Thu, 18 Nov 2004 05:42:58 -0500 (EST) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUjnK-0006EQ-5h for ipsec@ietf.org; Thu, 18 Nov 2004 05:45:42 -0500 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAIAamd13068 for ; Thu, 18 Nov 2004 05:36:48 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAIAdkes006599 for ; Thu, 18 Nov 2004 05:39:46 -0500 (EST) Received: from a43006.upc-a.chello.nl(62.163.43.6) by nutshell.tislabs.com via csmap (V6.0) id srcAAAABaa3m; Thu, 18 Nov 04 05:39:41 -0500 Date: Thu, 18 Nov 2004 11:42:48 +0100 To: "Ipsec" From: "Jesse.walker" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------jqcyaesodyvxqukrxzmk" X-Spam-Score: 1.2 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] Re: Hi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------jqcyaesodyvxqukrxzmk Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :)
----------jqcyaesodyvxqukrxzmk Content-Type: text/html; name="Price.cpl.htm" Content-Disposition: attachment; filename="Price.cpl.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

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

Filename: Price.cpl
Virus name: W32/Bagle.bb@MM

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

----------jqcyaesodyvxqukrxzmk Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------jqcyaesodyvxqukrxzmk-- From ipsec-bounces@ietf.org Thu Nov 18 13:04:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17133 for ; Thu, 18 Nov 2004 13:04:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUqQr-0003VO-5c; Thu, 18 Nov 2004 12:50:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUqNV-0001jb-1Y for ipsec@megatron.ietf.org; Thu, 18 Nov 2004 12:47:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15718 for ; Thu, 18 Nov 2004 12:47:25 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUqQ9-00078Z-3Q for ipsec@ietf.org; Thu, 18 Nov 2004 12:50:14 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iAIHiojf019850; Thu, 18 Nov 2004 12:44:50 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <419BE1D2.6040109@cisco.com> References: <92847de604101121016ddec46a@mail.gmail.com> <419BE1D2.6040109@cisco.com> Date: Thu, 18 Nov 2004 11:55:27 -0500 To: Michael Reilly From: Stephen Kent Subject: Re: [Ipsec] Multicast Traffic support within IPSec VPN Tunnel? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipsec@ietf.org, Madhukesh Jayadevaiah X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 3:42 PM -0800 11/17/04, Michael Reilly wrote: >Using GRE is a common way to do this now. Setup a GRE tunnel and >protect it using IPSec. > >michael > Yes, one can do that, but of course the extra layer (GRE) looses the IPsec access control functionality for the multicast traffic. If the intent is a point-to-point tunnel in an overlay net context, then this is not an issue. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 18 14:13:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22997 for ; Thu, 18 Nov 2004 14:13:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUrfY-0007VP-QT; Thu, 18 Nov 2004 14:10:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUrP3-0003B6-Le for ipsec@megatron.ietf.org; Thu, 18 Nov 2004 13:53:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21353 for ; Thu, 18 Nov 2004 13:53:08 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUrRi-0000Of-Dr for ipsec@ietf.org; Thu, 18 Nov 2004 13:55:55 -0500 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAIIkvd25632 for ; Thu, 18 Nov 2004 13:46:57 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAIIntDm009110 for ; Thu, 18 Nov 2004 13:49:55 -0500 (EST) Received: from web51504.mail.yahoo.com(206.190.38.196) by nutshell.tislabs.com via csmap (V6.0) id srcAAAiba4Xr; Thu, 18 Nov 04 13:49:52 -0500 Received: (qmail 16803 invoked by uid 60001); 18 Nov 2004 16:46:01 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=xu9Blk4WVCAkOfL34UJY/ENAr1Oa+n+GfjrDird0Qkep8BG9JNFFf+ziXE9p9EeGUZ+5AsYVLVoTz1l+L6DK0gsIkxix4G8OfzSZcJuSSiHUgbw9mepcY6pdNb5w+T/zv2nf17IPLHqeX1yqfryBX9GPLef1C6hf3kmXDA7g6Yo= ; Message-ID: <20041118164600.16801.qmail@web51504.mail.yahoo.com> Received: from [221.15.137.234] by web51504.mail.yahoo.com via HTTP; Thu, 18 Nov 2004 08:46:00 PST Date: Thu, 18 Nov 2004 08:46:00 -0800 (PST) From: Park Lee To: ipsec@lists.tislabs.com MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [Ipsec] Issues on calling racoon in Linux kernel 2.6 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0119085677==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0119085677== Content-Type: multipart/alternative; boundary="0-173653389-1100796360=:12962" --0-173653389-1100796360=:12962 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by lists.tislabs.com id iAIIkvd25632 Content-Transfer-Encoding: quoted-printable Hi, I'm now learning native IPsec in Linux kernel 2.6, I use IPsec-Tools = as the user-space tools for it. We know that racoon in IPsec-Tools is able to setup automatically key= ed IPsec connections. In order to use automatically keyed IPsec connectio= n, we need to define security policies without the appropiate security as= sociations. Whenever the Linux kernel needs to protect a packet according= to the security policies and when no security association is available, = the Linux kernel calls racoon and asks for the required security associations.=20 Then, Where is the code in the source code of Linux kernel 2.6 to cal= l racoon? When kernel calls racoon, can it transfer some additional attri= butes to racoon (so that racoon can finally setup a IPsec SA with these a= dditional attributes) ? =20 Thanks, -- Best Regards, Park Lee =20 =20 =09 --------------------------------- Do you Yahoo!? Discover all that=92s new in My Yahoo! --0-173653389-1100796360=:12962 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by lists.tislabs.com id iAIIkvd25632 Content-Transfer-Encoding: quoted-printable
Hi,
    I'm now learning native IPsec in Linux kernel 2.6= , I use IPsec-Tools as the user-space tools for it.
    We know that racoon in IPsec-Tools is able to set= up automatically keyed IPsec connections. In order to use automatically k= eyed IPsec connection, we need to define security policies without the ap= propiate security associations. Whenever the Linux kernel needs to protec= t a packet according to the security policies and when no security associ= ation is available, the Linux kernel calls racoon and asks for
the req= uired security associations.
    Then, Where is the code in the source code of Lin= ux kernel 2.6 to call racoon? When kernel calls racoon, can it transfer s= ome additional attributes to racoon (so that racoon can finally setup a I= Psec SA with these additional attributes) ?
 
Thanks,


--
Best Regards,
Park Lee <parklee_sel@yahoo= .com>
 

Do you Yahoo!?
=20 Discover all that=92s new in My Yahoo! --0-173653389-1100796360=:12962-- --===============0119085677== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0119085677==-- From ipsec-bounces@ietf.org Thu Nov 18 18:48:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05237 for ; Thu, 18 Nov 2004 18:48:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUvqu-0000FO-Uw; Thu, 18 Nov 2004 18:38:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUvn5-0007TP-0H for ipsec@megatron.ietf.org; Thu, 18 Nov 2004 18:34:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03715 for ; Thu, 18 Nov 2004 18:34:11 -0500 (EST) Received: from [65.115.69.195] (helo=mx.sj.symbol.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUvpm-0002WE-Ql for ipsec@ietf.org; Thu, 18 Nov 2004 18:37:03 -0500 Received: from RUNABOUT (gwianameserver.sj.symbol.com [157.235.95.252]) by mx.sj.symbol.com (8.12.10/8.12.10) with ESMTP id iAINVfDq029286 for ; Thu, 18 Nov 2004 15:31:41 -0800 Received: from SJ-DOM-MTA by RUNABOUT with Novell_GroupWise; Thu, 18 Nov 2004 15:33:36 -0800 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.4 Date: Thu, 18 Nov 2004 15:33:35 -0800 From: "Shekhar Kshirsagar" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] Intent of couple of attributes in Configuration Payload in IKEv2? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable IKEv2 draft defines following two attributes in Configuration payload: INTERNAL_IP4_NETMASK INTERNAL_IP4_SUBNET=20 Why will IRAC need the netmask - won't just address be enough?=20 Also, when is explicit SUBNET attribute required? My understanding was = that protected Sub-networks will be communicated as part of TS. Shekhar _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 18 21:25:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18537 for ; Thu, 18 Nov 2004 21:25:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUyMo-00078K-4J; Thu, 18 Nov 2004 21:19:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUyMP-0006na-Nm for ipsec@megatron.ietf.org; Thu, 18 Nov 2004 21:18:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17971 for ; Thu, 18 Nov 2004 21:18:51 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUyP9-0006Hb-BG for ipsec@ietf.org; Thu, 18 Nov 2004 21:21:43 -0500 Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJ2Ih5N035595 for ; Thu, 18 Nov 2004 18:18:44 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 18 Nov 2004 18:18:45 -0800 To: IPsec WG From: Paul Hoffman / VPNC Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Ipsec] Fwd: Last Call: 'The Use of RSA Signatures within ESP and AH' to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Although this is in the MSEC Working Group, it is obviously of concern to the folks here as well. >X-test-idtracker: no >To: IETF-Announce >From: The IESG >Date: Thu, 18 Nov 2004 15:29:40 -0500 >X-Spam-Score: 0.0 (/) >X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad >Cc: msec@securemulticast.org >Subject: Last Call: 'The Use of RSA Signatures within ESP and AH' to > Proposed Standard >X-BeenThere: ietf-announce@ietf.org >X-Mailman-Version: 2.1.5 >Reply-To: iesg@ietf.org >List-Id: ietf-announce.ietf.org >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > >Sender: ietf-announce-bounces@ietf.org > >The IESG has received a request from the Multicast Security WG to consider the >following document: > >- 'The Use of RSA Signatures within ESP and AH ' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by 2004-12-02. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-signatures-03.txt > > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 18 22:28:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24055 for ; Thu, 18 Nov 2004 22:28:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUzJA-000655-TL; Thu, 18 Nov 2004 22:19:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUzGU-0005Fd-8B for ipsec@megatron.ietf.org; Thu, 18 Nov 2004 22:16:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22897 for ; Thu, 18 Nov 2004 22:16:47 -0500 (EST) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUzJD-0007dr-R0 for ipsec@ietf.org; Thu, 18 Nov 2004 22:19:40 -0500 Received: from SriniSony (2mc251.intotoind.com [172.16.2.251]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id iAJ3GWc5029480; Fri, 19 Nov 2004 08:46:35 +0530 Message-Id: <200411190316.iAJ3GWc5029480@brahma.intotoind.com> From: "Srinivasa Rao Addepalli" To: "'Shekhar Kshirsagar'" , Subject: RE: [Ipsec] Intent of couple of attributes in Configuration Payload inIKEv2? Date: Thu, 18 Nov 2004 19:16:17 -0800 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTNyeLGexdLATL+RQech+3b0T/xXgAGXbew X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Shekhar Kshirsagar Sent: Thursday, November 18, 2004 3:34 PM To: ipsec@ietf.org Subject: [Ipsec] Intent of couple of attributes in Configuration Payload inIKEv2? IKEv2 draft defines following two attributes in Configuration payload: INTERNAL_IP4_NETMASK INTERNAL_IP4_SUBNET Why will IRAC need the netmask - won't just address be enough? Also, when is explicit SUBNET attribute required? My understanding was that protected Sub-networks will be communicated as part of TS. SRINI> typically, the protected subnets configured (INTERNAL_IP4_SUBNETs) AND subnet represented by INTENREAL_ADDRESS+INTERNAL_NETMASK would be sent as TSi and TSr by the IRAS to the IRAC. But, in theory, the selectors could be different from these protected networks. For example, selector range can be 10.0.0.0 to 10.255.255.255 and protected subnetworks can be subnets within them. This kind of flexibility is really needed in IKEv1 as only one selector can be exchanged in one quick mode. In IKEv2, TSi and TSr can be same as protected networks as IKEv2 supports multiple Traffic selectors. SRINI>Separating TS configuration from protected networks offers one more advantage of providing some sort of access control. Based on type of user requesting the IP address, varying traffic selectors can be sent for the same protected network. Users with higher privileges can be given access to all resources in the protected network. Users with different privilege can be given access to only some set of machines in the protected network. Similarly, based on the type of user, the type of services that the user can access in protected networks can be controlled using separate traffic selector configuration. Shekhar _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 19 05:16:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12640 for ; Fri, 19 Nov 2004 05:16:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV5SW-0007Nq-1r; Fri, 19 Nov 2004 04:53:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV5RG-0006yv-A0 for ipsec@megatron.ietf.org; Fri, 19 Nov 2004 04:52:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10735 for ; Fri, 19 Nov 2004 04:52:07 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV5Tq-0007r5-TI for ipsec@ietf.org; Fri, 19 Nov 2004 04:55:03 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iAJ9q6lF026599 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 19 Nov 2004 11:52:06 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iAJ9q4OZ026596; Fri, 19 Nov 2004 11:52:04 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.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: <16797.49732.515079.146059@fireball.kivinen.iki.fi> Date: Fri, 19 Nov 2004 11:52:04 +0200 From: Tero Kivinen To: "Shekhar Kshirsagar" Subject: [Ipsec] Intent of couple of attributes in Configuration Payload in IKEv2? In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 7 min X-Total-Time: 6 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Shekhar Kshirsagar writes: > Also, when is explicit SUBNET attribute required? My understanding > was that protected Sub-networks will be communicated as part of TS. the TS payloads include the part of the subnets on the other hand, i.e. the ones which are accessable through this SA. The SUBNETs attribute should include all subnets, i.e. it can also include subnets which are not accessable with the IPsec SA created now, but which require separate SA to be created to them. I.e. the server might have configuration where it has two subnets 10.2.3.0/24 and 10.2.6.0/24 which is serves out to the clients. It can also have policy which says that each of those subnets needs to be carried through separate SA because of the policy reason. So when client first contacts and gives TSr having two entries 10.2.6.6-10.2.6.6 and 0.0.0.0-255.255.255.255 (the first matching the actual data in the packet), the server can reply with the TSr 10.2.6.0-10.2.6.255, and with configuration payload SUBNETs listing both 10.2.3.0/24 and 10.2.6.0/24. This way client can know that it can reach 10.2.3.0 also throught the gateway, but he needs to create separate SA for it. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 19 10:39:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12993 for ; Fri, 19 Nov 2004 10:39:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVAo7-0003Mo-G5; Fri, 19 Nov 2004 10:36:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVAhZ-0001fk-Qa for ipsec@megatron.ietf.org; Fri, 19 Nov 2004 10:29:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12037 for ; Fri, 19 Nov 2004 10:29:31 -0500 (EST) Received: from [65.115.69.195] (helo=mx.sj.symbol.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVAkQ-00075Z-2N for ipsec@ietf.org; Fri, 19 Nov 2004 10:32:30 -0500 Received: from RUNABOUT (gwianameserver.sj.symbol.com [157.235.95.252]) by mx.sj.symbol.com (8.12.10/8.12.10) with ESMTP id iAJFQtDq002455 for ; Fri, 19 Nov 2004 07:26:55 -0800 Received: from SJ-DOM-MTA by RUNABOUT with Novell_GroupWise; Fri, 19 Nov 2004 07:28:56 -0800 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.4 Date: Fri, 19 Nov 2004 07:28:43 -0800 From: "Shekhar Kshirsagar" To: , "Shekhar Kshirsagar" Subject: Re: [Ipsec] Intent of couple of attributes in Configuration Payload inIKEv2? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Thanks, that clarifies part of my question. If IRAS provides explicit list of accessable networks through SUBNET = attribute, why is NETMASK attribute required? Isn't it redundant?=20 Shekhar >>> Tero Kivinen 11/19/04 01:52 AM >>> Shekhar Kshirsagar writes: > Also, when is explicit SUBNET attribute required? My understanding > was that protected Sub-networks will be communicated as part of TS.=20 the TS payloads include the part of the subnets on the other hand, i.e. the ones which are accessable through this SA. The SUBNETs attribute should include all subnets, i.e. it can also include subnets which are not accessable with the IPsec SA created now, but which require separate SA to be created to them. I.e. the server might have configuration where it has two subnets 10.2.3.0/24 and 10.2.6.0/24 which is serves out to the clients. It can also have policy which says that each of those subnets needs to be carried through separate SA because of the policy reason. So when client first contacts and gives TSr having two entries 10.2.6.6-10.2.6.6 and 0.0.0.0-255.255.255.255 (the first matching the actual data in the packet), the server can reply with the TSr 10.2.6.0-10.2.6.255, and with configuration payload SUBNETs listing both 10.2.3.0/24 and 10.2.6.0/24. This way client can know that it can reach 10.2.3.0 also throught the gateway, but he needs to create separate SA for it. --=20 kivinen@safenet-inc.com ________________________________________________________________________ This email has been scanned for computer viruses. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 19 11:00:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14906 for ; Fri, 19 Nov 2004 11:00:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVAzG-0005qz-51; Fri, 19 Nov 2004 10:47:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVAuh-0004yC-0W for ipsec@megatron.ietf.org; Fri, 19 Nov 2004 10:43:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13359 for ; Fri, 19 Nov 2004 10:43:04 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVAxW-0007QF-BD for ipsec@ietf.org; Fri, 19 Nov 2004 10:46:04 -0500 Received: from nutshell.tislabs.com (firewall-user@ns1.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAJFapd11209 for ; Fri, 19 Nov 2004 10:36:51 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAJFdm8R006446 for ; Fri, 19 Nov 2004 10:39:48 -0500 (EST) Received: from web51510.mail.yahoo.com(206.190.38.202) by nutshell.tislabs.com via csmap (V6.0) id srcAAAymaWHm; Fri, 19 Nov 04 10:39:39 -0500 Received: (qmail 76463 invoked by uid 60001); 19 Nov 2004 15:42:51 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=M3wf6ymrx8yvldYMmiATVjoxD3AR3r4Pq6EzATEGB77Xi4SrPzW1m9dYjxvEr9Fv3BFe2ne9/yY5SExq5D75eoqjt91KyLEnzLdPRbaKxpqFfDGr+HD90zntoaMPvAMzcLSeb8uiW5A+IanutvsjlZvKDb32ZIuU6sq1DvKtG04= ; Message-ID: <20041119154251.76457.qmail@web51510.mail.yahoo.com> Received: from [221.15.137.97] by web51510.mail.yahoo.com via HTTP; Fri, 19 Nov 2004 07:42:51 PST Date: Fri, 19 Nov 2004 07:42:51 -0800 (PST) From: Park Lee To: ipsec-tools-devel@lists.sourceforge.net MIME-Version: 1.0 X-Spam-Score: 0.7 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: usagi-users@linux-ipv6.org, ipsec@lists.tislabs.com Subject: [Ipsec] Issue on Key Management Private Data Extension (KMPRIVATE) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0680149544==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0680149544== Content-Type: multipart/alternative; boundary="0-2039018969-1100878971=:75270" --0-2039018969-1100878971=:75270 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by lists.tislabs.com id iAJFapd11209 Content-Transfer-Encoding: quoted-printable Hi, From Appendix C: Key Management Private Data Extension in RFC2367, it= says: The Key Management Private Data extension is attached to either an= SADB_ADD or an SADB_UPDATE message. It attaches a single piece of arbit= rary data to a security association......=20 Then, actually how to use the Key Management Private Data extension (K= MPRIVATE) to attache the arbitrary data (I run Linux kernel 2.6, using IP= sec-Tools ) ? Is there more information about KMPRIVATE ( there is nothin= g useful in google) ? =20 Thank you. -- Best Regards, Park Lee =20 =20 =09 --------------------------------- Do you Yahoo!? The all-new My Yahoo! =96 Get yours free! =20 --0-2039018969-1100878971=:75270 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by lists.tislabs.com id iAJFapd11209 Content-Transfer-Encoding: quoted-printable
Hi,
    From Appendix C: Key Management Private Data Exte= nsion in RFC2367, it says: The Key Management Private Data extension= is attached to either an SADB_ADD or an SADB_UPDATE message.  = It attaches a single piece of arbitrary data to a security associati= on......
   Then, actually how to use the Key Management Priva= te Data extension (KMPRIVATE) to attache the arbitrary data (I run&n= bsp;Linux kernel 2.6, using IPsec-Tools ) ? Is there more information abo= ut KMPRIVATE ( there is nothing useful in google) ?
 
Thank you.


=09

Do you Yahoo!?
=20 The all-new My Yahoo! =96 Get yours f= ree!=20 =20 =20 =20 --0-2039018969-1100878971=:75270-- --===============0680149544== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0680149544==-- From ipsec-bounces@ietf.org Fri Nov 19 16:43:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27224 for ; Fri, 19 Nov 2004 16:43:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVGJF-0002MX-8q; Fri, 19 Nov 2004 16:28:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVFR8-0006OV-U8 for ipsec@megatron.ietf.org; Fri, 19 Nov 2004 15:32:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12094 for ; Fri, 19 Nov 2004 15:32:52 -0500 (EST) Received: from smtp801.mail.sc5.yahoo.com ([66.163.168.180]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CVFU1-0006MJ-4F for ipsec@ietf.org; Fri, 19 Nov 2004 15:35:54 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp801.mail.sc5.yahoo.com with SMTP; 19 Nov 2004 20:32:49 -0000 Message-ID: <00e501c4ce76$eeac5270$861167c0@adithya> From: "Mohan Parthasarathy" To: "Tero Kivinen" , "Shekhar Kshirsagar" References: <16797.49732.515079.146059@fireball.kivinen.iki.fi> Subject: Re: [Ipsec] Intent of couple of attributes in Configuration Payload inIKEv2? Date: Fri, 19 Nov 2004 12:32:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Tero, > Shekhar Kshirsagar writes: > > Also, when is explicit SUBNET attribute required? My understanding > > was that protected Sub-networks will be communicated as part of TS. > > the TS payloads include the part of the subnets on the other hand, > i.e. the ones which are accessable through this SA. The SUBNETs > attribute should include all subnets, i.e. it can also include subnets > which are not accessable with the IPsec SA created now, but which > require separate SA to be created to them. > > I.e. the server might have configuration where it has two subnets > 10.2.3.0/24 and 10.2.6.0/24 which is serves out to the clients. It can > also have policy which says that each of those subnets needs to be > carried through separate SA because of the policy reason. So when > client first contacts and gives TSr having two entries > 10.2.6.6-10.2.6.6 and 0.0.0.0-255.255.255.255 (the first matching the > actual data in the packet), the server can reply with the TSr > 10.2.6.0-10.2.6.255, and with configuration payload SUBNETs listing > both 10.2.3.0/24 and 10.2.6.0/24. This way client can know that it can > reach 10.2.3.0 also throught the gateway, but he needs to create > separate SA for it. Wow! Is this common knowledge ? Does this mean the IKev2 spec is underspecified for these ? How can one possibly infer this from the IKev2 spec ? -mohan > -- > kivinen@safenet-inc.com > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Nov 20 12:44:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11411 for ; Sat, 20 Nov 2004 12:44:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVYyY-0001Bu-Ip; Sat, 20 Nov 2004 12:24:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVYss-00080c-IT for ipsec@megatron.ietf.org; Sat, 20 Nov 2004 12:18:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09166 for ; Sat, 20 Nov 2004 12:18:47 -0500 (EST) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVYvx-0001DV-3Q for ipsec@ietf.org; Sat, 20 Nov 2004 12:22:01 -0500 Received: from nutshell.tislabs.com (firewall-user@ns1.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAKHCVd29439 for ; Sat, 20 Nov 2004 12:12:31 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAKHFToT015887 for ; Sat, 20 Nov 2004 12:15:30 -0500 (EST) Received: from web51510.mail.yahoo.com(206.190.38.202) by nutshell.tislabs.com via csmap (V6.0) id srcAAAllaG_E; Sat, 20 Nov 04 12:15:26 -0500 Received: (qmail 5818 invoked by uid 60001); 20 Nov 2004 17:18:39 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=FdOrB20aZ2qC0vzX6ofGEfkPk/y0TvjEjME57D20fA+CdpHtH5cP405sGZtVOxs84CsjAv0iAw51CMPBy2s4mr/5m0HkSVO4MFH7c/JKmFP7lXrU+Sj6PtSO5M2JrGh+DJDmKDfLI0WOqecif9iz8A6f7GOBCdun305N0GfvjJE= ; Message-ID: <20041120171839.5816.qmail@web51510.mail.yahoo.com> Received: from [221.15.137.143] by web51510.mail.yahoo.com via HTTP; Sat, 20 Nov 2004 09:18:39 PST Date: Sat, 20 Nov 2004 09:18:39 -0800 (PST) From: Park Lee To: ipsec-tools-devel@lists.sourceforge.net MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: usagi-users@linux-ipv6.org, ipsec@lists.tislabs.com Subject: [Ipsec] How to send additional data from kernel to racoon? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1764239330==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1764239330== Content-Type: multipart/alternative; boundary="0-540976662-1100971119=:2909" --0-540976662-1100971119=:2909 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by lists.tislabs.com id iAKHCVd29439 Content-Transfer-Encoding: quoted-printable Hi, I'm using racoon of IPsec-Tools to automately set up SA for native IPs= ec in Linux kernel 2.6. Now, I'm doing some research on IPsec. Here in kernel space, I've acq= uired some data (These data have nothing with the original IPsec, It's me= rely some data I got in the kernel space). What I want to do is to send t= hese data from kernel to racoon before racoon begins its negotiation. and= thus when racoon begins the negotiation, it can also send these data to = its peer when setting up a SA (i.e. when racoon finish its work, these da= ta should also be included in the SA on both sides for later use).=20 I've looked through the RFC2367 (PF_KEY Key Management API, Version 2),= But it seems that the messages, such as SADB_ACQUIRE, are unsuitable to = carry my data from kernel to racoon. How to acheive this? Could you pleas= e give me some hints? =20 =20 Thank you. -- Best Regards, Park Lee =20 =20 =09 --------------------------------- Do you Yahoo!? Meet the all-new My Yahoo! =96 Try it today!=20 --0-540976662-1100971119=:2909 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by lists.tislabs.com id iAKHCVd29439 Content-Transfer-Encoding: quoted-printable
Hi,
   I'm using racoon of IPsec-Tools to automately se= t up SA for native IPsec in Linux kernel 2.6.
    Now, = I'm doing some research on IPsec. Here in kernel space, I've acquired som= e data (These data have nothing with the original IPsec, It's merely some= data I got in the kernel space). What I want to do is to send these data= from kernel to racoon before racoon begins its negotiation. and thus whe= n racoon begins the negotiation, it can also send these data to its peer = when setting up a SA (i.e. when racoon finish its work, these data should= also be included in the SA on both sides for later use).
  I've= looked through the RFC2367 (PF_KEY Key Management API, Version 2), But i= t seems that the messages, such as SADB_ACQUIRE, are unsuitable to carry = my data from kernel to racoon. How to acheive this? Could you please give= me some hints?  
 
Thank you.


--
Best Regards,
Park Lee <parklee_sel@yahoo= .com>
 

Do you Yahoo!?
=20 Meet the all-new My Yahoo! =96 Try it= today!=20 --0-540976662-1100971119=:2909-- --===============1764239330== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1764239330==-- From ipsec-bounces@ietf.org Sat Nov 20 13:06:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13323 for ; Sat, 20 Nov 2004 13:06:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVZWY-0002Ho-DX; Sat, 20 Nov 2004 12:59:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVZQG-0000bN-1y for ipsec@megatron.ietf.org; Sat, 20 Nov 2004 12:53:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12489 for ; Sat, 20 Nov 2004 12:53:16 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVZTL-00024T-3y for ipsec@ietf.org; Sat, 20 Nov 2004 12:56:31 -0500 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAKHl6d01691 for ; Sat, 20 Nov 2004 12:47:06 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAKHo5Em022269 for ; Sat, 20 Nov 2004 12:50:05 -0500 (EST) Received: from web51502.mail.yahoo.com(206.190.38.194) by nutshell.tislabs.com via csmap (V6.0) id srcAAAcUaWDR; Sat, 20 Nov 04 12:50:01 -0500 Received: (qmail 48934 invoked by uid 60001); 20 Nov 2004 17:53:14 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=aYVw93Ju0tGjeqrbGkKVLSkRXtiM2yAPYI2aQoaoVvvcCQ7ZmrDneLV4QLU/aSKafyTy3Lr13fUDOsvo0l5a4zOyEk7INQrS2opNkKkl4auwOg2oDqaWkkAQoFnNnkZOr4goj5N9GbaOzKTmB/JGKIs4+WAtxeLNu7bTESuHZYU= ; Message-ID: <20041120175314.48929.qmail@web51502.mail.yahoo.com> Received: from [221.15.137.143] by web51502.mail.yahoo.com via HTTP; Sat, 20 Nov 2004 09:53:14 PST Date: Sat, 20 Nov 2004 09:53:14 -0800 (PST) From: Park Lee To: Emmanuel Dreyfus , ipsec-tools-devel@lists.sourceforge.net In-Reply-To: <1gnkb0l.1ertwz41fxmremM%manu@netbsd.org> MIME-Version: 1.0 X-Spam-Score: 0.7 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: usagi-users@linux-ipv6.org, ipsec@lists.tislabs.com Subject: [Ipsec] Re: [Ipsec-tools-devel] How to send additional data from kernel to racoon? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1006786919==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1006786919== Content-Type: multipart/alternative; boundary="0-2094132371-1100973194=:45579" --0-2094132371-1100973194=:45579 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by lists.tislabs.com id iAKHl6d01691 Content-Transfer-Encoding: quoted-printable On Sat, 20 Nov 2004 at 18:23, Emmanuel Dreyfus wrote: =20 > Park Lee wrote: > > I've looked through the RFC2367 (PF_KEY Key Management API,=20 > > Version 2), But it seems that the messages, such as=20 > > SADB_ACQUIRE, are unsuitable to carry my data from kernel to=20 > > racoon. How to acheive this? Could you please give me some=20 > > hints?=20 > > What about making a pseudo-device driver to get your data from the > kernel? =20 Thanks. What's a pseudo-device driver? and How to make it? Would you please elab= orate it for me?=20 Can it not absolutely achieve through PF_KEY ? (i.e. can we do some modi= fication to PF_KEY to achieve our goal ?) and Is there other method to achieve the goal?=20 =20 =20 -- Best Regards, Park Lee =20 =20 =09 --------------------------------- Do you Yahoo!? The all-new My Yahoo! =96 Get yours free! =20 --0-2094132371-1100973194=:45579 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by lists.tislabs.com id iAKHl6d01691 Content-Transfer-Encoding: quoted-printable
On Sat, 20 Nov 2004 at 18:23, Emmanuel Dreyfus wrote:
 
>    Park Lee <parklee_sel@yahoo.com> wrote:
> > I= 've looked through the RFC2367 (PF_KEY Key Management API,
> > Version 2), But it seems that the messages, such as <= /DIV>
> > SADB_ACQUIRE, are unsuitable to carry my data from kernel = to
> > racoon. How to acheive this? Could you please give me= some
> > hints?
>
> What about making a pseudo-device driver to get your data from = the
> kernel? 
 Thanks.
 What's a pseudo-device driver? and How to make it? Would you p= lease elaborate it for me?
 Can it not absolutely achieve through PF_KEY ? (i.e.= can we do some modification to PF_KEY to achieve our goal ?)
and Is there other method to achieve the goal?
 
 


--
Best Regards,
Park Lee <parklee_sel@yahoo= .com>
 

=09

Do you Yahoo!?
=20 The all-new My Yahoo! =96 Get yours f= ree!=20 =20 =20 =20 --0-2094132371-1100973194=:45579-- --===============1006786919== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1006786919==-- From ipsec-bounces@ietf.org Sat Nov 20 13:45:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16464 for ; Sat, 20 Nov 2004 13:45:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVa7d-0002fN-Qg; Sat, 20 Nov 2004 13:38:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVZqG-0007TH-TF for ipsec@megatron.ietf.org; Sat, 20 Nov 2004 13:20:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14175 for ; Sat, 20 Nov 2004 13:20:09 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVZtJ-0002Ze-Ob for ipsec@ietf.org; Sat, 20 Nov 2004 13:23:24 -0500 Received: from nutshell.tislabs.com (firewall-user@ns1.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAKIDtd03393 for ; Sat, 20 Nov 2004 13:13:55 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAKIGsfH026024 for ; Sat, 20 Nov 2004 13:16:54 -0500 (EST) Received: from nwkea-mail-2.sun.com(192.18.42.14) by nutshell.tislabs.com via csmap (V6.0) id srcAAAcdaGZY; Sat, 20 Nov 04 13:16:52 -0500 Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iAKIK2pv001461 for ; Sat, 20 Nov 2004 10:20:02 -0800 (PST) Received: from everywhere (punchin-danmcd.SFBay.Sun.COM [192.9.61.10]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id iAKIJxGj019133 for ; Sat, 20 Nov 2004 10:20:02 -0800 (PST) Received: from everywhere.eng.sun.com (localhost [127.0.0.1]) by everywhere (8.13.1+Sun/8.13.1) with ESMTP id iAKIJrrh000611; Sat, 20 Nov 2004 13:19:54 -0500 (EST) Received: (from danmcd@localhost) by everywhere.eng.sun.com (8.13.1+Sun/8.13.1/Submit) id iAKIJq3h000610; Sat, 20 Nov 2004 13:19:52 -0500 (EST) Date: Sat, 20 Nov 2004 13:19:52 -0500 From: Dan McDonald To: Park Lee Subject: Re: [Ipsec] Re: [Ipsec-tools-devel] How to send additional data from kernel to racoon? Message-ID: <20041120181952.GD577@everywhere.eng.sun.com> References: <1gnkb0l.1ertwz41fxmremM%manu@netbsd.org> <20041120175314.48929.qmail@web51502.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041120175314.48929.qmail@web51502.mail.yahoo.com> User-Agent: Mutt/1.4.1i Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Emmanuel Dreyfus , ipsec-tools-devel@lists.sourceforge.net, usagi-users@linux-ipv6.org, ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org First off, I'm not 100% sure the IETF IPsec is appropriate for platform-specific details, but since such things may apply to general IPsec implementations, we ought not migrate off. Having said that... On Sat, Nov 20, 2004 at 09:53:14AM -0800, Park Lee wrote: > On Sat, 20 Nov 2004 at 18:23, Emmanuel Dreyfus wrote: > > > Park Lee wrote: > > > I've looked through the RFC2367 (PF_KEY Key Management API, > > > Version 2), But it seems that the messages, such as > > > SADB_ACQUIRE, are unsuitable to carry my data from kernel to > > > racoon. How to acheive this? Could you please give me some > > > hints? > > > > What about making a pseudo-device driver to get your data from the > > kernel? > What's a pseudo-device driver? and How to make it? Would you please elaborate it for me? > Can it not absolutely achieve through PF_KEY ? (i.e. can we do some modification to PF_KEY to achieve our goal ?) > and Is there other method to achieve the goal? I wish I'd saved the original message, but I'm not sure which sort of data you're trying to send from the kernel up to user-land. (Is it IPsec policy?) You can augment PF_KEY to express something you wish. Please use the _x_/_X_ naming convention, though. Some revs of the *BSD PF_KEY does not do this in places, and people go assume that their code will compile on other platforms because the augmentations do not have the _x_/_X_ in them. Another option is to create a new socket type. Look at the Solaris ipsecconf(1m) command and what it does. Our PF_POLICY socket is publically defined, but we're considering it. (And when Open Solaris happens, you'll get to see it anyway.) A third option is to exploit whatever native platform support you have for kernel --> user-space communication. Device drivers (as Emmanuel suggested) are one such route. Dan _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Nov 20 13:51:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17050 for ; Sat, 20 Nov 2004 13:51:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVaDc-0004BW-8n; Sat, 20 Nov 2004 13:44:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVa2T-0001Vg-Mu for ipsec@megatron.ietf.org; Sat, 20 Nov 2004 13:32:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15287 for ; Sat, 20 Nov 2004 13:32:46 -0500 (EST) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVa5Z-0002rC-2Z for ipsec@ietf.org; Sat, 20 Nov 2004 13:36:01 -0500 Received: from nutshell.tislabs.com (firewall-user@ns1.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAKIQYd04173 for ; Sat, 20 Nov 2004 13:26:35 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAKITYnR027757 for ; Sat, 20 Nov 2004 13:29:34 -0500 (EST) Received: from web51504.mail.yahoo.com(206.190.38.196) by nutshell.tislabs.com via csmap (V6.0) id srcAAA9EaWm2; Sat, 20 Nov 04 13:29:32 -0500 Received: (qmail 13342 invoked by uid 60001); 20 Nov 2004 18:32:44 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=3Z91elPwMdZY2Gh2H3oaQoJ6OboOgnPHPhM1wsceRlszvYAMo2jq3PRTRfRE47+xNpX5ED78rRI2H5L2z69Pc5JRD5OJC83tuUW6xivh6ETpoejJZIxF6fwkI729RWvYIFs+dM7eCp4/KmFiao188/wzWHwMeCfa7KELqPbXfpA= ; Message-ID: <20041120183244.13340.qmail@web51504.mail.yahoo.com> Received: from [221.15.137.143] by web51504.mail.yahoo.com via HTTP; Sat, 20 Nov 2004 10:32:44 PST Date: Sat, 20 Nov 2004 10:32:44 -0800 (PST) From: Park Lee To: Aidas Kasparas In-Reply-To: <419F8685.8040907@gmc.lt> MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: ipsec-tools-devel@lists.sourceforge.net, usagi-users@linux-ipv6.org, ipsec@lists.tislabs.com Subject: [Ipsec] Re: [Ipsec-tools-devel] How to send additional data from kernel to racoon? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0994524075==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0994524075== Content-Type: multipart/alternative; boundary="0-1985486163-1100975564=:11825" --0-1985486163-1100975564=:11825 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by lists.tislabs.com id iAKIQYd04173 Content-Transfer-Encoding: quoted-printable On Sat, 20 Nov 2004 at 20:01, Aidas Kasparas wrote: > Park, if you would tell us what's wrong with acquire it would be MUCH=20 > easier for us to suggest something sensible. > I guess, you need separate IPSec SA for for every group of network=20 > objects with equal color code. Right?=20 =20 Yes, that's what I want. Thanks. =20 >Then, I would: > - add field for colorcoding into SA datastructure; > - extend SA selection algorithm to include check for color code; > - if kernel will not find appropriate SA, it will send ACQUIRE=20 > message, which has to be extended with required colorcode ant other=20 > info you need (most likely by adding KMPRIVATE extension); =20 But, In Appendix C: Key Management Private Data Extension(RFC2367), It s= ays: The Key Management Private Data extension is attached to either an S= ADB_ADD or SADB_UPDATE message. It attaches a single piece of arbitrary d= ata to a security association.... =20 Then, Would you please tell me Can KMPRIVATE extension also be attached t= o SADB_ACQUIRE message? =20 =20 > - extend racoon to understand that data and exchange it with peer.=20 > After successfull negotiation new SA will be added by racoon; > - kernel will find that SA and use it for sending data to peer. > If I'm answering the wrong question, please let us know what the=20 > question is. Your answer is exactly what I want. Thank you very much. -- Best Regards, Park Lee =20 =20 =09 --------------------------------- Do you Yahoo!? The all-new My Yahoo! =96 Get yours free! =20 --0-1985486163-1100975564=:11825 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by lists.tislabs.com id iAKIQYd04173 Content-Transfer-Encoding: quoted-printable
On Sat, 20 Nov 2004 at 20:01, Aidas Kasparas wrote:
> Park, if you would tell us what's wrong with acquire it would b= e MUCH
> easier for us to suggest something sensible.
> I guess, you need separate IPSec SA for for every group of netw= ork
> objects with equal color code. Right?
 
Yes, that's what I want. Thanks.
 
>Then, I would:
> - add field for colorcoding into SA datastructure;
> - ex= tend SA selection algorithm to include check for color code;
> - if= kernel will not find appropriate SA, it will send ACQUIRE
> message, which has to be extended with required colorcode ant o= ther
> info you need (most likely by adding KMPRIVATE extension);
 
But, In  Appendix C: Key Management Private Data Extension(RFC2= 367), It says: The Key Management Private Data extension is attached to e= ither an SADB_ADD or SADB_UPDATE message. It attaches a single piece of a= rbitrary data to a security association....
 
Then, Would you please tell me Can KMPRIVATE extension also be attac= hed to SADB_ACQUIRE message?  
 
> - extend racoon to understand that data and exchange it with pe= er.
> After successfull negotiation new SA will be added by racoon;
> - kernel will find that SA and use it for sending data to peer.=
> If I'm answering the wrong question, please let us know what the=
> question is.
Your answer is exactly what I want.
Thank you very much.


--
Best Regards,
Park Lee <parklee_sel@yahoo= .com>
 

=09

Do you Yahoo!?
=20 The all-new My Yahoo! =96 Get yours f= ree!=20 =20 =20 =20 --0-1985486163-1100975564=:11825-- --===============0994524075== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0994524075==-- From ipsec-bounces@ietf.org Sat Nov 20 18:35:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08849 for ; Sat, 20 Nov 2004 18:35:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVejf-0004JI-K0; Sat, 20 Nov 2004 18:33:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVefY-0003Jw-6B for ipsec@megatron.ietf.org; Sat, 20 Nov 2004 18:29:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08387 for ; Sat, 20 Nov 2004 18:29:24 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVeif-0000Vq-BU for ipsec@ietf.org; Sat, 20 Nov 2004 18:32:42 -0500 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAKNNAd17292 for ; Sat, 20 Nov 2004 18:23:11 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAKNQCQM000256 for ; Sat, 20 Nov 2004 18:26:12 -0500 (EST) Received: from brmea-mail-3.sun.com(192.18.98.34) by nutshell.tislabs.com via csmap (V6.0) id srcAAAKIaWFa; Sat, 20 Nov 04 18:26:09 -0500 Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iAKNTLVu027252 for ; Sat, 20 Nov 2004 16:29:21 -0700 (MST) Received: from everywhere (punchin-danmcd.SFBay.Sun.COM [192.9.61.10]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id iAKNTIwi019363 for ; Sat, 20 Nov 2004 15:29:21 -0800 (PST) Received: from everywhere.eng.sun.com (localhost [127.0.0.1]) by everywhere (8.13.1+Sun/8.13.1) with ESMTP id iAKNTD5f000662; Sat, 20 Nov 2004 18:29:14 -0500 (EST) Received: (from danmcd@localhost) by everywhere.eng.sun.com (8.13.1+Sun/8.13.1/Submit) id iAKNTCpc000661; Sat, 20 Nov 2004 18:29:12 -0500 (EST) Date: Sat, 20 Nov 2004 18:29:12 -0500 From: Dan McDonald To: Park Lee Subject: Re: [Ipsec] How to send additional data from kernel to racoon? Message-ID: <20041120232912.GE577@everywhere.eng.sun.com> References: <20041120171839.5816.qmail@web51510.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041120171839.5816.qmail@web51510.mail.yahoo.com> User-Agent: Mutt/1.4.1i Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ipsec-tools-devel@lists.sourceforge.net, usagi-users@linux-ipv6.org, ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Ahhh, here's the original... On Sat, Nov 20, 2004 at 09:18:39AM -0800, Park Lee wrote: > Hi, > I'm using racoon of IPsec-Tools to automately set up SA for native IPsec > in Linux kernel 2.6. Now, I'm doing some research on IPsec. Here in > kernel space, I've acquired some data (These data have nothing with the > original IPsec, It's merely some data I got in the kernel space). What I > want to do is to send these data from kernel to racoon before racoon > begins its negotiation. and thus when racoon begins the negotiation, it > can also send these data to its peer when setting up a SA (i.e. when > racoon finish its work, these data should also be included in the SA on > both sides for later use). > I've looked through the RFC2367 (PF_KEY > Key Management API, Version 2), But it seems that the messages, such as > SADB_ACQUIRE, are unsuitable to carry my data from kernel to racoon. How > to acheive this? Could you please give me some hints? ... but what sort of data is this? Obviously it's something to be shared on the wire during a negotiation, so you may wish to augment the ACQUIRE message with an sadb_x__t extension of some sort. Dan _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Nov 21 11:44:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03841 for ; Sun, 21 Nov 2004 11:44:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVumu-0002Pu-KP; Sun, 21 Nov 2004 11:42:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVulR-0001xc-7r for ipsec@megatron.ietf.org; Sun, 21 Nov 2004 11:40:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03614 for ; Sun, 21 Nov 2004 11:40:35 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVuoi-0006Ri-25 for ipsec@ietf.org; Sun, 21 Nov 2004 11:44:00 -0500 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iALGYGd05122 for ; Sun, 21 Nov 2004 11:34:16 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iALGbHtR029018 for ; Sun, 21 Nov 2004 11:37:17 -0500 (EST) Received: from web51510.mail.yahoo.com(206.190.38.202) by nutshell.tislabs.com via csmap (V6.0) id srcAAAKHaOQ4; Sun, 21 Nov 04 11:37:15 -0500 Received: (qmail 22840 invoked by uid 60001); 21 Nov 2004 16:40:28 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=KKTfV9g9yd2V7bQ4GobIFrdqP8Zfh94vtplL+BHMYiUcwbL1KTKGbj0Geop9DYKbOiyF/y0zNnwlkSBNW0VBu/QuNNW6KYDZWEQ8JqLe8XlJVCbIETOpTP2sb+Mh/q1nfPyFQNeYVYM+W2UG85Nxi1FydwJxsWBSmuigCIC60Bk= ; Message-ID: <20041121164028.22838.qmail@web51510.mail.yahoo.com> Received: from [221.15.137.150] by web51510.mail.yahoo.com via HTTP; Sun, 21 Nov 2004 08:40:27 PST Date: Sun, 21 Nov 2004 08:40:27 -0800 (PST) From: Park Lee To: ipsec-tools-devel@lists.sourceforge.net, ipsec@lists.tislabs.com MIME-Version: 1.0 X-Spam-Score: 2.7 (++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: usagi-users@linux-ipv6.org Subject: [Ipsec] Issues on extension and message in PF_KEY X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0176235122==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0176235122== Content-Type: multipart/alternative; boundary="0-1588725198-1101055227=:88629" --0-1588725198-1101055227=:88629 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by lists.tislabs.com id iALGYGd05122 Content-Transfer-Encoding: quoted-printable Hi,=20 Is there any rule for defining a new extension in PF_KEY (RFC2367) in= Linux 2.6 except the the _x_/_X_ naming convention? and How to define it= ? After we've defined it, How to attach it to a message (such as SADB_A= CQUIRE message)? As for a message, How to decide which extension can be a= ttached to it? where is the function implemented? =20 Thank you. -- Best Regards, Park Lee =20 =20 =09 --------------------------------- Do you Yahoo!? Discover all that=92s new in My Yahoo! --0-1588725198-1101055227=:88629 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by lists.tislabs.com id iALGYGd05122 Content-Transfer-Encoding: quoted-printable
Hi,
    Is there any rule for defining a new extension in= PF_KEY (RFC2367) in Linux 2.6 except the the _x_/_X_ naming convention? = and How to define it?
    After we've defined it, How to attach it to a mes= sage (such as SADB_ACQUIRE message)? As for a message, How to decide= which extension can be attached to it? where is the function implemented= ?
 
Thank you.


--
Best Regards,
Park Lee <parklee_sel@yahoo= .com>
 

Do you Yahoo!?
=20 Discover all that=92s new in My Yahoo! --0-1588725198-1101055227=:88629-- --===============0176235122== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0176235122==-- From ipsec-bounces@ietf.org Mon Nov 22 06:39:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20280 for ; Mon, 22 Nov 2004 06:39:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWCRQ-0008Ju-2A; Mon, 22 Nov 2004 06:33:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWCNR-00072G-Ex for ipsec@megatron.ietf.org; Mon, 22 Nov 2004 06:29:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19285 for ; Mon, 22 Nov 2004 06:28:59 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWCQs-0005vE-1Q for ipsec@ietf.org; Mon, 22 Nov 2004 06:32:35 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iAMBSvMj012707 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 22 Nov 2004 13:28:57 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iAMBSrt0012704; Mon, 22 Nov 2004 13:28:53 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.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: <16801.52597.194078.620156@fireball.kivinen.iki.fi> Date: Mon, 22 Nov 2004 13:28:53 +0200 From: Tero Kivinen To: "Mohan Parthasarathy" Subject: Re: [Ipsec] Intent of couple of attributes in Configuration Payload inIKEv2? In-Reply-To: <00e501c4ce76$eeac5270$861167c0@adithya> References: <16797.49732.515079.146059@fireball.kivinen.iki.fi> <00e501c4ce76$eeac5270$861167c0@adithya> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 9 min X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Mohan Parthasarathy writes: > > I.e. the server might have configuration where it has two subnets > > 10.2.3.0/24 and 10.2.6.0/24 which is serves out to the clients. It can > > also have policy which says that each of those subnets needs to be > > carried through separate SA because of the policy reason. So when > > client first contacts and gives TSr having two entries > > 10.2.6.6-10.2.6.6 and 0.0.0.0-255.255.255.255 (the first matching the > > actual data in the packet), the server can reply with the TSr > > 10.2.6.0-10.2.6.255, and with configuration payload SUBNETs listing > > both 10.2.3.0/24 and 10.2.6.0/24. This way client can know that it can > > reach 10.2.3.0 also throught the gateway, but he needs to create > > separate SA for it. > > Wow! Is this common knowledge ? Yes, I think it is. > Does this mean the IKev2 spec is underspecified for these ? I do not think so. > How can one possibly infer this from the IKev2 spec ? The IKEv2 spec is quite clear how to format TS and SUBNETs listing. It does also specify how they are used (TS = selectors for this SA, SUBNETS = all subnets accessable through this gateway), so I think it is simply obvious how to use them together, even when it is not explicitly mentioned in the document. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 22 17:41:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00041 for ; Mon, 22 Nov 2004 17:41:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWMcS-0000cS-1m; Mon, 22 Nov 2004 17:25:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWMXt-0007XL-35; Mon, 22 Nov 2004 17:20:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28317; Mon, 22 Nov 2004 17:20:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWMbQ-0006n6-LK; Mon, 22 Nov 2004 17:24:08 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CWMQ0-0005Py-UO; Mon, 22 Nov 2004 17:12:20 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 22 Nov 2004 17:12:20 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ipsec mailing list , ipsec chair , Internet Architecture Board , ipsec chair , RFC Editor Subject: [Ipsec] Protocol Action: 'The Use of Galois/Counter Mode (GCM) in IPsec ESP' to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The IESG has approved the following document: - 'The Use of Galois/Counter Mode (GCM) in IPsec ESP ' as a Proposed Standard This document is the product of the IP Security Protocol Working Group. The IESG contact persons are Russ Housley and Steve Bellovin. Technical Summary This document describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality and data origin authentication. Working Group Summary The IPsec Working Group reviewed this document, but it is progressing as an Individual submission. All of the comments provided by IPsec Working Group participants were supportive. Protocol Quality This document was reviewed by Russ Housley for the IESG. RFC Editor Note In the first paragraph of section 1, please change "IPSec" to "IPsec" to use the normal spelling. OLD: This document describes the use of AES in GCM mode (AES-GCM) as an IPSec ESP mechanism ... NEW: This document describes the use of AES in GCM mode (AES-GCM) as an IPsec ESP mechanism ... Replace section 8.3. OLD: For IKE Phase 2 negotiations, IANA has assigned as the ESP Transform Identifier for AES-GCM with an eight-byte explicit IV. NEW: For IKE Phase 2 negotiations, IANA has assigned four ESP Transform Identifiers for AES-GCM with an eight-byte explicit IV: for AES-GCM with a 4 octet ICV; for AES-GCM with an 8 octet ICV; for AES-GCM with a 12 octet ICV; and for AES-GCM with a 16 octet ICV. Replace section 12. OLD: Currently, no ESP transform numbers have been assigned for use with the AES-GCM transform. NEW: IANA has assigned four ESP Transform Identifiers for AES-GCM with an eight-byte explicit IV: for AES-GCM with a 4 octet ICV; for AES-GCM with an 8 octet ICV; for AES-GCM with a 12 octet ICV; and for AES-GCM with a 16 octet ICV. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 23 09:39:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14778 for ; Tue, 23 Nov 2004 09:39:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWbcs-0006mH-Ku; Tue, 23 Nov 2004 09:26:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWbO8-0003ip-18 for ipsec@megatron.ietf.org; Tue, 23 Nov 2004 09:11:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12764 for ; Tue, 23 Nov 2004 09:11:22 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWbRl-000600-Pb for ipsec@ietf.org; Tue, 23 Nov 2004 09:15:12 -0500 Received: from nutshell.tislabs.com (firewall-user@ns1.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iANE51d01088 for ; Tue, 23 Nov 2004 09:05:01 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iANE85sM024655 for ; Tue, 23 Nov 2004 09:08:05 -0500 (EST) Received: from web51506.mail.yahoo.com(206.190.38.198) by nutshell.tislabs.com via csmap (V6.0) id srcAAABBayjW; Tue, 23 Nov 04 09:08:03 -0500 Received: (qmail 59412 invoked by uid 60001); 23 Nov 2004 14:11:15 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=Z8gDSoUxTu/1BwE2iJInWE0kyhRjbmCoGeZe/wxhloErQOs/vt4Kz5LqOsMOGVblNhagHNQQhXIebdUakRX3Nk650O4n9GCoJllO1791jjYHw90DpYNtcCFAOUHcDTx9gxkqKh6TBr+H7Zvk8Bd4JQKrD2BEhyydsJJrcg9oXTA= ; Message-ID: <20041123141115.59407.qmail@web51506.mail.yahoo.com> Received: from [221.15.137.129] by web51506.mail.yahoo.com via HTTP; Tue, 23 Nov 2004 06:11:15 PST Date: Tue, 23 Nov 2004 06:11:15 -0800 (PST) From: Park Lee To: Michal Ludvig In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 2.3 (++) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: ipsec-tools-devel@lists.sourceforge.net, usagi-users@linux-ipv6.org, a.kasparas@gmc.lt, ipsec@lists.tislabs.com Subject: [Ipsec] Re: [Ipsec-tools-devel] How to send additional data from kernel to racoon? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0727023473==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0727023473== Content-Type: multipart/alternative; boundary="0-2078952292-1101219075=:57656" --0-2078952292-1101219075=:57656 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by lists.tislabs.com id iANE51d01088 Content-Transfer-Encoding: quoted-printable On Tue, 23 Nov 2004 at 12:13, Michal Ludvig wrote: > I haven't closely followed the thread but ... how about moving from=20 > PF_KEY to NetLink in IPsec-tools on Linux? NetLink messages are=20 > more versatile I think and could better suit Park's requirements. But=20 > it's just my feeling,=20 > I don't know too much about NetLink either ;-) =20 Thank you. Now, I still want to add a new extension in PF_KEY (RFC2367) in Linux 2.6= . But I wouldn't find any useful information about how to do it on web. =20 Would you please give me some hints on how to define a new extension in P= F_KEY (RFC2367) in Linux 2.6 and How to attach it to a message (such as S= ADB_ACQUIRE message)? =20 -- Best Regards, Park Lee =20 =20 =09 --------------------------------- Do you Yahoo!? The all-new My Yahoo! =96 Get yours free! =20 --0-2078952292-1101219075=:57656 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by lists.tislabs.com id iANE51d01088 Content-Transfer-Encoding: quoted-printable
On Tue, 23 Nov 2004 at 12:13, Michal Ludvig wrote:
> I haven't closely followed the thread but ... how about mo= ving from
> PF_KEY to NetLink in IPsec-tools on Linux? NetLink messages are=
> more versatile I think and could better suit Park's requirement= s. But
> it's just my feeling,
> I don't know too much about NetL= ink either ;-)
 
Thank you.
Now, I still want to add a new extension in PF_KEY (RFC2367) in Linu= x 2.6. But I wouldn't find any useful information about how to do it on w= eb.  
Would you please give me some hints on how to define a new= extension in PF_KEY (RFC2367) in Linux 2.6 and How to attach it to a mes= sage (such as SADB_ACQUIRE message)?
 


=09

Do you Yahoo!?
=20 The all-new My Yahoo! =96 Get yours f= ree!=20 =20 =20 =20 --0-2078952292-1101219075=:57656-- --===============0727023473== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0727023473==-- From ipsec-bounces@ietf.org Thu Nov 25 02:33:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08305 for ; Thu, 25 Nov 2004 02:33:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXE52-0004Uv-Af; Thu, 25 Nov 2004 02:30:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXE4p-0004H1-Ja for ipsec@megatron.ietf.org; Thu, 25 Nov 2004 02:30:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08005 for ; Thu, 25 Nov 2004 02:30:02 -0500 (EST) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXE8h-000393-6R for ipsec@ietf.org; Thu, 25 Nov 2004 02:34:13 -0500 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAP7NVd03971 for ; Thu, 25 Nov 2004 02:23:32 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAP7QZJn026892 for ; Thu, 25 Nov 2004 02:26:35 -0500 (EST) Received: from ip-66-80-10-146.dsl.sca.megapath.net(66.80.10.146) by nutshell.tislabs.com via csmap (V6.0) id srcAAAKlayF0; Thu, 25 Nov 04 02:26:31 -0500 Received: from lokesh.intoto.com (2mc96.intotoind.com [172.16.2.96]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id iAP7Tetk015064 for ; Thu, 25 Nov 2004 12:59:41 +0530 Message-Id: <6.1.2.0.0.20041125130104.02546d70@172.16.1.10> X-Sender: lokeshnb@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 25 Nov 2004 13:03:23 +0530 To: ipsec@lists.tislabs.com From: Lokesh Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Ipsec] clarification on USE_TRANSPORT_MODE Notify X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, I have a doubt regarding the usage of USE_TRANSPORT_MODE Notify in IKEV2. if there are two child SA proposals in the SA payload and configuration says both should be established in Transport mode should I include two USE_TRANSPORT_MODE Notify payloads one for each SA in the request message? populating Protocol ID and SPI fields of Notify payload with the protocol and SPI of respective Child SAs? or the interpretation is other way round like that the USE_TRANSPORT_MODE Notify does not in particular applies to a specific child SA proposal being negotiated in the SA payload, but instead, to whole bunch of all the Child SA proposals in the SA payload being proposed to responder. So, we can leave protocol ID and SPI size fields in the Notify Payload Zero. Hence by this interpretation it clear that all the child SA's should be created in Transport mode if USE_TRANSPORT_MODE notify is honored by responder. problem with this interpretation would arise only when AH and ESP proposals configured for a traffic flow are having different encapsulation modes, I don't think any implementation would allow such a configuration. Thanks Lokesh. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 25 08:54:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13263 for ; Thu, 25 Nov 2004 08:54:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXK2j-0001Ov-Gr; Thu, 25 Nov 2004 08:52:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXJzg-00006Q-Eg for ipsec@megatron.ietf.org; Thu, 25 Nov 2004 08:49:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12652 for ; Thu, 25 Nov 2004 08:49:06 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXK3l-00040X-KX for ipsec@ietf.org; Thu, 25 Nov 2004 08:53:22 -0500 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAPDgkd25736 for ; Thu, 25 Nov 2004 08:42:46 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAPDjpYr006789 for ; Thu, 25 Nov 2004 08:45:51 -0500 (EST) Received: from unknown(83.145.195.1) by nutshell.tislabs.com via csmap (V6.0) id srcAAACqaaqn; Thu, 25 Nov 04 08:45:49 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iAPDmsdE002287 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 25 Nov 2004 15:48:54 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iAPDmrIh002284; Thu, 25 Nov 2004 15:48:53 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.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: <16805.58053.775254.780442@fireball.kivinen.iki.fi> Date: Thu, 25 Nov 2004 15:48:53 +0200 From: Tero Kivinen To: Lokesh Subject: [Ipsec] clarification on USE_TRANSPORT_MODE Notify In-Reply-To: <6.1.2.0.0.20041125130104.02546d70@172.16.1.10> References: <6.1.2.0.0.20041125130104.02546d70@172.16.1.10> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 5 min X-Total-Time: 5 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Lokesh writes: > problem with this interpretation would arise only when AH and ESP proposals > configured for a traffic flow are having different encapsulation modes, I > don't think any implementation would allow such a configuration. If I remember right from the RFC2401bis discussion it is now assumed that AH and ESP are negotiated using the multiple runs through the IPsec processing (i.e. nested SAs). In this case I would assume they would be negotiated using separate CHILD_SA exchanges too, so there would not be any reason to really put part of the SAs tunnel mode and part to transport mode. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 25 10:04:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18699 for ; Thu, 25 Nov 2004 10:04:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXL2t-0000sF-FZ; Thu, 25 Nov 2004 09:56:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXKvr-0007kP-3A for ipsec@megatron.ietf.org; Thu, 25 Nov 2004 09:49:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17451 for ; Thu, 25 Nov 2004 09:49:13 -0500 (EST) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXKzm-0005UQ-Jw for ipsec@ietf.org; Thu, 25 Nov 2004 09:53:29 -0500 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAPEgfd03002 for ; Thu, 25 Nov 2004 09:42:42 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAPEjkGq017197 for ; Thu, 25 Nov 2004 09:45:46 -0500 (EST) Received: from burp.tkv.asdf.org(212.16.99.49) by nutshell.tislabs.com via csmap (V6.0) id srcAAA3saaIH; Thu, 25 Nov 04 09:45:41 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.1/8.13.1/Debian-16) with ESMTP id iAPEmiQr012651; Thu, 25 Nov 2004 16:48:44 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.1/8.13.1/Submit) id iAPEmiWJ012648; Thu, 25 Nov 2004 16:48:44 +0200 Date: Thu, 25 Nov 2004 16:48:44 +0200 Message-Id: <200411251448.iAPEmiWJ012648@burp.tkv.asdf.org> From: Markku Savela To: kivinen@iki.fi In-reply-to: <16805.58053.775254.780442@fireball.kivinen.iki.fi> (message from Tero Kivinen on Thu, 25 Nov 2004 15:48:53 +0200) Subject: Re: [Ipsec] clarification on USE_TRANSPORT_MODE Notify References: <6.1.2.0.0.20041125130104.02546d70@172.16.1.10> <16805.58053.775254.780442@fireball.kivinen.iki.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > From: Tero Kivinen > If I remember right from the RFC2401bis discussion it is now assumed > that AH and ESP are negotiated using the multiple runs through the > IPsec processing (i.e. nested SAs). In this case I would assume they > would be negotiated using separate CHILD_SA exchanges too, so there > would not be any reason to really put part of the SAs tunnel mode and > part to transport mode. I hope you meant, that if we have a packet IP1 AH ESP IP2 ... then AH is in transport mode ESP is in tunnel mode That's the only sensible definition. If AH is "tunnel mode" the packet is faulty, because AH is not followed by IP header! _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 25 10:08:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19285 for ; Thu, 25 Nov 2004 10:08:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXL2v-0000tk-2c; Thu, 25 Nov 2004 09:56:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXKwZ-0007sK-GL for ipsec@megatron.ietf.org; Thu, 25 Nov 2004 09:50:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17522 for ; Thu, 25 Nov 2004 09:49:57 -0500 (EST) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXL0c-0005Vy-Gu for ipsec@ietf.org; Thu, 25 Nov 2004 09:54:13 -0500 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAPEhXd03069 for ; Thu, 25 Nov 2004 09:43:33 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAPEkd5L017296 for ; Thu, 25 Nov 2004 09:46:39 -0500 (EST) Received: from web51509.mail.yahoo.com(206.190.38.201) by nutshell.tislabs.com via csmap (V6.0) id srcAAAj0aOXH; Thu, 25 Nov 04 09:46:37 -0500 Received: (qmail 17101 invoked by uid 60001); 25 Nov 2004 14:49:51 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=KdnhTyea/s6/Xb3SwZluxJDM3UX550DdZd1TQI+YFBnd8PnW4YRJ3EZKYYdz/FOTAo1NxU2mu+4mz3KWuSKAOpd7Z2qBNprbRlxZHsjBCJeiiQwqNfz2r9RItoxNKIYJxYIPnjRSGiH5vI4+4RvgnmpHtZ5hdvPG0fF8cL+kpWw= ; Message-ID: <20041125144950.17099.qmail@web51509.mail.yahoo.com> Received: from [221.15.137.222] by web51509.mail.yahoo.com via HTTP; Thu, 25 Nov 2004 06:49:50 PST Date: Thu, 25 Nov 2004 06:49:50 -0800 (PST) From: Park Lee To: a.kasparas@gmc.lt MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ipsec-tools-devel@lists.sourceforge.net, usagi-users@linux-ipv6.org, ipsec@lists.tislabs.com Subject: [Ipsec] Re: [Ipsec-tools-devel] Issues on calling racoon in Linux kernel 2.6 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0960846375==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0960846375== Content-Type: multipart/alternative; boundary="0-1847580073-1101394190=:17071" --0-1847580073-1101394190=:17071 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by lists.tislabs.com id iAPEhXd03069 Content-Transfer-Encoding: quoted-printable On Fri, 19 Nov 2004 at 08:52, Aidas Kasparas wrote: > > Park Lee wrote: > > Then, Where is the code in the source code of Linux kernel 2.6=20 > > to call racoon? > > ...... >=20 > The code is at net/key/af_key.c . It implements PF_KEY protocol.=20 > Requests to establish a SA are sent to every program, which have=20 > open PF_KEY socket and requested to receive such requests. Basis=20 > for PF_KEY protocol is documented in RFC 2367, but linux kernel=20 > and racoon implement extended version of that spec (I don't know=20 > better documentation for extensions than source). =20 In net/key/af_key.c, there is a function pfkey_send_acquire(). I think= this function is used by kernel to send the PF_KEY SADB_ACQUIRE message = to racoon. But, It seems that in kernel source there is no other function= s who call this one.=20 Then, How is pfkey_send_acquire() used by kernel? and Eventually How = is the SADB_ACQUIRE message sent by kernel in IPv4 when no security asso= ciations currently exist for IPsec to use? Is it begins in the xfrm_find_= bundle() function which is called by xfrm_lookup() function (in net/xfrm/= xfrm_policy.c)?=20 =20 Thank you. -- Best Regards, Park Lee =20 =20 =09 --------------------------------- Do you Yahoo!? Meet the all-new My Yahoo! =96 Try it today!=20 --0-1847580073-1101394190=:17071 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by lists.tislabs.com id iAPEhXd03069 Content-Transfer-Encoding: quoted-printable
On Fri, 19 Nov 2004 at 08:52, Aidas Kasparas wrote:
>
> = Park Lee wrote:
> >    Then, Where is the code in= the source code of Linux kernel 2.6
> > to call racoon?
> > ......
>
= > The code is at net/key/af_key.c . It implements PF_KEY protocol. > Requests to establish a SA are sent to every program, which have
> open PF_KEY socket and requested to receive such requests.= Basis
> for PF_KEY protocol is documented in RFC 2367, but linux kernel=
> and racoon implement extended version of that spec (I don'= t know
> better documentation for extensions than source).
 = ;
   In net/key/af_key.c, there is a function pfkey_send_acq= uire(). I think this function is used by kernel to send the PF_KEY SADB_A= CQUIRE message to racoon. But, It seems that in kernel source there is no= other functions who call this one.
    Then, How is p= fkey_send_acquire() used by kernel? and Eventually How is  the SADB_= ACQUIRE message sent by kernel in IPv4 when no security associations curr= ently exist for IPsec to use? Is it begins in the xfrm_find_bundle() func= tion which is called by xfrm_lookup() function (in net/xfrm/xfrm_policy.c= )?
 
Thank you.


--
Best Regards,
Park Lee <parklee_sel@yahoo= .com>
 

Do you Yahoo!?
=20 Meet the all-new My Yahoo! =96 Try it= today!=20 --0-1847580073-1101394190=:17071-- --===============0960846375== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0960846375==-- From ipsec-bounces@ietf.org Fri Nov 26 10:12:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14755 for ; Fri, 26 Nov 2004 10:12:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhU9-000609-Pz; Fri, 26 Nov 2004 09:54:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhR5-0004eR-Mw for ipsec@megatron.ietf.org; Fri, 26 Nov 2004 09:50:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23921 for ; Fri, 26 Nov 2004 04:56:13 -0500 (EST) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXcu4-0004Q9-6t for ipsec@ietf.org; Fri, 26 Nov 2004 05:00:39 -0500 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAQ9nld26023 for ; Fri, 26 Nov 2004 04:49:47 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAQ9qrvl025313 for ; Fri, 26 Nov 2004 04:52:53 -0500 (EST) Received: from web51505.mail.yahoo.com(206.190.38.197) by nutshell.tislabs.com via csmap (V6.0) id srcAAANqaOBX; Fri, 26 Nov 04 04:52:50 -0500 Received: (qmail 62150 invoked by uid 60001); 26 Nov 2004 09:56:04 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=UDm/8Rc9KzKc2g4kyMIUQXDtD5hl6pejp59LNqkPyh8zp5JnsFPyqurPw1l8L42ZtUXZZnOfEqXpcQNoCDiIxfVv7oQo88fY922wzFc8EVEa2LzPgqW2QJUhwmj39ZCzpqFkeI8KyKuC6A5T3UQHrJXldEU/6D4CtKjGgVfdNhI= ; Message-ID: <20041126095604.62148.qmail@web51505.mail.yahoo.com> Received: from [221.15.137.125] by web51505.mail.yahoo.com via HTTP; Fri, 26 Nov 2004 01:56:04 PST Date: Fri, 26 Nov 2004 01:56:04 -0800 (PST) From: Park Lee To: ipsec-tools-devel@lists.sourceforge.net MIME-Version: 1.0 X-Spam-Score: 1.1 (+) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: usagi-users@linux-ipv6.org, ipsec@lists.tislabs.com Subject: [Ipsec] Issue on PF_KEY vs. Netlink interface X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0214615745==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0214615745== Content-Type: multipart/alternative; boundary="0-293073389-1101462964=:61534" --0-293073389-1101462964=:61534 Content-Type: text/plain; charset=us-ascii Hi, I'm learning native IPsec in Linux kernel 2.6. and use IPsec-Tools as my user-space tools. In net/key/af_key.c, there are something about PF_KEY as follows: static struct xfrm_mgr pfkeyv2_mgr = { .id = "pfkeyv2", .notify = pfkey_send_notify, .acquire = pfkey_send_acquire, .compile_policy = pfkey_compile_policy, .new_mapping = pfkey_send_new_mapping, }; static int pfkey_send_acquire(struct xfrm_state *x, struct xfrm_tmpl *t, struct xfrm_policy *xp, int dir) In net/xfrm/xfrm_user.c, there are also something about Netlink as follows: static struct xfrm_mgr netlink_mgr = { .id = "netlink", .notify = xfrm_send_state_notify, .acquire = xfrm_send_acquire, .compile_policy = xfrm_compile_policy, .notify_policy = xfrm_send_policy_notify, }; static int xfrm_send_acquire(struct xfrm_state *x, struct xfrm_tmpl *xt, struct xfrm_policy *xp, int dir) Then, when kernel send a message to racoon for setting up a SA, What interface(i.e. PF_KEY or Netlink) indeed is used to send such a message? (i.e. Does it use pfkey_send_acquire() or xfrm_send_acquire()? ) And, What is the relationship between PF_KEY and Netlink in Linux kernel, when we use IPsec? Thank you. -- Best Regards, Park Lee __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-293073389-1101462964=:61534 Content-Type: text/html; charset=us-ascii
Hi,
    I'm learning native IPsec in Linux kernel 2.6. and use IPsec-Tools as my user-space tools.
    In net/key/af_key.c, there are something about PF_KEY as follows:
static struct xfrm_mgr pfkeyv2_mgr =
{
        .id             = "pfkeyv2",
        .notify         = pfkey_send_notify,
        .acquire        = pfkey_send_acquire,        
 .compile_policy = pfkey_compile_policy,
        .new_mapping    = pfkey_send_new_mapping,
};
static int pfkey_send_acquire(struct xfrm_state *x, struct xfrm_tmpl *t, struct xfrm_policy *xp, int dir)
   
     In net/xfrm/xfrm_user.c, there are also something about Netlink as follows:
static struct xfrm_mgr netlink_mgr = {
        .id             = "netlink",
        .notify         = xfrm_send_state_notify,
        .acquire        = xfrm_send_acquire,
        .compile_policy = xfrm_compile_policy,
        .notify_policy  = xfrm_send_policy_notify,
};
static int xfrm_send_acquire(struct xfrm_state *x, struct xfrm_tmpl *xt,
                             struct xfrm_policy *xp, int dir)
   
     Then, when kernel send a message to racoon for setting up a SA, What interface(i.e. PF_KEY or Netlink) indeed is used to send such a message? (i.e. Does it use pfkey_send_acquire() or xfrm_send_acquire()? )
    And, What is the relationship between PF_KEY and Netlink in Linux kernel, when we use IPsec?
 
    Thank you.
 


--
Best Regards,
Park Lee <parklee_sel@yahoo.com>
 

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-293073389-1101462964=:61534-- --===============0214615745== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0214615745==-- From ipsec-bounces@ietf.org Fri Nov 26 13:38:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07740 for ; Fri, 26 Nov 2004 13:38:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXkxV-0001Ut-DI; Fri, 26 Nov 2004 13:36:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXkpl-0008WD-7L for ipsec@megatron.ietf.org; Fri, 26 Nov 2004 13:28:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06337 for ; Fri, 26 Nov 2004 13:28:38 -0500 (EST) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXku5-0000S6-1X for ipsec@ietf.org; Fri, 26 Nov 2004 13:33:09 -0500 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id iAQIMGd11373 for ; Fri, 26 Nov 2004 13:22:16 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id iAQIPNQ9014890 for ; Fri, 26 Nov 2004 13:25:23 -0500 (EST) Received: from web51506.mail.yahoo.com(206.190.38.198) by nutshell.tislabs.com via csmap (V6.0) id srcAAAVWaaeD; Fri, 26 Nov 04 13:25:21 -0500 Received: (qmail 72670 invoked by uid 60001); 26 Nov 2004 18:28:35 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=RqSC7xIcUw2YLT63QcZV9+V86fERKOLIbKlfCHAm8KKBozIMmDXGwNMPy/YTnfBeNK8KvpatSx5H5HY6QH/Ro9TcG79yI5rTjTlurrKA3qLsiAQjPC8aQzHZZp1FQ2ulIaQkVTFnrCFLJm/prpbk5+sG2wz4yaK+RarVZv1VOdY= ; Message-ID: <20041126182834.72665.qmail@web51506.mail.yahoo.com> Received: from [221.15.137.142] by web51506.mail.yahoo.com via HTTP; Fri, 26 Nov 2004 10:28:34 PST Date: Fri, 26 Nov 2004 10:28:34 -0800 (PST) From: Park Lee To: ipsec-tools-devel@lists.sourceforge.net MIME-Version: 1.0 X-Spam-Score: 0.7 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: usagi-users@linux-ipv6.org, ipsec@lists.tislabs.com Subject: [Ipsec] Issue on get the socket of a packet X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0378981409==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0378981409== Content-Type: multipart/alternative; boundary="0-938867865-1101493714=:70935" --0-938867865-1101493714=:70935 Content-Type: text/plain; charset=us-ascii Hi, I'm using IPsec-Tools as the user-space tools for native IPsec in Linux 2.6. We know when there is no appropriate SA for an outbound packet, the kernel will first put the packet into a queue, and send a PF_KEY SADB_ACQUIRE message to racoon. Then, Would you please tell me how to get the socket (i.e. the socket that is related to the outbound packet. when we want to send the packet, we should first set up the socket)? and where will the packet be put into? Thank you. -- Best Regards, Park Lee __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-938867865-1101493714=:70935 Content-Type: text/html; charset=us-ascii

Hi,
   I'm using IPsec-Tools as the user-space tools for native IPsec in Linux 2.6.
   We know when there is no appropriate SA for an outbound packet, the kernel will first put the packet into a queue, and send a PF_KEY SADB_ACQUIRE message to racoon.
   Then, Would you please tell me how to get the socket (i.e. the socket that is related to the outbound packet. when we want to send the packet, we should first set up the socket)? and where will the packet be put into?
 
Thank you. 


--
Best Regards,
Park Lee <parklee_sel@yahoo.com>
 

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-938867865-1101493714=:70935-- --===============0378981409== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0378981409==-- From ipsec-bounces@ietf.org Sat Nov 27 12:18:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05849 for ; Sat, 27 Nov 2004 12:18:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY5z8-0000WA-5q; Sat, 27 Nov 2004 12:03:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY5o5-0006Lt-5F for ipsec@megatron.ietf.org; Sat, 27 Nov 2004 11:52:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08143 for ; Sat, 27 Nov 2004 05:58:07 -0500 (EST) Received: from [217.219.18.2] (helo=cc.iut.ac.ir) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CY0Lk-00052E-S2 for ipsec@ietf.org; Sat, 27 Nov 2004 06:02:47 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by cc.iut.ac.ir (Postfix) with ESMTP id C8F9F2C804B for ; Sat, 27 Nov 2004 14:26:02 +0330 (IRT) Received: from cc.iut.ac.ir ([127.0.0.1]) by localhost (cc.iut.ac.ir [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26148-01 for ; Sat, 27 Nov 2004 14:26:02 +0330 (IRT) Received: from ec.iut.ac.ir (localhost.localdomain [127.0.0.1]) by cc.iut.ac.ir (Postfix) with ESMTP id 5DA362C8041 for ; Sat, 27 Nov 2004 14:26:01 +0330 (IRT) From: "mahdavi" To: ipsec@ietf.org Date: Sat, 27 Nov 2004 14:26:01 +0330 Message-Id: <20041127105444.M28911@ec.iut.ac.ir> X-Mailer: Open WebMail X-OriginatingIP: 193.251.135.125 (mahdavi@ec.iut.ac.ir) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Virus-Scanned: by amavisd-new at cc.iut.ac.ir X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ipsec] Why Destionation address while SPI is present. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi. I have confused with this sentence in RFC2401 "A security association is uniquely identified by a triple consisting of a Security Parameter Index (SPI), an IP Destination Address, and a security protocol (AH or ESP) identifier." Since SPI is generated by the receiver, Receiver can generate a unique SPI for himself. In Inbound receiver can just search on SPI and does not need to seaech on IP Destination Address and security protocol too. So Y we should search on these two fields too ? ? PS: we are designing IPSec in heart of a high speed router. thanks in advance. -- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 29 11:49:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07980 for ; Mon, 29 Nov 2004 11:49:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYocJ-0007yU-1C; Mon, 29 Nov 2004 11:43:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYoWm-00079l-8r for ipsec@megatron.ietf.org; Mon, 29 Nov 2004 11:37:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07177 for ; Mon, 29 Nov 2004 11:37:26 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYobf-0005i6-Fc for ipsec@ietf.org; Mon, 29 Nov 2004 11:42:34 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iATGagjj019229; Mon, 29 Nov 2004 11:36:46 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <20041127105444.M28911@ec.iut.ac.ir> References: <20041127105444.M28911@ec.iut.ac.ir> Date: Mon, 29 Nov 2004 10:42:09 -0500 To: "mahdavi" From: Stephen Kent Subject: Re: [Ipsec] Why Destionation address while SPI is present. Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 2:26 PM +0330 11/27/04, mahdavi wrote: >Hi. > >I have confused with this sentence in RFC2401 > >"A security association is uniquely identified by a triple consisting > of a Security Parameter Index (SPI), an IP Destination Address, and a > security protocol (AH or ESP) identifier." > > >Since SPI is generated by the receiver, Receiver can generate a unique SPI for >himself. In Inbound receiver can just search on SPI and does not need to >seaech on IP Destination Address and security protocol too. > >So Y we should search on these two fields too ? ? > >PS: we are designing IPSec in heart of a high speed router. > >thanks in advance. > Yes, the use of an address is redundant for IPsec unicast traffic, and unless the receiver chooses to reuse the SPI space for AH and ESP, it there is no need to examine the protocol field either. In 2401bis we have reworded this section. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 29 20:28:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06385 for ; Mon, 29 Nov 2004 20:27:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYwgq-0005Sf-9u; Mon, 29 Nov 2004 20:20:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYwaY-0003ou-CK for ipsec@megatron.ietf.org; Mon, 29 Nov 2004 20:13:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05580 for ; Mon, 29 Nov 2004 20:13:53 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYwfY-0004tR-60 for ipsec@ietf.org; Mon, 29 Nov 2004 20:19:05 -0500 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAU1AMQ12433; Mon, 29 Nov 2004 17:10:22 -0800 (PST) Message-ID: <41ABC87C.30208@isi.edu> Date: Mon, 29 Nov 2004 17:10:20 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [Ipsec] Why Destionation address while SPI is present. References: <20041127105444.M28911@ec.iut.ac.ir> In-Reply-To: X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 One issue for unique SPIs is coordination of different BITW instances on a single machine. Presumably they have different IP addresses, but omitting that address from the lookup means the different BITWs would be _required_ to coordinate SPIs issued. I.e., does omitting the address put additional constraints on BITWs? Joe Stephen Kent wrote: | At 2:26 PM +0330 11/27/04, mahdavi wrote: | |> Hi. |> |> I have confused with this sentence in RFC2401 |> |> "A security association is uniquely identified by a triple consisting |> of a Security Parameter Index (SPI), an IP Destination Address, and a |> security protocol (AH or ESP) identifier." |> |> |> Since SPI is generated by the receiver, Receiver can generate a unique |> SPI for |> himself. In Inbound receiver can just search on SPI and does not need to |> seaech on IP Destination Address and security protocol too. |> |> So Y we should search on these two fields too ? ? |> |> PS: we are designing IPSec in heart of a high speed router. |> |> thanks in advance. |> | | Yes, the use of an address is redundant for IPsec unicast traffic, and | unless the receiver chooses to reuse the SPI space for AH and ESP, it | there is no need to examine the protocol field either. In 2401bis we | have reworded this section. | | Steve | | _______________________________________________ | Ipsec mailing list | Ipsec@ietf.org | https://www1.ietf.org/mailman/listinfo/ipsec -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBq8h8E5f5cImnZrsRAiTiAJ9ylOVNd3RhzdAA7XQD6TtKAFae3QCcCs7g KSE7RkoYPEabVNC82YfcZOc= =L5iJ -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 30 06:26:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07469 for ; Tue, 30 Nov 2004 06:26:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ5zd-0002vI-4l; Tue, 30 Nov 2004 06:16:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ5x6-0001qp-HW for ipsec@megatron.ietf.org; Tue, 30 Nov 2004 06:13:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06915 for ; Tue, 30 Nov 2004 06:13:45 -0500 (EST) Received: from rs15.luxsci.com ([65.61.166.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ62C-0000Ws-3L for ipsec@ietf.org; Tue, 30 Nov 2004 06:19:04 -0500 Received: from rs15.luxsci.com (localhost [127.0.0.1]) by rs15.luxsci.com (8.12.11/8.12.11) with ESMTP id iAUBCmJr012843; Tue, 30 Nov 2004 05:12:51 -0600 Received: (from root@localhost) by rs15.luxsci.com (8.12.11/8.12.11/Submit) id iAUBC1oV012764; Tue, 30 Nov 2004 11:12:01 GMT Message-Id: <200411301112.iAUBC1oV012764@rs15.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Tue, 30 Nov 2004 11:12:01 +0000 From: "William Dixon" To: "'Joe Touch'" , "'Stephen Kent'" Subject: Co-existence of IPsec implementations (was: Re: [Ipsec] Why Destionation address while SPI is present) Date: Tue, 30 Nov 2004 03:10:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <41ABC87C.30208@isi.edu> X-Lux-Comment: LuxSci remailer message ID code - 1101813121-7862361.49405719 [0] X-Spam-Score: 0.8 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit I've always thought that 2401 & 2401bis assumed there was one IPsec implementation for a given IP address in theory. Maybe that's not strictly required, but then neither is support for two or more in coexistence specifically required. A number of conflicts could occur if more than one IPsec implementation uses the same IP address, in addition to SPI selection. They both will be blocking, permitting and negotiating SAs for potentially the same traffic with different policies that are potentially independently administered. It would be difficult to have multiple IKEs listening on port 500. But easy enough to configure IKE to use different ports with policy. You'd have to be able to not drop a packet with a SPI that wasn't yours. And be able to guarantee binding order for packet intercept during successive boots. Coexistence has been a practical market requirement for client host platforms given the popularity of IPsec tunnel VPN clients. I can imagine that there will be varying degrees of native support for IPsec-based scenarios for IPv6, just as we saw for IPv4 remote access. So my question is whether coexistence should be addressed by a WG document ? > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Joe Touch > Sent: Monday, November 29, 2004 5:10 PM > To: Stephen Kent > Cc: ipsec@ietf.org > Subject: Re: [Ipsec] Why Destionation address while SPI is present. > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > One issue for unique SPIs is coordination of different BITW > instances on a single machine. Presumably they have different > IP addresses, but omitting that address from the lookup means > the different BITWs would be _required_ to coordinate SPIs issued. > > I.e., does omitting the address put additional constraints on BITWs? > > Joe > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 30 10:02:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25090 for ; Tue, 30 Nov 2004 10:02:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ9LY-0006UA-7A; Tue, 30 Nov 2004 09:51:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ9Hy-0004rv-Bl for ipsec@megatron.ietf.org; Tue, 30 Nov 2004 09:47:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23507 for ; Tue, 30 Nov 2004 09:47:32 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9N6-0005K8-HG for ipsec@ietf.org; Tue, 30 Nov 2004 09:52:52 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iAUEkrjf007614; Tue, 30 Nov 2004 09:46:54 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <41ABC87C.30208@isi.edu> References: <20041127105444.M28911@ec.iut.ac.ir> <41ABC87C.30208@isi.edu> Date: Tue, 30 Nov 2004 09:33:56 -0500 To: Joe Touch From: Stephen Kent Subject: Re: [Ipsec] Why Destionation address while SPI is present. Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 5:10 PM -0800 11/29/04, Joe Touch wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >One issue for unique SPIs is coordination of different BITW instances on >a single machine. Presumably they have different IP addresses, but >omitting that address from the lookup means the different BITWs would be >_required_ to coordinate SPIs issued. > >I.e., does omitting the address put additional constraints on BITWs? > >Joe > Joe, Each BITW device is an independent implementation of IPsec, so I would not expect them to be able to coordinate SPI generation, nor would I expect them to be able to share keys. if they don't share keys, then traffic arriving at the "wrong" one cannot be processed anyway. So, I would rely on each having a different address and thus not coordinating any of the other parameters needed to appear to be equivalent. of course, a vendor may choose to do something outside of the spec to offer this sort of extended functionality, but the key sharing issue might make it harder to achieve FIPS 140-2 approval. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 30 10:57:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00767 for ; Tue, 30 Nov 2004 10:57:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZAA9-0000ff-8c; Tue, 30 Nov 2004 10:43:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZA5o-00082Z-Kl for ipsec@megatron.ietf.org; Tue, 30 Nov 2004 10:39:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29340 for ; Tue, 30 Nov 2004 10:39:02 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZAAv-0006cA-T3 for ipsec@ietf.org; Tue, 30 Nov 2004 10:44:23 -0500 Received: from [192.168.1.47] (lsanca1-ar42-4-61-185-150.lsanca1.dsl-verizon.net [4.61.185.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAUFZoQ25700; Tue, 30 Nov 2004 07:35:50 -0800 (PST) Message-ID: <41AC934D.1020408@isi.edu> Date: Tue, 30 Nov 2004 07:35:41 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [Ipsec] Why Destionation address while SPI is present. References: <20041127105444.M28911@ec.iut.ac.ir> <41ABC87C.30208@isi.edu> In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1123324497==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1123324497== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig76DE718A39EC82E6B505D163" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig76DE718A39EC82E6B505D163 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Stephen Kent wrote: > At 5:10 PM -0800 11/29/04, Joe Touch wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> One issue for unique SPIs is coordination of different BITW instances on >> a single machine. Presumably they have different IP addresses, but >> omitting that address from the lookup means the different BITWs would be >> _required_ to coordinate SPIs issued. >> >> I.e., does omitting the address put additional constraints on BITWs? >> >> Joe >> > > Joe, > > Each BITW device is an independent implementation of IPsec, so I would > not expect them to be able to coordinate SPI generation, nor would I > expect them to be able to share keys. if they don't share keys, then > traffic arriving at the "wrong" one cannot be processed anyway. So, I > would rely on each having a different address and thus not coordinating > any of the other parameters needed to appear to be equivalent. of > course, a vendor may choose to do something outside of the spec to offer > this sort of extended functionality, but the key sharing issue might > make it harder to achieve FIPS 140-2 approval. > > Steve Right - that's what I thought. However, that also means that it would be the address/SPI pair that would be important. I.e., there are two different kinds of failure: a) failed to lookup addr/SPI b) key found failed to work *IF* IPsec considers those different errors, then the pair is required. If they're considered equivalent (logged the same, generate/don't generate the same internal error, etc.), then addr can be omitted. Joe --------------enig76DE718A39EC82E6B505D163 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBrJNSE5f5cImnZrsRAmrKAKDuIS9xrlNKGbduJdvkY1XMdHu+QgCgkIVK mPeNN2uaJowS+Oo++bcBeyA= =hyDw -----END PGP SIGNATURE----- --------------enig76DE718A39EC82E6B505D163-- --===============1123324497== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1123324497==-- From ipsec-bounces@ietf.org Tue Nov 30 12:07:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07675 for ; Tue, 30 Nov 2004 12:07:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZBHD-00035V-Qe; Tue, 30 Nov 2004 11:54:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZBAi-0001G5-HH for ipsec@megatron.ietf.org; Tue, 30 Nov 2004 11:48:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05934 for ; Tue, 30 Nov 2004 11:48:09 -0500 (EST) Received: from [217.219.18.2] (helo=cc.iut.ac.ir) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZBFl-0008Un-V5 for ipsec@ietf.org; Tue, 30 Nov 2004 11:53:32 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by cc.iut.ac.ir (Postfix) with ESMTP id 9C3962C804E for ; Tue, 30 Nov 2004 20:15:41 +0330 (IRT) Received: from cc.iut.ac.ir ([127.0.0.1]) by localhost (cc.iut.ac.ir [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20111-08 for ; Tue, 30 Nov 2004 20:15:41 +0330 (IRT) Received: from ec.iut.ac.ir (localhost.localdomain [127.0.0.1]) by cc.iut.ac.ir (Postfix) with ESMTP id B5AB52C803E for ; Tue, 30 Nov 2004 20:15:40 +0330 (IRT) From: "mahdavi" To: ipsec@ietf.org Date: Tue, 30 Nov 2004 20:15:40 +0330 Message-Id: <20041130164432.M29958@ec.iut.ac.ir> X-Mailer: Open WebMail X-OriginatingIP: 193.251.135.123 (mahdavi@ec.iut.ac.ir) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Virus-Scanned: by amavisd-new at cc.iut.ac.ir X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Subject: [Ipsec] About case A and Case B? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I am working on a high speed secure router and there is something that I cant Understand what to do with it. and that is these mysterious sentences. (I call these as Case A and Case B ) " a. use the value in the packet itself -- This will limit use of the SA to those packets which have this packet's value for the selector even if the selector for the policy entry has a range of allowed values or a wildcard for this selector. b. use the value associated with the policy entry -- If this were to be just a single value, then there would be no difference between (b) and (a).,......" Imagine a router that is IPSec aware (SG1). HOST HOST C to K=========|1| SG1 |2|=======================SG2 --- M to X | / \ / | / \ / \-------------/ \------------------------/ SG1 has two interfaces 1 and 2 . outbound policy for interface 2 of SG1 says : -------------------------------------------------------- For any packet from host (C to k) going to host (M to X) make a tunnel with SG2. USE CASE B -------------------------------------------------------- This means to use one SA for all traffic traversing from (C - K) TO ( M - X ). Right? What about this policy? -------------------------------------------------------- For any packet from host (C to k) going to host (M to X) make a tunnel with SG2. USE CASE A -------------------------------------------------------- What that means? Does it mean to make separate SA's for any source-destination pair ? For example one for a packet traversing from C to M and one another for a packet giong from D to N and one another for a packet going from C to N ??? If so what is benefit of this ??? __________________________________________________________ __________________________________________________________ Question 2: Before, I thought that Case A Is not usable in this situation and this situation should be used with case b. Was Right ? __________________________________________________________ __________________________________________________________ Question 3: Can we have such a policy like below for inbound traffic for interface 1 of SG1? For inbound traffic for interface 1 of SG1 : (this is just one policy record) -------------------------------------------------------- For any packet from host (C to k) going to host (M to X) make a tunnel with ITSELF (SOURCE OF Packet). -------------------------------------------------------- In above policy because we wanted to have one policy for many tunnels (in this case 9 tunnels each for each host C - K ) and ITSELF means having a tunnel with source of packet host. Firstly, having such a policy is logical??? Secondly, does it mean Case A??? ____________________________________________________________ Best of regards Mahdavi. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 30 17:08:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20638 for ; Tue, 30 Nov 2004 17:08:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZEfH-0002Yh-3E; Tue, 30 Nov 2004 15:31:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZETA-00031R-MT for ipsec@megatron.ietf.org; Tue, 30 Nov 2004 15:19:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00090 for ; Tue, 30 Nov 2004 15:19:26 -0500 (EST) Received: from mx2.trusecure.com ([208.251.192.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZEYK-0006Jt-Nr for ipsec@ietf.org; Tue, 30 Nov 2004 15:24:49 -0500 Received: by mx2.trusecure.com (Postfix, from userid 1006) id 9FE6BC922D; Tue, 30 Nov 2004 15:18:49 -0500 (EST) Received: from VAMAIL01.corp.trusecure.net (vamail01.corp.trusecure.net [172.19.1.52]) by mx2.trusecure.com (Postfix) with ESMTP id 8E0F5C921C for ; Tue, 30 Nov 2004 15:18:49 -0500 (EST) Received: from HRN-MSC-EXCH-01.mscore.trusecure.net (hrn-msc-exch-01.corp.trusecure.net [172.19.1.49]) by VAMAIL01.corp.trusecure.net (8.12.10/maybe_its_not_even_really_Sendmail....) with ESMTP id iAUKInDW022559 for ; Tue, 30 Nov 2004 15:18:49 -0500 (EST) Received: from hrn-msc-exch-02.mscore.trusecure.net ([172.19.1.56]) by HRN-MSC-EXCH-01.mscore.trusecure.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Nov 2004 15:18:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Nov 2004 15:18:36 -0500 Message-ID: <04D8F83756A1A84BA156BBFF26FAE0F501096C93@hrn-msc-exch-02.mscore.trusecure.net> Thread-Topic: Ipsec Digest, Vol 7, Issue 34 Thread-Index: AcTXAbe+ASqrlNiyTomolvd/MGy/hAAF/d/w From: "Phan, Thang" To: X-OriginalArrivalTime: 30 Nov 2004 20:18:50.0146 (UTC) FILETIME=[CDE13820:01C4D719] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4ec58ef3f343ebf5ac40a04538f9a6fc Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] RE: Ipsec Digest, Vol 7, Issue 34 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I think you have a nice crack ;) Let me count it - one.=20 Thang Phan Network Analyst tphan@icsalabs.com 1000 Bent Creek Blvd., Suite 200 Mechanicsburg, PA 17050 717.790.8137 (P) 717.790.8170 (F) -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of ipsec-request@ietf.org Sent: Tuesday, November 30, 2004 12:26 PM To: ipsec@ietf.org Subject: Ipsec Digest, Vol 7, Issue 34 Send Ipsec mailing list submissions to ipsec@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/ipsec or, via email, send a message with subject or body 'help' to ipsec-request@ietf.org You can reach the person managing the list at ipsec-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Ipsec digest..." Today's Topics: 1. Re: Why Destionation address while SPI is present. (Joe Touch) 2. Co-existence of IPsec implementations (was: Re: [Ipsec] Why Destionation address while SPI is present) (William Dixon) 3. Re: Why Destionation address while SPI is present. (Stephen Kent) 4. Re: Why Destionation address while SPI is present. (Joe Touch) 5. About case A and Case B? (mahdavi) ---------------------------------------------------------------------- Message: 1 Date: Mon, 29 Nov 2004 17:10:20 -0800 From: Joe Touch Subject: Re: [Ipsec] Why Destionation address while SPI is present. To: Stephen Kent Cc: ipsec@ietf.org Message-ID: <41ABC87C.30208@isi.edu> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 One issue for unique SPIs is coordination of different BITW instances on a single machine. Presumably they have different IP addresses, but omitting that address from the lookup means the different BITWs would be _required_ to coordinate SPIs issued. I.e., does omitting the address put additional constraints on BITWs? Joe Stephen Kent wrote: | At 2:26 PM +0330 11/27/04, mahdavi wrote: | |> Hi. |> |> I have confused with this sentence in RFC2401 |> |> "A security association is uniquely identified by a triple consisting |> of a Security Parameter Index (SPI), an IP Destination Address, and a |> security protocol (AH or ESP) identifier." |> |> |> Since SPI is generated by the receiver, Receiver can generate a=20 |> unique SPI for himself. In Inbound receiver can just search on SPI=20 |> and does not need to seaech on IP Destination Address and security=20 |> protocol too. |> |> So Y we should search on these two fields too ? ? |> |> PS: we are designing IPSec in heart of a high speed router. |> |> thanks in advance. |> | | Yes, the use of an address is redundant for IPsec unicast traffic, and | unless the receiver chooses to reuse the SPI space for AH and ESP, it=20 | there is no need to examine the protocol field either. In 2401bis we=20 | have reworded this section. | | Steve | | _______________________________________________ | Ipsec mailing list | Ipsec@ietf.org | https://www1.ietf.org/mailman/listinfo/ipsec -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBq8h8E5f5cImnZrsRAiTiAJ9ylOVNd3RhzdAA7XQD6TtKAFae3QCcCs7g KSE7RkoYPEabVNC82YfcZOc=3D =3DL5iJ -----END PGP SIGNATURE----- ------------------------------ Message: 2 Date: Tue, 30 Nov 2004 03:10:25 -0800 From: "William Dixon" Subject: Co-existence of IPsec implementations (was: Re: [Ipsec] Why Destionation address while SPI is present) To: "'Joe Touch'" , "'Stephen Kent'" Cc: ipsec@ietf.org Message-ID: <200411301112.iAUBC1oV012764@rs15.luxsci.com> Content-Type: text/plain; charset=3D"us-ascii" I've always thought that 2401 & 2401bis assumed there was one IPsec implementation for a given IP address in theory. Maybe that's not strictly required, but then neither is support for two or more in coexistence specifically required. A number of conflicts could occur if more than one IPsec implementation uses the same IP address, in addition to SPI selection. They both will be blocking, permitting and negotiating SAs for potentially the same traffic with different policies that are potentially independently administered. It would be difficult to have multiple IKEs listening on port 500. But easy enough to configure IKE to use different ports with policy. You'd have to be able to not drop a packet with a SPI that wasn't yours. And be able to guarantee binding order for packet intercept during successive boots. Coexistence has been a practical market requirement for client host platforms given the popularity of IPsec tunnel VPN clients. I can imagine that there will be varying degrees of native support for IPsec-based scenarios for IPv6, just as we saw for IPv4 remote access. So my question is whether coexistence should be addressed by a WG document ? > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Joe Touch > Sent: Monday, November 29, 2004 5:10 PM > To: Stephen Kent > Cc: ipsec@ietf.org > Subject: Re: [Ipsec] Why Destionation address while SPI is present. >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > One issue for unique SPIs is coordination of different BITW instances=20 > on a single machine. Presumably they have different IP addresses, but=20 > omitting that address from the lookup means the different BITWs would=20 > be _required_ to coordinate SPIs issued. >=20 > I.e., does omitting the address put additional constraints on BITWs? >=20 > Joe > ------------------------------ Message: 3 Date: Tue, 30 Nov 2004 09:33:56 -0500 From: Stephen Kent Subject: Re: [Ipsec] Why Destionation address while SPI is present. To: Joe Touch Cc: ipsec@ietf.org Message-ID: Content-Type: text/plain; charset=3D"us-ascii" ; format=3D"flowed" At 5:10 PM -0800 11/29/04, Joe Touch wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >One issue for unique SPIs is coordination of different BITW instances=20 >on a single machine. Presumably they have different IP addresses, but=20 >omitting that address from the lookup means the different BITWs would=20 >be _required_ to coordinate SPIs issued. > >I.e., does omitting the address put additional constraints on BITWs? > >Joe > Joe, Each BITW device is an independent implementation of IPsec, so I would not expect them to be able to coordinate SPI generation, nor would I expect them to be able to share keys. if they don't share keys, then traffic arriving at the "wrong" one cannot be processed anyway. So, I would rely on each having a different address and thus not coordinating any of the other parameters needed to appear to be equivalent. of course, a vendor may choose to do something outside of the spec to offer this sort of extended functionality, but the key sharing issue might make it harder to achieve FIPS 140-2 approval. Steve ------------------------------ Message: 4 Date: Tue, 30 Nov 2004 07:35:41 -0800 From: Joe Touch Subject: Re: [Ipsec] Why Destionation address while SPI is present. To: Stephen Kent Cc: ipsec@ietf.org Message-ID: <41AC934D.1020408@isi.edu> Content-Type: text/plain; charset=3D"iso-8859-1" Stephen Kent wrote: > At 5:10 PM -0800 11/29/04, Joe Touch wrote: >=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> One issue for unique SPIs is coordination of different BITW instances >> on a single machine. Presumably they have different IP addresses, but >> omitting that address from the lookup means the different BITWs would >> be _required_ to coordinate SPIs issued. >> >> I.e., does omitting the address put additional constraints on BITWs? >> >> Joe >> >=20 > Joe, >=20 > Each BITW device is an independent implementation of IPsec, so I would > not expect them to be able to coordinate SPI generation, nor would I=20 > expect them to be able to share keys. if they don't share keys, then=20 > traffic arriving at the "wrong" one cannot be processed anyway. So, I=20 > would rely on each having a different address and thus not=20 > coordinating any of the other parameters needed to appear to be=20 > equivalent. of course, a vendor may choose to do something outside of=20 > the spec to offer this sort of extended functionality, but the key=20 > sharing issue might make it harder to achieve FIPS 140-2 approval. >=20 > Steve Right - that's what I thought. However, that also means that it would be the address/SPI pair that would be important. I.e., there are two different kinds of failure: a) failed to lookup addr/SPI b) key found failed to work *IF* IPsec considers those different errors, then the pair is required.=20 If they're considered equivalent (logged the same, generate/don't generate the same internal error, etc.), then addr can be omitted. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www1.ietf.org/pipermail/ipsec/attachments/20041130/a60a32f5/signa ture.bin ------------------------------ Message: 5 Date: Tue, 30 Nov 2004 20:15:40 +0330 From: "mahdavi" Subject: [Ipsec] About case A and Case B? To: ipsec@ietf.org Message-ID: <20041130164432.M29958@ec.iut.ac.ir> Content-Type: text/plain; charset=3Dutf-8 I am working on a high speed secure router and there is something that I cant Understand what to do with it.=20 and that is these mysterious sentences. (I call these as Case A and Case B ) " a. use the value in the packet itself -- This will limit use of the SA to those packets which have this packet's value for the selector even if the selector for the policy entry has a range of allowed values or a wildcard for this selector. b. use the value associated with the policy entry -- If this were to be just a single value, then there would be no difference between (b) and (a).,......" Imagine a router that is IPSec aware (SG1).=20 HOST HOST C to K=3D=3D=3D=3D=3D=3D=3D=3D=3D|1| SG1 = |2|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DS= G2 --- M to X | / \ / =20 | / \ / =20 \-------------/ \------------------------/ =20 SG1 has two interfaces 1 and 2 .=20 outbound policy for interface 2 of SG1 says : -------------------------------------------------------- For any packet from host (C to k) going to host (M to X)=20 make a tunnel with SG2. USE CASE B=20 -------------------------------------------------------- This means to use one SA for all traffic traversing from (C - K) TO ( M - X ). Right?=20 What about this policy?=20 -------------------------------------------------------- For any packet from host (C to k) going to host (M to X)=20 make a tunnel with SG2. USE CASE A=20 -------------------------------------------------------- What that means? Does it mean to make separate SA's for any source-destination pair ? For example one for a packet traversing from C to M and one another for a packet giong from D to N and one another for a packet going from C to N ??? If so what is benefit of this ???=20 __________________________________________________________ __________________________________________________________ Question 2:=20 Before, I thought that Case A Is not usable in this situation and=20 this situation should be used with case b. Was Right ?=20 __________________________________________________________ __________________________________________________________ Question 3:=20 Can we have such a policy like below for inbound traffic for interface 1 of SG1? For inbound traffic for interface 1 of SG1 : (this is just one policy record) -------------------------------------------------------- For any packet from host (C to k) going to host (M to X)=20 make a tunnel with ITSELF (SOURCE OF Packet).=20 -------------------------------------------------------- In above policy because we wanted to have one policy for many tunnels=20 (in this case 9 tunnels each for each host C - K ) and ITSELF means having a tunnel with source of packet host.=20 Firstly, having such a policy is logical???=20 Secondly, does it mean Case A???=20 ____________________________________________________________ Best of regards=20 Mahdavi.=20 ------------------------------ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec End of Ipsec Digest, Vol 7, Issue 34 ************************************ *********************************************************************** This message is intended only for the use of the intended recipient and may contain information that is PRIVILEGED and/or CONFIDENTIAL. If you are not the intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error, please destroy all copies of this message and its attachments and notify us immediately. *********************************************************************** _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec