From ipsec-bounces@ietf.org Tue Nov 01 18:55:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX5yQ-0003Th-DL; Tue, 01 Nov 2005 18:55:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX5yO-0003TZ-Jc for ipsec@megatron.ietf.org; Tue, 01 Nov 2005 18:55:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24810 for ; Tue, 1 Nov 2005 18:55:03 -0500 (EST) Received: from kame195.kame.net ([203.178.141.195] helo=papa.tanu.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX6Cp-0001Ck-Hx for ipsec@ietf.org; Tue, 01 Nov 2005 19:10:22 -0500 Received: from localhost (ZP131110.ppp.dion.ne.jp [222.12.131.110]) by papa.tanu.org (8.12.9/8.12.8) with ESMTP id jA1NgbH6042968 for ; Wed, 2 Nov 2005 08:42:37 +0900 (JST) (envelope-from sakane@kame.net) To: ipsec@ietf.org X-Mailer: Cue version 0.8 (051011-1456/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20051102085504Q.sakane@kame.net> Date: Wed, 02 Nov 2005 08:55:04 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 206 X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Subject: [Ipsec] releasing racoon2 including 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 This is from the Racoon2 project. I am sorry for messing this mailing list. I know that this mailing list is not suitable for using the announcement of a software. However some people told me what the racoon2 state was when we released it before. So this is the first and the last announcement to this list. We are pleased to release the Racoon2, a IPsec key management system. The Racoon2 is a system to exchange and to install security parameters for the IPsec. It supports both the IKEv2 and the KINK. README is attached for detail. You can get the tarball from: ftp://ftp.kame.net/pub/racoon2/racoon2-20051102a.tgz Please ask to racoon2@kame.net if you have any question. Thank you. === $Id: README,v 1.32 2005/11/01 03:46:29 mk Exp $ This document describes the Racoon2 and the distribution kit. You have to read doc/INSTALL and doc/USAGE to use the Racoon2 after you read this document. Enjoy ! o Directory README : this file explaining the Racoon2 distribution. COPYRIGHT: contains the copyright. doc/ : specification, usage and memo. samples/ : configuration samples. lib/ : source files related to the library, libracoon.a kinkd/ : files related to the KINK daemon. iked/ : files related to the IKE daemon. spmd/ : files related to the SPM daemon. pskgen/ : files related to pskgen(8) o What is the Racoon2 ? The Racoon2 is a system to exchange and to install security parameters for the IPsec. This is provided by the Racoon2 Project in the WIDE Project, Japan. The project aims to provide the IPsec system for FreeBSD, NetBSD and Linux. There are some projects doing like that in the Internet community. We do not have any thought to compete with these communities. We rather like to collaborate with them though there is a language barrier. Currently the system supports the following specification: Internet Key Exchange (IKEv2) Protocol draft-ietf-ipsec-ikev2-17.txt draft-eronen-ipsec-ikev2-clarifications-06.txt Kerberized Internet Negotiation of Keys (KINK) draft-ietf-kink-kink-07.txt Note that the KINK protocol is work in progress, and changes which are incompatible with -07 are planned. When such changes are performed, the racoon2 KINK daemon will track the changes and *no care* for compatibilities with older racoon2 will taken. PF_KEY Key Management API, Version 2 RFC2367 The following protocols will be supported soon. The Internet Key Exchange (IKE) RFC2409 The system provides three daemons: iked, kinkd and spmd. Each daemon manages IKE, KINK and IPsec Policy respectively. o What features will the Racoon2 support ? Here is the list of features that we think to implement in a future. This is not complete list. This may be changed with no announcing. - English documentation. - IKEv2: configuration payload (mode-config) in iked. - SHISA support (WIDE MIP6 Implementation on *BSD) in iked. - MIPL support (MIP6 Implementation on Linux) in iked. - To follow the updates of the I-D of KINK. - Support for tunnel mode SAs in both iked and kinkd. - Support gracefully rekeying. - Configuration file converter from racoon1. - Easy configuration tool. - IKEv1 support in iked. o What is The Racoon2 system structure ? There are three daemons in the Racoon2 system. The following picture indicates the relationship between the daemons in the system. You have to run "spmd" AND one protocol daemon to exchange IPsec SAs. +--------+ +--------+ | iked |--(spmif)--+ +--(spmif)--| kinkd | +--------+ | | +--------+ | +--------+ | | | spmd | | | +--------+ | | | | | | | --(PFKEY)------------(PFKEY)-----------(PFKEY)-- | | | | | | +---------------------------------------------+ | Kernel | +---------------------------------------------+ "spmd" is the IPsec policy management daemon. It has two missions. First one is to manage IPsec policies. "spmd" will install IPsec policies and delete them from the kernel. It uses PF_KEYv2 for this purpose. Another is to cache the mapping table between IP addresses and FQDNs for KINK processing. "iked" processes the IKE protocol. It initiates the protocol, and processes the packet from the remote system. Then it installs IPsec SAs into the kernel by using PF_KEYv2. It also requests "spmd" to install IPsec policies if necessary by using "spmif" which is an abbreviation of spmd interface. Currently it only supports IKE version 2. "kinkd" is similar to "iked" except that it processes the KINK protocol. Current kinkd supports draft-ietf-kink-kink-06.txt, and newer revisions of this draft is expected to be incompatible with this version. When a newer draft (or RFC) is published, kinkd will follow it, and the support for older version will be dropped. o What is the difference from "previous racoon" ? "previous racoon" only supports IKEv1 [RFC2409]. The Racoon2 supports both IKEv2 and KINK, will also support IKEv1. The configuration is completely different because the Racoon2 system supports multiple key exchange protocols. o Contact Points If you have any question about the Racoon2, you can ask to the mailing list: racoon2@kame.net You should not ask them to other mailing lists like "racoon@kame.net", "kame-snap@kame.net", or "ipsec-tools-users@lists.sourceforge.net". If you want to help us or if you want to contribute, please contact us. It is welcome to give us any patch, any suggestion and any help. In particular, to check English documentations is very helpful for us. We are planning to dedicate the web site of the Racoon2 project and to provide the cvsweb to access the repository soon. o Copyright Basically this kit follows the BSD-like copyright. See the file: COPYRIGHT. In short, the code is freely available but with no warranty. The copyright holder is WIDE Project instead of the Racoon2 Project. This is because the Racoon2 Project belongs to the one of the working groups in the WIDE Project. o IPR consideration The Racoon2 Project takes no position regarding the validity or scope of any intellectual property rights or other rights that might be claimed to pertain to the implementation or use of the technology used in the Racoon2, or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. The Racoon2 Project simply reproduces the intellectual property rights statements that have been submitted to the IETF at concerning the IETF protocols embodied in the Racoon2. Certicom's Statement About IPR Claimed in RFC 3526, RFC 2409, draft-ietf-ipsec-ikev2, and Other IETF Specifications Using MODP Groups: Internet Key Exchange (IKEv2) Protocol: Microsoft's statement about IPR claimed in draft-ietf-ipsec-ikev2-08.txt: If you have a concern about the possible intellectual property rights associated with acquiring, compiling, modifying, or otherwise using the Racoon2 software, you should consult your own attorney. o Project Members Core project members are: Yutaka Yamashita Keio University Satoshi Inoue NEC Communication Systems Atsushi Fukumoto Toshiba Corporation Mitsuru Kanda Toshiba Corporation Kazunori Miyazawa Yokogawa Electric Corporation Ken'ichi Kamada Yokogawa Electric Corporation Shoichi Sakane Yokogawa Electric Corporation o Acknowledgments Thanks to Paul Hoffman. He suggested what we should think about the intellectual property rights related the IKEv2 protocol, and helped us to publish our IKEv2 code. Thanks to member of the WIDE project. We could not work without the great project. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 09 12:29:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZtl2-0002px-Mv; Wed, 09 Nov 2005 12:29:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZtl1-0002ps-IA for ipsec@megatron.ietf.org; Wed, 09 Nov 2005 12:29:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24035 for ; Wed, 9 Nov 2005 12:28:44 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZu13-00033F-Oe for ipsec@ietf.org; Wed, 09 Nov 2005 12:45:47 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id jA9HSQa02636 for ; Wed, 9 Nov 2005 18:28:26 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id jA9HSR4s097819 for ; Wed, 9 Nov 2005 18:28:27 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511091728.jA9HSR4s097819@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@ietf.org Date: Wed, 09 Nov 2005 18:28:27 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Ipsec] MIPv6 bootstrapping and 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 This message could be dropped by some mailing-list relays, at least I've received no comment (including negative :-) at all... IKEv2 is assumed to become the default mechanism in MIPv6 bootstrapping, both because the MIPv6 security between a mobile node and its home agent (HA) is based on IPsec and because IKEv2 is efficient, provides configuration, support legacy authentication, etc. Look at draft-ietf-mip6-ikev2-ipsec-04.txt ... But something IKEv2 doesn't (yet!) know to do is the assignment of the HA address, mainly because when you are talking with the HA you already have its address... MIPv6 has some HA address discovery mechanisms (a problem very similar to the SG discovery) and is looking for HA (address) assignment mechanisms. HAs on the same link share an IPv6 anycast address (a group address like multicast but messages are delivered to one member of the group and the format is the same than for unicast. IPv6 anycasts share some properties with multicasts: they must not use as source addresses and a stream of messages is not required to be delivered to the same node). A proposal is the initiator (aka mobile node aka VPN client) sends the first message (IKE_SA_INIT) to the anycast address, the receiving HA forwards it to the "best" HA which answers using its own unicast address. The initiator keeps this address as the responder address for further messages. IMHO we should enforce Cookie mechanism in this case: - we always get a full IKE_SA_INIT exchange using the right addresses - we can't mess NAT detection or other things relying on addresses - an anycast address is a good target for attacks so to always consider it is under attack is just pessimism Is there a problem I couldn't see? Is it a good/bad/don't-care idea? (BTW it is not mine) Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 09 13:32:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZukQ-0000K5-6k; Wed, 09 Nov 2005 13:32:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZukO-0000JZ-Kj for ipsec@megatron.ietf.org; Wed, 09 Nov 2005 13:32:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28328 for ; Wed, 9 Nov 2005 13:32:09 -0500 (EST) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZv0S-000544-EE for ipsec@ietf.org; Wed, 09 Nov 2005 13:49:12 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jA9IWIwp000443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Nov 2005 20:32:18 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jA9IWIKG002470; Wed, 9 Nov 2005 20:32: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: <17266.16562.46482.612816@fireball.kivinen.iki.fi> Date: Wed, 9 Nov 2005 20:32:18 +0200 From: Tero Kivinen To: Francis Dupont Subject: [Ipsec] MIPv6 bootstrapping and IKEv2 In-Reply-To: <200511091728.jA9HSR4s097819@givry.rennes.enst-bretagne.fr> References: <200511091728.jA9HSR4s097819@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 16 min X-Total-Time: 18 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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 Francis Dupont writes: > A proposal is the initiator (aka mobile node aka VPN client) sends > the first message (IKE_SA_INIT) to the anycast address, the receiving > HA forwards it to the "best" HA which answers using its own unicast > address. The initiator keeps this address as the responder address > for further messages. > > IMHO we should enforce Cookie mechanism in this case: > - we always get a full IKE_SA_INIT exchange using the right addresses > - we can't mess NAT detection or other things relying on addresses > - an anycast address is a good target for attacks so to always > consider it is under attack is just pessimism > > Is there a problem I couldn't see? Is it a good/bad/don't-care idea? > (BTW it is not mine) Hmm... so this means that exchange goes like this: Initiator Responder ========= ========== Initiator sends IKE_INIT_SA to anycast address. (IP_I:500 -> ANYCAST:500) HDR(A, 0), SAi1, KEi, Ni --> The packet is delivered to the best server servicing that anycast address. Server replies using his own IP, not anycast address, this is modification to the normal MUST processing of the IKEv2 in section 2.11. On the other hand this can also be considered as if there was NAT in front of the Responder who NAT'ed the ANYCAST:500 to IP_R:500 before the packet appeared to the IKE server, so IKE actually did see packet having (IP_I:500 -> IP_R:500), not (IP_I:500 -> ANYCAST:500). <-- (IP_R:500, IP_I:500) HDR(A, 0) N(COOKIE) Initiator needs to process that reply, even when it is coming from different IP-address to where it was sent. This should not cause problems, as it did know that it sent it to anycast address, and can enable special handling for that. It notices it is N(COOKIE) and retries, but now it MUST use the IP_R:500 from the return packet not the ANYCAST:500 as it did on the first packet: (IP_I:500 -> IP_R:500) HDR(A, 0), N(COOKIE), SAi1, KEi, Ni --> From this point on the exchange is normal IKEv2 exchange. I think that should work, it do require some changes to the both server and client, depending how the anycast is done on the operating system stack. If the anycast server will get the packet in in NAT'ed form, i.e. where the destination address is already changed from the ANYCAST to the real IP-address to use (don't know if they do that or if not), then standard IKEv2 server would work, without any modifications. If the IKEv2 server gets the anycast address in, then it needs to replace that with real IP when sending reply. The client end needs to know that it is initiating to annycast address, and needs to replace the anycast destination IP-address with the address from the reply packet. In case there is attacker replying before the real server replies (or in case the packet goes to multiple servers because of misconfiguration), the client will probably need to similar thing than 2.4 3rd last paragraph, i.e. if it receives multiple replies, it needs to reply to all of them, and once he manages to get one through the IKE_AUTH it should discard the others. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 10 05:27:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea9e2-0006oe-4W; Thu, 10 Nov 2005 05:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea9dz-0006oZ-QF for ipsec@megatron.ietf.org; Thu, 10 Nov 2005 05:26:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22267 for ; Thu, 10 Nov 2005 05:26:31 -0500 (EST) Received: from web30002.mail.mud.yahoo.com ([68.142.200.65]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ea9u5-0005QC-JQ for ipsec@ietf.org; Thu, 10 Nov 2005 05:43:44 -0500 Received: (qmail 27506 invoked by uid 60001); 10 Nov 2005 10:26:41 -0000 Message-ID: <20051110102641.27504.qmail@web30002.mail.mud.yahoo.com> Received: from [203.160.1.39] by web30002.mail.mud.yahoo.com via HTTP; Thu, 10 Nov 2005 02:26:41 PST Date: Thu, 10 Nov 2005 02:26:41 -0800 (PST) From: "Buồn quá" To: ipsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Ipsec] Designed VPN over IPSec, but use my algorithm ? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: buonqua802000@yahoo.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2102955046==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============2102955046== Content-Type: multipart/alternative; boundary="0-913971455-1131618401=:26885" --0-913971455-1131618401=:26885 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi folks ! I have designed VPN over IPSec, and it's gone well (I used ESP protocol and algorithm DES3). But now, i want to use other algorithm (Not DES3 or MD5). I want to use algorithm of me, but i don't way to do it. Someone can help me about that, and show me the line have to change to do it. Thanks very much --------------------------------- Yahoo! FareChase - Search multiple travel sites in one click. --0-913971455-1131618401=:26885 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi folks !
 
             I have designed VPN over IPSec, and it's gone well (I used ESP protocol and algorithm DES3). But now, i want to use other algorithm (Not DES3 or MD5). I want to use algorithm of me, but i don't way to do it. Someone can help me about that, and show me the line have to change to do it.
 
 
Thanks very much

Yahoo! FareChase - Search multiple travel sites in one click. --0-913971455-1131618401=:26885-- --===============2102955046== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============2102955046==-- From ipsec-bounces@ietf.org Thu Nov 10 07:24:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaBU8-0006oq-8w; Thu, 10 Nov 2005 07:24:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaBU7-0006ol-3l for ipsec@megatron.ietf.org; Thu, 10 Nov 2005 07:24:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28417 for ; Thu, 10 Nov 2005 07:24:27 -0500 (EST) Received: from web30003.mail.mud.yahoo.com ([68.142.200.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EaBkJ-0008NH-Ee for ipsec@ietf.org; Thu, 10 Nov 2005 07:41:40 -0500 Received: (qmail 77286 invoked by uid 60001); 10 Nov 2005 12:24:44 -0000 Message-ID: <20051110122444.77284.qmail@web30003.mail.mud.yahoo.com> Received: from [203.160.1.39] by web30003.mail.mud.yahoo.com via HTTP; Thu, 10 Nov 2005 04:24:44 PST Date: Thu, 10 Nov 2005 04:24:44 -0800 (PST) From: "Buồn quá" To: ipsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Ipsec] Designed VPN over IPSec, but use my algorithm ? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: buonqua802000@yahoo.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1693768274==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1693768274== Content-Type: multipart/alternative; boundary="0-1467979510-1131625484=:77036" --0-1467979510-1131625484=:77036 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi folks ! I have designed VPN over IPSec, and it's gone well (I used ESP protocol and algorithm DES3). But now, i want to use other algorithm (Not DES3 or MD5). I want to use algorithm of me, but i don't way to do it. Someone can help me about that, and show me the line have to change to do it. Thanks very much --------------------------------- Yahoo! FareChase - Search multiple travel sites in one click. --0-1467979510-1131625484=:77036 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi folks !
 
             I have designed VPN over IPSec, and it's gone well (I used ESP protocol and algorithm DES3). But now, i want to use other algorithm (Not DES3 or MD5). I want to use algorithm of me, but i don't way to do it. Someone can help me about that, and show me the line have to change to do it.
 
 
Thanks very much

Yahoo! FareChase - Search multiple travel sites in one click. --0-1467979510-1131625484=:77036-- --===============1693768274== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1693768274==-- From ipsec-bounces@ietf.org Fri Nov 11 06:52:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaXSL-0001Wz-Td; Fri, 11 Nov 2005 06:52:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaXSK-0001Wr-FP for ipsec@megatron.ietf.org; Fri, 11 Nov 2005 06:52:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03059 for ; Fri, 11 Nov 2005 06:52:02 -0500 (EST) Received: from smtp.um.es ([155.54.212.105] helo=mail.um.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaXij-00026Q-2x for ipsec@ietf.org; Fri, 11 Nov 2005 07:09:30 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 01E6423C3D3 for ; Fri, 11 Nov 2005 12:52:17 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 26781-01-48 for ; Fri, 11 Nov 2005 12:52:16 +0100 (CET) Received: from mistral.dif.um.es (mistral.dif.um.es [155.54.1.60]) by mail.um.es (Postfix) with ESMTP id D534C23C2F1 for ; Fri, 11 Nov 2005 12:52:16 +0100 (CET) Received: from pcalex (openikev2.dif.um.es [155.54.210.130]) by mistral.dif.um.es (Postfix) with ESMTP id F020385C004 for ; Fri, 11 Nov 2005 12:45:37 +0100 (CET) From: Alejandro Perez Mendez To: ipsec@ietf.org Content-Type: text/plain Date: Fri, 11 Nov 2005 12:52:20 +0100 Message-Id: <1131709940.3008.19.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.3 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Subject: [Ipsec] PFS 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 some troubles understanding how PFS is performed when proposal has more than one protocol. What is the desired way to indicate we want to use AH + ESP protocol and we also want to refresh DH material? Where we must include the DH_ID transform, in the ESP protocol, in the AH protocol, in both...? If a proposal like the following is valid (I suppouse it is), must we include two KE payloads in the CREATE_CHILD_SA exchange? It is possible? I suppouse that not but I don't know how perform this funcionability. PROPOSAL #1---------> PROTOCOL ESP |---------> TRANSFORM ENCR 3DES | |---------> TRANSFORM ENCR AES256 | |---------> TRANSFORM INTEG SHA1 | |---------> TRANSFORM DH 2 | | .... | |---------> PROTOCOL AH |---------> TRANSFORM INTEG MD5 | |---------> TRANSFORM DH 1 | | .... -- Alejandro Perez Mendez Pedro Javier Fernandez Ruiz _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 11 11:46:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eac2g-0004gs-Vr; Fri, 11 Nov 2005 11:46:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eac2f-0004gn-Lw for ipsec@megatron.ietf.org; Fri, 11 Nov 2005 11:46:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18711 for ; Fri, 11 Nov 2005 11:45:52 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EacJ7-0003co-1C for ipsec@ietf.org; Fri, 11 Nov 2005 12:03:22 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 11 Nov 2005 11:46:10 -0500 X-IronPort-AV: i="3.99,119,1131339600"; d="scan'208"; a="75487705:sNHT26837404" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jABGjbxU002561; Fri, 11 Nov 2005 11:46:08 -0500 (EST) Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 11 Nov 2005 11:46:07 -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 Subject: RE: [Ipsec] PFS Date: Fri, 11 Nov 2005 11:46:06 -0500 Message-ID: <13E3DA8B48E17D4C96D261A36A23FCD6D0961D@xmb-rtp-208.amer.cisco.com> Thread-Topic: [Ipsec] PFS Thread-Index: AcXmtzh7WUsG1cu0RZuerQ8JRgh2EQAJ6nxw From: "Stephane Beaulieu \(stephane\)" To: "Alejandro Perez Mendez" , X-OriginalArrivalTime: 11 Nov 2005 16:46:07.0833 (UTC) FILETIME=[69E04C90:01C5E6DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: 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 Alejandro, You should include the DH transform in both, and set them to identical values. Stephane.=20 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf Of Alejandro Perez Mendez > Sent: Friday, November 11, 2005 6:52 AM > To: ipsec@ietf.org > Subject: [Ipsec] PFS >=20 > Hi. I have some troubles understanding how PFS is performed=20 > when proposal has more than one protocol. >=20 > What is the desired way to indicate we want to use AH + ESP=20 > protocol and we also want to refresh DH material? > Where we must include the DH_ID transform, in the ESP=20 > protocol, in the AH protocol, in both...? >=20 > If a proposal like the following is valid (I suppouse it is),=20 > must we include two KE payloads in the CREATE_CHILD_SA=20 > exchange? It is possible? > I suppouse that not but I don't know how perform this funcionability. >=20 > PROPOSAL #1---------> PROTOCOL ESP |---------> TRANSFORM ENCR 3DES > | |---------> TRANSFORM ENCR AES256 > | |---------> TRANSFORM INTEG SHA1 > | |---------> TRANSFORM DH 2 > | | .... > | =20 > |---------> PROTOCOL AH |---------> TRANSFORM INTEG MD5 > | |---------> TRANSFORM DH 1 > | | .... >=20 >=20 > -- > Alejandro Perez Mendez Pedro=20 > Javier Fernandez Ruiz >=20 >=20 > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 11 14:19:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaeQj-0007Uj-Qb; Fri, 11 Nov 2005 14:19:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaeQh-0007T9-PE for ipsec@megatron.ietf.org; Fri, 11 Nov 2005 14:19:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29143 for ; Fri, 11 Nov 2005 14:18:49 -0500 (EST) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaehA-0001ve-8f for ipsec@ietf.org; Fri, 11 Nov 2005 14:36:21 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jABJIsnQ027918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Nov 2005 21:18:54 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jABJIrhg011414; Fri, 11 Nov 2005 21:18: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: <17268.61085.962694.989069@fireball.kivinen.iki.fi> Date: Fri, 11 Nov 2005 21:18:53 +0200 From: Tero Kivinen To: "Stephane Beaulieu \(stephane\)" Subject: RE: [Ipsec] PFS In-Reply-To: <13E3DA8B48E17D4C96D261A36A23FCD6D0961D@xmb-rtp-208.amer.cisco.com> References: <13E3DA8B48E17D4C96D261A36A23FCD6D0961D@xmb-rtp-208.amer.cisco.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 11 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 I assume you are talking about IKEv2 here. Stephane Beaulieu \(stephane\) writes: > You should include the DH transform in both, and set them to identical > values. Yes, if you want to support that kind of extension to RFC2401bis you probably should do it that way (and only include one KE payload). > > What is the desired way to indicate we want to use AH + ESP > > protocol and we also want to refresh DH material? Note, that in the RFC2401bis you do not create AH + ESP with that kind of exchang. Instead you create AH as a separate exchange and put traffic selectors to be ESP, and then create the ESP SA separately with real traffic selectors. > > If a proposal like the following is valid (I suppouse it is), > > must we include two KE payloads in the CREATE_CHILD_SA > > exchange? It is possible? I do not think it is valid to have to different diffie hellman groups, and two KE payloads. On the other hand when using RFC2401bis architecture this issue does not come up, as there is no ESP and AH protocol in one proposal there, as the two SAs are set up separately. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 11 14:25:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaeX4-0003Cr-2q; Fri, 11 Nov 2005 14:25:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaeX2-0003Cd-FL for ipsec@megatron.ietf.org; Fri, 11 Nov 2005 14:25:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29637 for ; Fri, 11 Nov 2005 14:25:22 -0500 (EST) Received: from 84-121-24-204.onocable.ono.com ([84.121.24.204] helo=localhost.localdomain) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaenW-0002D7-64 for ipsec@ietf.org; Fri, 11 Nov 2005 14:42:54 -0500 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 022228E6B1; Fri, 11 Nov 2005 20:25:41 +0100 (CET) Subject: RE: [Ipsec] PFS From: Alejandro Perez Mendez To: Tero Kivinen In-Reply-To: <17268.61085.962694.989069@fireball.kivinen.iki.fi> References: <13E3DA8B48E17D4C96D261A36A23FCD6D0961D@xmb-rtp-208.amer.cisco.com> <17268.61085.962694.989069@fireball.kivinen.iki.fi> Content-Type: text/plain Date: Fri, 11 Nov 2005 20:25:41 +0100 Message-Id: <1131737141.7992.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.5.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, "Stephane Beaulieu \(stephane\)" 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 vie, 2005-11-11 at 21:18 +0200, Tero Kivinen wrote: > I assume you are talking about IKEv2 here. Yes, I am. > Stephane Beaulieu \(stephane\) writes: > > You should include the DH transform in both, and set them to identical > > values. > > Yes, if you want to support that kind of extension to RFC2401bis you > probably should do it that way (and only include one KE payload). I also think this is the best way to do that. > > > What is the desired way to indicate we want to use AH + ESP > > > protocol and we also want to refresh DH material? > > Note, that in the RFC2401bis you do not create AH + ESP with that kind > of exchang. Instead you create AH as a separate exchange and put > traffic selectors to be ESP, and then create the ESP SA separately > with real traffic selectors. I know it, but IKEv2 support this feature and I'm interesting in a IKEv2 over RFC 2401 implementation. > > > If a proposal like the following is valid (I suppouse it is), > > > must we include two KE payloads in the CREATE_CHILD_SA > > > exchange? It is possible? > > I do not think it is valid to have to different diffie hellman groups, > and two KE payloads. On the other hand when using RFC2401bis > architecture this issue does not come up, as there is no ESP and AH > protocol in one proposal there, as the two SAs are set up separately. Thank you all for the clarifications. Best Regards! -- Alejandro Perez Mendez _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Nov 13 10:13:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbJXU-0005yo-AC; Sun, 13 Nov 2005 10:13:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbJXS-0005yj-M0 for ipsec@megatron.ietf.org; Sun, 13 Nov 2005 10:13:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11441 for ; Sun, 13 Nov 2005 10:12:31 -0500 (EST) Received: from xproxy.gmail.com ([66.249.82.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbJoI-0006N1-FU for Ipsec@ietf.org; Sun, 13 Nov 2005 10:30:27 -0500 Received: by xproxy.gmail.com with SMTP id s6so1352343wxc for ; Sun, 13 Nov 2005 07:12:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=ouRl8cb/xE9/yuzwI2tf69vCsAIGIjVFfbXbGq3N785LkVBnE2VBASA3BJFqVektb/zkYQ6sqivpUnZas+jFCDWzsOWSBbOAnm3en+Yy4EJxQg+uGOOcUnRS3wJ/h+hlzX1XbZBiTpqa/LMRhiDjadp2nm9PJP9fZqTX96anGMg= Received: by 10.65.159.9 with SMTP id l9mr4624176qbo; Sun, 13 Nov 2005 07:12:58 -0800 (PST) Received: by 10.65.211.11 with HTTP; Sun, 13 Nov 2005 07:12:58 -0800 (PST) Message-ID: Date: Sun, 13 Nov 2005 23:12:58 +0800 From: Wade Yin To: Ipsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 2.3 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Subject: [Ipsec] how does multi-proposal be processed in quick mode... 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="===============0843922928==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0843922928== Content-Type: multipart/alternative; boundary="----=_Part_6683_30721818.1131894778614" ------=_Part_6683_30721818.1131894778614 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, How does ipsec-tools process Multi-proposal: when the initiator/responder has two or more proposal configured with different protocol and security algorithm, how should entitys chosen a right one? Which function is use to distinguish the different proposal and transofrm payloads? Just give me some tips pls. Thanks.. ----------------------------------------------------- att: In 2408: section 4.2 "...Each proposal payload contain a security parameter index (SPI) and ensures that the SPI is associated with the protocol-id in accordance with the Internet security architecture.... Wade ------=_Part_6683_30721818.1131894778614 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
Hi,
  How does ipsec-tools process Multi-proposal: when the init= iator/responder has two or more proposal configured with different protocol= and security algorithm, how should entitys chosen a right one? <= /div>
 
 Which function is use to distinguish the different proposal and = transofrm payloads?  Just give me some tips pls. Thanks..
 
-----------------------------------------------------
att:
 In 2408:  section 4.2
"...Each proposal payload contain a security parameter index (SPI= ) and ensures that the SPI is associated with the protocol-id in accordance= with the Internet security architecture....
 
 
 
Wade
 
------=_Part_6683_30721818.1131894778614-- --===============0843922928== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0843922928==-- From ipsec-bounces@ietf.org Mon Nov 14 01:09:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbXWs-0003gZ-64; Mon, 14 Nov 2005 01:09:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbXWq-0003gO-Hf for ipsec@megatron.ietf.org; Mon, 14 Nov 2005 01:09:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27579 for ; Mon, 14 Nov 2005 01:08:49 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbXnn-0007Zk-SM for ipsec@ietf.org; Mon, 14 Nov 2005 01:26:53 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAE696cM016710; Mon, 14 Nov 2005 08:09:07 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 08:09:01 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 08:09:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 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] PFS Date: Mon, 14 Nov 2005 08:08:59 +0200 Message-ID: Thread-Topic: [Ipsec] PFS Thread-Index: AcXm9mWiq2Tx4SyGStyJ7VPzWkFJigB6p0Bg To: X-OriginalArrivalTime: 14 Nov 2005 06:09:01.0538 (UTC) FILETIME=[E877D420:01C5E8E1] X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Alejandro Perez Mendez wrote: > > Note, that in the RFC2401bis you do not create AH + ESP with > > that kind of exchang. Instead you create AH as a separate > > exchange and put traffic selectors to be ESP, and then create > > the ESP SA separately with real traffic selectors. >=20 > I know it, but IKEv2 support this feature and I'm interesting in=20 > a IKEv2 over RFC 2401 implementation. There is currently no such thing as "IKEv2 over RFC 2401":=20 the IKEv2 base specification requires 2401bis. (I guess it would be possible to write an "IKEv2-for-2401" spec that would specify some RFC2401-only extensions to IKEv2, but I'm=20 not sure why you would want to do that.) Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 14 03:56:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eba8Y-0003yP-4z; Mon, 14 Nov 2005 03:56:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eba8W-0003yA-5n for ipsec@megatron.ietf.org; Mon, 14 Nov 2005 03:56:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06389 for ; Mon, 14 Nov 2005 03:55:52 -0500 (EST) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbaPU-0004Ft-Vs for ipsec@ietf.org; Mon, 14 Nov 2005 04:13:58 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jAE8u1C0002762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Nov 2005 10:56:01 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jAE8u0B3029538; Mon, 14 Nov 2005 10:56:00 +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: <17272.20768.467097.756125@fireball.kivinen.iki.fi> Date: Mon, 14 Nov 2005 10:56:00 +0200 From: Tero Kivinen To: Alejandro Perez Mendez Subject: RE: [Ipsec] PFS In-Reply-To: <1131737141.7992.4.camel@localhost.localdomain> References: <13E3DA8B48E17D4C96D261A36A23FCD6D0961D@xmb-rtp-208.amer.cisco.com> <17268.61085.962694.989069@fireball.kivinen.iki.fi> <1131737141.7992.4.camel@localhost.localdomain> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, "Stephane Beaulieu \(stephane\)" 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 Alejandro Perez Mendez writes: > I know it, but IKEv2 support this feature and I'm interesting in a IKEv2 > over RFC 2401 implementation. IKEv2 does not really specify that feature, but it does not forbid the feature either. As you can see from your questions it is not specified in the IKEv2 document (and should not be specified, as IKEv2 do require RFC2401bis architecture). Using IKEv2 and old RFC2401 architecture have other problems also, so I would not recommend that combination. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 14 04:05:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbaH5-0005EB-9D; Mon, 14 Nov 2005 04:05:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbaH3-0005E1-MR for ipsec@megatron.ietf.org; Mon, 14 Nov 2005 04:05:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06832 for ; Mon, 14 Nov 2005 04:04:41 -0500 (EST) Received: from smtp.um.es ([155.54.212.105] helo=mail.um.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbaY1-0004WI-Nx for ipsec@ietf.org; Mon, 14 Nov 2005 04:22:48 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id AF44123C0EB; Mon, 14 Nov 2005 10:04:52 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18114-02-18; Mon, 14 Nov 2005 10:04:52 +0100 (CET) Received: from mistral.dif.um.es (mistral.dif.um.es [155.54.1.60]) by mail.um.es (Postfix) with ESMTP id 5C52A23C324; Mon, 14 Nov 2005 10:04:47 +0100 (CET) Received: from pcalex (openikev2.dif.um.es [155.54.210.130]) by mistral.dif.um.es (Postfix) with ESMTP id 4A3D285C008; Mon, 14 Nov 2005 09:57:35 +0100 (CET) Subject: RE: [Ipsec] PFS From: Alejandro Perez Mendez To: Tero Kivinen In-Reply-To: <17272.20768.467097.756125@fireball.kivinen.iki.fi> References: <13E3DA8B48E17D4C96D261A36A23FCD6D0961D@xmb-rtp-208.amer.cisco.com> <17268.61085.962694.989069@fireball.kivinen.iki.fi> <1131737141.7992.4.camel@localhost.localdomain> <17272.20768.467097.756125@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=utf-8 Date: Mon, 14 Nov 2005 10:04:57 +0100 Message-Id: <1131959097.10948.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, "Stephane Beaulieu \(stephane\)" 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 El lun, 14-11-2005 a las 10:56 +0200, Tero Kivinen escribi=C3=B3: > Alejandro Perez Mendez writes: > > I know it, but IKEv2 support this feature and I'm interesting in a IK= Ev2 > > over RFC 2401 implementation. >=20 > IKEv2 does not really specify that feature, but it does not forbid the > feature either. As you can see from your questions it is not > specified in the IKEv2 document=20 But a AH + ESP combination it is allowed in the specification since PROPOSAL structure can contain more than one protocol substructure. Why is this allowed if the correspondent behaviour is not specified? > (and should not be specified, as IKEv2 > do require RFC2401bis architecture). >=20 > Using IKEv2 and old RFC2401 architecture have other problems also, so > I would not recommend that combination.=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 14 04:22:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbaXj-0000BO-LY; Mon, 14 Nov 2005 04:22:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbaXh-0000BJ-HU for ipsec@megatron.ietf.org; Mon, 14 Nov 2005 04:22:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07590 for ; Mon, 14 Nov 2005 04:21:53 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebaog-0004zf-JD for ipsec@ietf.org; Mon, 14 Nov 2005 04:40:00 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAE9HeRl026928; Mon, 14 Nov 2005 11:17:44 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 11:22:15 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 11:22:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 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] PFS Date: Mon, 14 Nov 2005 11:22:14 +0200 Message-ID: Thread-Topic: [Ipsec] PFS Thread-Index: AcXo+u1evaNAC79aT7aInbgym0EssgAAPt/w To: , X-OriginalArrivalTime: 14 Nov 2005 09:22:15.0432 (UTC) FILETIME=[E6F7A880:01C5E8FC] X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: 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 Alejandro Perez Mendez wrote: > But a AH + ESP combination it is allowed in the specification=20 > since PROPOSAL structure can contain more than one protocol=20 > substructure. Why is this allowed if the correspondent behaviour=20 > is not specified? IKEv2 does not forbid having more than one protocol substructure=20 so that it can be later extended to create other types of SAs than those defined in 2401bis. But those other types of SAs are=20 not part of the IKEv2 base specification (e.g. draft-maino-fcsp-02=20 extends IKEv2 to create fibre channel SAs). Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 14 07:56:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbdtI-0002c7-Ke; Mon, 14 Nov 2005 07:56:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbdtH-0002bj-BW for ipsec@megatron.ietf.org; Mon, 14 Nov 2005 07:56:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18314 for ; Mon, 14 Nov 2005 07:56:24 -0500 (EST) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbeAI-00031P-6S for ipsec@ietf.org; Mon, 14 Nov 2005 08:14:31 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jAECuI2k016977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Nov 2005 14:56:18 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jAECuHgF021276; Mon, 14 Nov 2005 14:56: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: <17272.35185.374286.933235@fireball.kivinen.iki.fi> Date: Mon, 14 Nov 2005 14:56:17 +0200 From: Tero Kivinen To: Alejandro Perez Mendez Subject: RE: [Ipsec] PFS In-Reply-To: <1131959097.10948.2.camel@localhost.localdomain> References: <13E3DA8B48E17D4C96D261A36A23FCD6D0961D@xmb-rtp-208.amer.cisco.com> <17268.61085.962694.989069@fireball.kivinen.iki.fi> <1131737141.7992.4.camel@localhost.localdomain> <17272.20768.467097.756125@fireball.kivinen.iki.fi> <1131959097.10948.2.camel@localhost.localdomain> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 12 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, "Stephane Beaulieu \(stephane\)" 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 Alejandro Perez Mendez writes: > > IKEv2 does not really specify that feature, but it does not forbid the > > feature either. As you can see from your questions it is not > > specified in the IKEv2 document > > But a AH + ESP combination it is allowed in the specification since > PROPOSAL structure can contain more than one protocol substructure. Why > is this allowed if the correspondent behaviour is not specified? Mostly because it was copied from the old IKEv1 structure. Another reason was to keep that open for to allow negotiation of multiple protocols. RFC2401bis finished after IKEv2 and it decided that we do not need that feature, thus IKEv2 implementations need not to implement it as it is not needed in the RFC2401bis architecture. Even if you would want to use it, you need to notice, that as it is not part of the RFC2401bis architecture, that will mean that other implementations will NOT implement it, thus your extension will be non-standard extension which will not interoperate with implementation following the RFC2401bis standard. Why do you want to do that in non-standard way? Wouldn't it be better to implement it as specified in the RFC2401bis standard? -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 14 09:36:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbfR7-0005UM-NX; Mon, 14 Nov 2005 09:35:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbfR2-0005Tm-5R for ipsec@megatron.ietf.org; Mon, 14 Nov 2005 09:35:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24642 for ; Mon, 14 Nov 2005 09:35:20 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebfi4-0006IQ-SL for ipsec@ietf.org; Mon, 14 Nov 2005 09:53:29 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id jAEEZNH18064; Mon, 14 Nov 2005 15:35:23 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id jAEEZNtE035131; Mon, 14 Nov 2005 15:35:23 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511141435.jAEEZNtE035131@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen Subject: Re: [Ipsec] MIPv6 bootstrapping and IKEv2 In-reply-to: Your message of Wed, 09 Nov 2005 20:32:18 +0200. <17266.16562.46482.612816@fireball.kivinen.iki.fi> Date: Mon, 14 Nov 2005 15:35:23 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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 your previous mail you wrote: Hmm... so this means that exchange goes like this: Initiator Responder ========= ========== Initiator sends IKE_INIT_SA to anycast address. (IP_I:500 -> ANYCAST:500) HDR(A, 0), SAi1, KEi, Ni --> The packet is delivered to the best server servicing that anycast address. Server replies using his own IP, not anycast address, this is modification to the normal MUST processing of the => there is a conflicting MUST about no anycast in a source address. IKEv2 in section 2.11. On the other hand this can also be considered as if there was NAT in front of the Responder who NAT'ed the ANYCAST:500 to IP_R:500 before the packet appeared to the IKE server, so IKE actually did see packet having (IP_I:500 -> IP_R:500), not (IP_I:500 -> ANYCAST:500). => yes, even if the code getting the anycasted message is in IKE itself, it should be a special case because of the source address of the reply and possible NAT detection/prohibition. <-- (IP_R:500, IP_I:500) HDR(A, 0) N(COOKIE) Initiator needs to process that reply, even when it is coming from different IP-address to where it was sent. => it could know it will be the cast (anycast addresses can be recognized, and this should be the case here). This should not cause problems, as it did know that it sent it to anycast address, and can enable special handling for that. => exactly It notices it is N(COOKIE) and retries, but now it MUST use the IP_R:500 from the return packet not the ANYCAST:500 as it did on the first packet: (IP_I:500 -> IP_R:500) HDR(A, 0), N(COOKIE), SAi1, KEi, Ni --> From this point on the exchange is normal IKEv2 exchange. => yes, IMHO it is important to have a minimal change in the IKE code. I think that should work, it do require some changes to the both server and client, depending how the anycast is done on the operating system stack. => it is done as multicast on reception: you can't bind an anycast address, you have to bind only the port and get packets to any destination address. If the anycast server will get the packet in in NAT'ed form, i.e. where the destination address is already changed from the ANYCAST to the real IP-address to use (don't know if they do that or if not), => IMHO the best way is to do that but with an extra level of encapsulation (i.e., not NAT'ed). then standard IKEv2 server would work, without any modifications. => as this is simple to do only if a standard IKEv2 server doesn't run on the same box than the one receiving anycast message, IMHO it is better to add a small anycast handler in the lower layer reception code. If the IKEv2 server gets the anycast address in, then it needs to replace that with real IP when sending reply. The client end needs to know that it is initiating to annycast address, and needs to replace the anycast destination IP-address with the address from the reply packet. In case there is attacker replying before the real server replies (or in case the packet goes to multiple servers because of misconfiguration), the client will probably need to similar thing than 2.4 3rd last paragraph, i.e. if it receives multiple replies, it needs to reply to all of them, and once he manages to get one through the IKE_AUTH it should discard the others. => yes, in the two possible attacks on the initial exchange we already have the cookie stuff for the receiver side (so we can publish the anycast address without trouble, one of the ideas behind the HA assignment is to not offer the Home Agents as victims for DoS), the initiator side should be done as specified for standard IKEv2... BTW my concern is to introduce no new possible security concern, it seems we agree it is the case, i.e., I can write down the proposal in an I-D. Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 14 20:56:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebq43-0000Mp-CS; Mon, 14 Nov 2005 20:56:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebq41-0000Mg-95 for ipsec@megatron.ietf.org; Mon, 14 Nov 2005 20:56:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20285 for ; Mon, 14 Nov 2005 20:56:17 -0500 (EST) Received: from web30002.mail.mud.yahoo.com ([68.142.200.65]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EbqL3-0000Hv-S2 for ipsec@ietf.org; Mon, 14 Nov 2005 21:14:32 -0500 Received: (qmail 43173 invoked by uid 60001); 15 Nov 2005 01:56:33 -0000 Message-ID: <20051115015633.43171.qmail@web30002.mail.mud.yahoo.com> Received: from [203.160.1.39] by web30002.mail.mud.yahoo.com via HTTP; Mon, 14 Nov 2005 17:56:33 PST Date: Mon, 14 Nov 2005 17:56:33 -0800 (PST) From: "Buồn quá" To: ipsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ipsec] How to use other algorithm X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: buonqua802000@yahoo.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1325405413==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1325405413== Content-Type: multipart/alternative; boundary="0-160582052-1132019793=:42748" --0-160582052-1132019793=:42748 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi folks ! I want to other encryption algorithm in IPSec, but i don't the way to do it. If someone knows about it, please tell me what i do ? Thanks --------------------------------- Yahoo! FareChase - Search multiple travel sites in one click. --0-160582052-1132019793=:42748 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi folks !
 
         I want to other encryption algorithm in IPSec, but i don't the way to do it. If someone knows about it, please tell me what i do ?
 
Thanks

Yahoo! FareChase - Search multiple travel sites in one click. --0-160582052-1132019793=:42748-- --===============1325405413== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1325405413==-- From ipsec-bounces@ietf.org Tue Nov 15 04:11:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebwr4-00074Y-MA; Tue, 15 Nov 2005 04:11:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebwr2-00074S-GG for ipsec@megatron.ietf.org; Tue, 15 Nov 2005 04:11:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12213 for ; Tue, 15 Nov 2005 04:11:19 -0500 (EST) Received: from imx11.toshiba.co.jp ([61.202.160.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebx88-0005M1-Fw for ipsec@ietf.org; Tue, 15 Nov 2005 04:29:39 -0500 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id jAF9BUFF004702 for ; Tue, 15 Nov 2005 18:11:30 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id jAF9BjLP002288 for ipsec@ietf.org; Tue, 15 Nov 2005 18:11:45 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id UAA02284; Tue, 15 Nov 2005 18:11:45 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id jAF9BT3u026062 for ; Tue, 15 Nov 2005 18:11:29 +0900 (JST) Received: by toshiba.co.jp id jAF9BSWn004608; Tue, 15 Nov 2005 18:11:28 +0900 (JST) To: ipsec@ietf.org Date: Tue, 15 Nov 2005 18:11:28 +0900 From: Fukumoto Atsushi Message-Id: <200511150911.jAF9BSWn004608@toshiba.co.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ipsec] IKEv2 CHILD_SA handling after rekeying IKE_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 I want a confirmation or clarification about CHILD SA handling after rekeying the parent IKE SA. IKEv2 draft-17 section 1.4 states: Control messages that pertain to an IKE_SA MUST be sent under that IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent under the protection of the IKE_SA which generated them (or its successor if the IKE_SA was replaced for the purpose of rekeying). After rekeying IKE SA, there may be redundant IKE SAs, according to section 2.8. Thus, I suppose, an implementation MUST be able to accept any one of successors of IKE_SA to be used to control CHILD_SA. Deleting IKE_SA implicitly closes all associated CHILD_SAs (draft section 2.4). I suppose it must be only if the children are not shared with other IKE_SAs. Am I right with this interpretation? FUKUMOTO Atsushi atsushi.fukumoto@toshiba.co.jp _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 15 04:28:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebx6p-0003QM-Hs; Tue, 15 Nov 2005 04:28:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebx6o-0003QH-LW for ipsec@megatron.ietf.org; Tue, 15 Nov 2005 04:28:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13082 for ; Tue, 15 Nov 2005 04:27:38 -0500 (EST) Received: from smtp.um.es ([155.54.212.105] helo=mail.um.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbxO0-0005rl-Cq for ipsec@ietf.org; Tue, 15 Nov 2005 04:45:57 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id E217E1FA330; Tue, 15 Nov 2005 10:27:50 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 26338-01-19; Tue, 15 Nov 2005 10:27:50 +0100 (CET) Received: from mistral.dif.um.es (mistral.dif.um.es [155.54.1.60]) by mail.um.es (Postfix) with ESMTP id 416EF1FA312; Tue, 15 Nov 2005 10:27:50 +0100 (CET) Received: from pcalex (openikev2.dif.um.es [155.54.210.130]) by mistral.dif.um.es (Postfix) with ESMTP id 9261085C004; Tue, 15 Nov 2005 10:20:25 +0100 (CET) Subject: Re: [Ipsec] IKEv2 CHILD_SA handling after rekeying IKE_SA From: Alejandro Perez Mendez To: Fukumoto Atsushi In-Reply-To: <200511150911.jAF9BSWn004608@toshiba.co.jp> References: <200511150911.jAF9BSWn004608@toshiba.co.jp> Content-Type: text/plain; charset=utf-8 Date: Tue, 15 Nov 2005 10:28:01 +0100 Message-Id: <1132046881.16832.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 El mar, 15-11-2005 a las 18:11 +0900, Fukumoto Atsushi escribi=C3=B3: > I want a confirmation or clarification about CHILD SA handling after > rekeying the parent IKE SA. >=20 > IKEv2 draft-17 section 1.4 states: > Control messages that pertain to an IKE_SA MUST be sent under that > IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent unde= r > the protection of the IKE_SA which generated them (or its successor > if the IKE_SA was replaced for the purpose of rekeying). >=20 > After rekeying IKE SA, there may be redundant IKE SAs, according to > section 2.8. Thus, I suppose, an implementation MUST be able to > accept any one of successors of IKE_SA to be used to control CHILD_SA. Section 2.8 says: << To rekey an IKE_SA, establish a new equivalent IKE_SA (see section 2.18 below) with the peer to whom the old IKE_SA is shared using a CREATE_CHILD_SA within the existing IKE_SA. An IKE_SA so created inherits all of the original IKE_SA's CHILD_SAs. Use the new IKE_SA for all control messages needed to maintain the CHILD_SAs created by the old IKE_SA, and delete the old IKE_SA. The Delete payload to delete itself MUST be the last request sent over an IKE_SA. >> My interpretation is: After rekeying an IKE_SA, the new one is the only one that controls the CHILD_SAs created by the old IKE_SA. The is no CHILD_SA sharing, because they are "transferred" from old to new IKE_SA. > Deleting IKE_SA implicitly closes all associated CHILD_SAs (draft > section 2.4). I suppose it must be only if the children are not > shared with other IKE_SAs. Hence, when the old IKE_SA is deleted, it hasn't any associated CHILD_SA. Alejandro Perez Mendez Pedro J. Fernandez Ruiz >=20 > Am I right with this interpretation? >=20 >=20 > FUKUMOTO Atsushi > atsushi.fukumoto@toshiba.co.jp >=20 > _______________________________________________ > 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 15 04:56:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbxYL-0003FW-Kr; Tue, 15 Nov 2005 04:56:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbxYJ-0003FR-PC for ipsec@megatron.ietf.org; Tue, 15 Nov 2005 04:56:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14477 for ; Tue, 15 Nov 2005 04:56:03 -0500 (EST) Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbxpP-0006hh-CL for ipsec@ietf.org; Tue, 15 Nov 2005 05:14:23 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id jAF9uPbf015218 for ; Tue, 15 Nov 2005 18:56:25 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id jAF9uPKb000976 for ; Tue, 15 Nov 2005 18:56:25 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id UAA00945 ; Tue, 15 Nov 2005 18:56:25 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id jAF9uOIE009688 for ; Tue, 15 Nov 2005 18:56:24 +0900 (JST) Received: by toshiba.co.jp id jAF9uNn3028797; Tue, 15 Nov 2005 18:56:23 +0900 (JST) To: Alejandro Perez Mendez Subject: Re: [Ipsec] IKEv2 CHILD_SA handling after rekeying IKE_SA In-reply-to: alejandro_perez's message of "Tue, 15 Nov 2005 10:28:01 +0100." <1132046881.16832.8.camel@localhost.localdomain> Date: Tue, 15 Nov 2005 18:56:22 +0900 From: Fukumoto Atsushi Message-Id: <200511150956.jAF9uNn3028797@toshiba.co.jp> 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 Alejandro Perez Mendez wrote: > My interpretation is: After rekeying an IKE_SA, the new one is the only > one that controls the CHILD_SAs created by the old IKE_SA. The is no > CHILD_SA sharing, because they are "transferred" from old to new IKE_SA. > Let me clarify my point: you are correct if rekeying does not collide, but draft-17 section 2.8 states: If the two ends have the same lifetime policies, it is possible that both will initiate a rekeying at the same time (which will result in redundant SAs)." and, This form of rekeying may temporarily result in multiple similar SAs between the same pairs of nodes. When there are two SAs eligible to receive packets, a node MUST accept incoming packets through either SA. If redundant SAs are created though such a collision, the SA created with the lowest of the four nonces used in the two exchanges SHOULD be closed by the endpoint that created it. Thus, redundant IKE_SAs are created, and the implementation MUST be able to accept this, if rekeying IKE_SA is supported, if I understand correctly. FUKUMOTO Atsushi atsushi.fukumoto@toshiba.co.jp _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 15 05:12:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbxnN-0007V9-Jl; Tue, 15 Nov 2005 05:12:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbxnK-0007Tv-Mj for ipsec@megatron.ietf.org; Tue, 15 Nov 2005 05:12:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15214 for ; Tue, 15 Nov 2005 05:11:33 -0500 (EST) Received: from smtp.um.es ([155.54.212.105] helo=mail.um.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eby4X-00078l-Qe for ipsec@ietf.org; Tue, 15 Nov 2005 05:29:54 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 4D8911FA31E; Tue, 15 Nov 2005 11:11:57 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 29067-01-95; Tue, 15 Nov 2005 11:11:57 +0100 (CET) Received: from mistral.dif.um.es (mistral.dif.um.es [155.54.1.60]) by mail.um.es (Postfix) with ESMTP id BFC041FA32F; Tue, 15 Nov 2005 11:11:56 +0100 (CET) Received: from pcalex (openikev2.dif.um.es [155.54.210.130]) by mistral.dif.um.es (Postfix) with ESMTP id 664F585C004; Tue, 15 Nov 2005 11:04:31 +0100 (CET) Subject: Re: [Ipsec] IKEv2 CHILD_SA handling after rekeying IKE_SA From: Alejandro Perez Mendez To: Fukumoto Atsushi In-Reply-To: <200511150956.jAF9uN6k004651@toshiba.co.jp> References: <200511150956.jAF9uN6k004651@toshiba.co.jp> Content-Type: text/plain; charset=utf-8 Date: Tue, 15 Nov 2005 11:12:07 +0100 Message-Id: <1132049527.23130.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 El mar, 15-11-2005 a las 18:56 +0900, Fukumoto Atsushi escribi=C3=B3: > Alejandro Perez Mendez wrote: > > My interpretation is: After rekeying an IKE_SA, the new one is the on= ly > > one that controls the CHILD_SAs created by the old IKE_SA. The is no > > CHILD_SA sharing, because they are "transferred" from old to new IKE_= SA. > >=20 >=20 >=20 > Let me clarify my point: you are correct if rekeying does not collide, > but draft-17 section 2.8 states: >=20 > If the two ends have the same lifetime policies, it is possible > that both will initiate a rekeying at the same time (which will > result in redundant SAs)." >=20 > and, >=20 > This form of rekeying may temporarily result in multiple similar SAs > between the same pairs of nodes. When there are two SAs eligible to > receive packets, a node MUST accept incoming packets through either > SA. If redundant SAs are created though such a collision, the SA > created with the lowest of the four nonces used in the two exchanges > SHOULD be closed by the endpoint that created it. >=20 > Thus, redundant IKE_SAs are created, and the implementation MUST be > able to accept this, if rekeying IKE_SA is supported, if I understand > correctly. >=20 >=20 > FUKUMOTO Atsushi > atsushi.fukumoto@toshiba.co.jp umm, you are right. I interpreted this text only for CHILD_SA, but redudandant SAs also includes redundant IKE_SAs. In this case IMHO the CHILD_SAs of the redundant IKE_SA must not be closed, as you said. I hope Tero, Pasi or same IKEv2 guru can clarify this :) --=20 Alejandro Perez Mendez Pedro J. Fernandez Ruiz University of Murcia _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 15 06:18:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbypT-0007PR-Vs; Tue, 15 Nov 2005 06:18:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbypR-0007PI-Jk for ipsec@megatron.ietf.org; Tue, 15 Nov 2005 06:18:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17999 for ; Tue, 15 Nov 2005 06:17:48 -0500 (EST) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebz6c-0000Xj-Dh for ipsec@ietf.org; Tue, 15 Nov 2005 06:36:09 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jAFBHphK025465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Nov 2005 13:17:51 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jAFBHpvk022304; Tue, 15 Nov 2005 13:17:51 +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: <17273.50142.998011.64421@fireball.kivinen.iki.fi> Date: Tue, 15 Nov 2005 13:17:50 +0200 From: Tero Kivinen To: Fukumoto Atsushi Subject: Re: [Ipsec] IKEv2 CHILD_SA handling after rekeying IKE_SA In-Reply-To: <200511150956.jAF9uNn3028797@toshiba.co.jp> References: <1132046881.16832.8.camel@localhost.localdomain> <200511150956.jAF9uNn3028797@toshiba.co.jp> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 4 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Fukumoto Atsushi writes: > This form of rekeying may temporarily result in multiple similar SAs > between the same pairs of nodes. When there are two SAs eligible to > receive packets, a node MUST accept incoming packets through either > SA. If redundant SAs are created though such a collision, the SA > created with the lowest of the four nonces used in the two exchanges > SHOULD be closed by the endpoint that created it. > > Thus, redundant IKE_SAs are created, and the implementation MUST be > able to accept this, if rekeying IKE_SA is supported, if I understand > correctly. That does not say anything about where the child SAs are moved. My interpretation has been that child SAs are always moved to the winning IKE SA, and the loosing IKE SA is closed after small timeout. Also the old IKE SA is closed, so after short time there will be only one IKE SA that has all child SAs. The text do say that "temporarily" so it is not supposed to be situation lasting longer. I would also consider that the loosing IKE SA is not supposed to be used for the traffic, although there are cases where this cannot be avoided. In the end all child SAs should still end up only in the winning IKE SA, thus they are always only part of one IKE SA (no sharing of child SAs between multiple IKE SAs). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 16 00:03:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcFS6-000251-Qw; Wed, 16 Nov 2005 00:03:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcFS5-00024C-10 for ipsec@megatron.ietf.org; Wed, 16 Nov 2005 00:03:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29227 for ; Wed, 16 Nov 2005 00:02:47 -0500 (EST) Received: from imx11.toshiba.co.jp ([61.202.160.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcFjO-0002ps-FY for ipsec@ietf.org; Wed, 16 Nov 2005 00:21:18 -0500 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id jAG532Xa024087 for ; Wed, 16 Nov 2005 14:03:02 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id jAG53I3n005014 for ipsec@ietf.org; Wed, 16 Nov 2005 14:03:18 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id QAA04971; Wed, 16 Nov 2005 14:03:18 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id jAG531Um020330 for ; Wed, 16 Nov 2005 14:03:01 +0900 (JST) Received: by toshiba.co.jp id jAG531nP013746; Wed, 16 Nov 2005 14:03:01 +0900 (JST) To: Tero Kivinen Subject: Re: [Ipsec] IKEv2 CHILD_SA handling after rekeying IKE_SA In-reply-to: kivinen's message of "Tue, 15 Nov 2005 13:17:50 +0200." <17273.50142.998011.64421@fireball.kivinen.iki.fi> Date: Wed, 16 Nov 2005 14:03:00 +0900 From: Fukumoto Atsushi Message-Id: <200511160503.jAG531nP013746@toshiba.co.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Tero Kivinen wrote: > That does not say anything about where the child SAs are moved. My > interpretation has been that child SAs are always moved to the winning > IKE SA, and the loosing IKE SA is closed after small timeout. Also the > old IKE SA is closed, so after short time there will be only one IKE > SA that has all child SAs. I'll be happy to implement along that way, but I think it is hard to deduce that interpretation from the spec, in fact I think it doesn't conform to specification, since it states quite explicitly that "a node MUST accept incoming packets through either SA.". Spec needs amendment for that. FUKUMOTO Atsushi atsushi.fukumoto@toshiba.co.jp _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 16 09:26:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcOFD-0000T2-Rg; Wed, 16 Nov 2005 09:26:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcOFB-0000St-HJ for ipsec@megatron.ietf.org; Wed, 16 Nov 2005 09:26:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29743 for ; Wed, 16 Nov 2005 09:26:04 -0500 (EST) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcOWc-0001kc-6t for ipsec@ietf.org; Wed, 16 Nov 2005 09:44:39 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jAGEQLQG005800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Nov 2005 16:26:21 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jAGEQKlS020630; Wed, 16 Nov 2005 16:26:20 +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: <17275.16780.918843.416197@fireball.kivinen.iki.fi> Date: Wed, 16 Nov 2005 16:26:20 +0200 From: Tero Kivinen To: Fukumoto Atsushi Subject: Re: [Ipsec] IKEv2 CHILD_SA handling after rekeying IKE_SA In-Reply-To: <200511160503.jAG531EE013748@toshiba.co.jp> References: <17273.50142.998011.64421@fireball.kivinen.iki.fi> <200511160503.jAG531EE013748@toshiba.co.jp> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 75 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Fukumoto Atsushi writes: > Tero Kivinen wrote: > > That does not say anything about where the child SAs are moved. My > > interpretation has been that child SAs are always moved to the winning > > IKE SA, and the loosing IKE SA is closed after small timeout. Also the > > old IKE SA is closed, so after short time there will be only one IKE > > SA that has all child SAs. > > > I'll be happy to implement along that way, but I think it is hard to > deduce that interpretation from the spec, in fact I think it doesn't > conform to specification, since it states quite explicitly that "a > node MUST accept incoming packets through either SA.". Spec needs > amendment for that. All of the IPsec SA moved are still accepting incoming packets. The old IKE SA is still accepting incoming packets, but specs say that only packet coming to that is delete payload. The new winning IKE SA is of course accepting incoming packets and continues processing them. The only question is what happens to the loosing IKE SA. If the initator detects before the loosing IKE SA is finished that there is simultaneous IKE rekey he will delete the loosing IKE SA and not use it at all, so there is no problem. The responder will of course accept packets for the loosing IKE SA, but assumes it will be deleted and it can fail all child SA negotiations on the SA. If the initiator gets the IKE SA finished and starts child SA negotiation on that IKE SA and only after that notices that there was actually simulatenous rekey (this can and will happen) it should not be suprised if the create child SA was failed by the responder (responder will know when that child SA creation was starting that there was simultaneous rekey, but it might not yet know which IKE SA is going to be winning one). On the other hand after the child SA is created he is supposed to delete the IKE SA, and my interpretation is that the created child SA is also deleted along the IKE SA, as it was created after rekey took place. So all SAs will still accept incoming packets as long as they are there, but each end can at will anyways delete any SAs, and they are assumed to be deleting the loosing SAs, and after that there is only one SA getting incoming packets. I agree that the document does not explain all possible combinations of what can happen during the simulatenous IKE SA rekey, but the basic rule (i.e. the one IKE SA is the winning and other loosing, and the initiator of the loosing IKE SA will delete the loosing IKE SA, and either end can delete the old IKE SA). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 23 08:51:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eev1s-0000cw-Ir; Wed, 23 Nov 2005 08:51:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eev1q-0000co-8e for ipsec@megatron.ietf.org; Wed, 23 Nov 2005 08:51:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02534 for ; Wed, 23 Nov 2005 08:50:38 -0500 (EST) Received: from ws9.cdotb.ernet.in ([202.41.72.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EevKh-0002Gw-19 for ipsec@ietf.org; Wed, 23 Nov 2005 09:10:48 -0500 Received: from ws9.cdotb.ernet.in (localhost [127.0.0.1]) by localhost.cdotb.ernet.in (Postfix) with ESMTP id 8FA6C4072 for ; Wed, 23 Nov 2005 19:14:28 -0500 (GMT) Received: from universe.cdotb.ernet.in (universe [192.168.42.10]) by ws9.cdotb.ernet.in (Postfix) with ESMTP id 6B20B4074 for ; Wed, 23 Nov 2005 19:14:28 -0500 (GMT) Received: from universe.cdotb.ernet.in (localhost [127.0.0.1]) by universe.cdotb.ernet.in (8.12.2+Sun/8.12.2) with ESMTP id jAO0PZs2028597 for ; Wed, 23 Nov 2005 19:25:35 -0500 (GMT) From: "Nayna Jain" To: ipsec@ietf.org Date: Thu, 24 Nov 2005 05:55:35 +0530 Message-Id: <20051124002510.M28300@universe.cdotb.ernet.in> X-Mailer: Open WebMail 2.41 20040926 X-OriginatingIP: 202.41.75.51 (nayna) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Ipsec] Non-Repudiation in 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 Hi, I have a query whether IPSec provides non-repudiation or not but i couldn't find anywhere in the latest RFCs. Can someone please give me some pointers regarding it. Thanks & Regards, - Nayna -- Open WebMail Project (http://openwebmail.org) _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 23 09:51:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eevy2-0006WO-HO; Wed, 23 Nov 2005 09:51:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eevy0-0006US-Kl for ipsec@megatron.ietf.org; Wed, 23 Nov 2005 09:51:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10820 for ; Wed, 23 Nov 2005 09:50:44 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EewGs-00065r-0w for ipsec@ietf.org; Wed, 23 Nov 2005 10:10:55 -0500 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id jANEp8lM026030; Wed, 23 Nov 2005 06:51:08 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 23 Nov 2005 06:51:08 -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 Subject: RE: [Ipsec] Non-Repudiation in ipsec Date: Wed, 23 Nov 2005 06:51:07 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD377C24EC@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: [Ipsec] Non-Repudiation in ipsec Thread-Index: AcXwNVZ3NUEbXpvQTpG3qNnokUYX1QAB9PlA From: "Hallam-Baker, Phillip" To: "Nayna Jain" , X-OriginalArrivalTime: 23 Nov 2005 14:51:08.0600 (UTC) FILETIME=[5691E380:01C5F03D] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: 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 No it does not. Non repudiation is in any case useless at the packet or transport level. Unless you can archive the message there is no positive value to non-repudiation.=20 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf Of Nayna Jain > Sent: Wednesday, November 23, 2005 7:26 PM > To: ipsec@ietf.org > Subject: [Ipsec] Non-Repudiation in ipsec >=20 >=20 > Hi, > I have a query whether IPSec provides non-repudiation or not=20 > but i couldn't find anywhere in the latest RFCs. > Can someone please give me some pointers regarding it. > Thanks & Regards, > - Nayna > -- > Open WebMail Project (http://openwebmail.org) >=20 >=20 > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec >=20 >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 30 04:10:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhNyz-0004A8-Sw; Wed, 30 Nov 2005 04:10:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhNyy-00048E-LA for ipsec@megatron.ietf.org; Wed, 30 Nov 2005 04:10:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18048 for ; Wed, 30 Nov 2005 04:09:47 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhOJD-0002pg-5I for ipsec@ietf.org; Wed, 30 Nov 2005 04:31:28 -0500 Received: by wproxy.gmail.com with SMTP id 69so50198wri for ; Wed, 30 Nov 2005 01:10:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=LBVhVGIZEMYxyhLCfaeBLnPedQK3MIi/uzWmeqZU001kV/c6c/nGLFuWsqG1uMnxCxTUN9hl9qpnevHYIquTneR6A4kmd0PHrHkiXof//xiTSlgqJIee8LLxPn8OTAiy9uwocJkzsDVdlIwKRFVdQVRqobEAgOVu612mcXJYR6U= Received: by 10.65.11.13 with SMTP id o13mr4427104qbi; Wed, 30 Nov 2005 01:10:28 -0800 (PST) Received: by 10.64.204.7 with HTTP; Wed, 30 Nov 2005 01:10:28 -0800 (PST) Message-ID: Date: Wed, 30 Nov 2005 14:40:28 +0530 From: Dhiraj Gaurh To: ipsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ipsec] multicasting support with 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: , Content-Type: multipart/mixed; boundary="===============1337422298==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1337422298== Content-Type: multipart/alternative; boundary="----=_Part_9493_7665779.1133341828874" ------=_Part_9493_7665779.1133341828874 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, Has multicasting support for IPsec been finalized ? regards Dhiraj ------=_Part_9493_7665779.1133341828874 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello,
  Has multicasting support for IPsec been finalized ?
regards
Dhiraj
------=_Part_9493_7665779.1133341828874-- --===============1337422298== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1337422298==-- From ipsec-bounces@ietf.org Wed Nov 30 08:14:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhRnE-0002Qh-1z; Wed, 30 Nov 2005 08:14:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhRnC-0002QX-D1 for ipsec@megatron.ietf.org; Wed, 30 Nov 2005 08:14:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12878 for ; Wed, 30 Nov 2005 08:13:51 -0500 (EST) From: Atul.Sharma@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhS7Q-0002Ak-Fq for ipsec@ietf.org; Wed, 30 Nov 2005 08:35:36 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAUDAge5013408; Wed, 30 Nov 2005 15:11:11 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Nov 2005 15:05:52 +0200 Received: from bsebe101.NOE.Nokia.com ([172.19.160.235]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Nov 2005 07:05:50 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 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] multicasting support with IPsec Date: Wed, 30 Nov 2005 08:05:49 -0500 Message-ID: Thread-Topic: [Ipsec] multicasting support with IPsec Thread-Index: AcX1q7kdRmqJwcuwSaKiH/jZH+OwPAAAsN2w To: , X-OriginalArrivalTime: 30 Nov 2005 13:05:50.0625 (UTC) FILETIME=[C9A7A910:01C5F5AE] X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: 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 Dhiraj, =20 You should follow MSEC group which is working on Multicast extentensions = to IPsec: draft-ietf-msec-ipsec-multicast-extensions-00.txt =20 Atul -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]On Behalf Of = ext Dhiraj Gaurh Sent: Wednesday, November 30, 2005 4:10 AM To: ipsec@ietf.org Subject: [Ipsec] multicasting support with IPsec Hello, Has multicasting support for IPsec been finalized ? regards Dhiraj _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 30 15:43:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYnV-0006nQ-VD; Wed, 30 Nov 2005 15:43:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYnU-0006nF-UK for ipsec@megatron.ietf.org; Wed, 30 Nov 2005 15:43:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10520 for ; Wed, 30 Nov 2005 15:42:39 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhZ7p-0002Pl-HU for ipsec@ietf.org; Wed, 30 Nov 2005 16:04:26 -0500 Received: from [10.20.30.249] (dsl2-63-249-109-231.cruzio.com [63.249.109.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUKhGKB047931 for ; Wed, 30 Nov 2005 12:43:17 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 30 Nov 2005 12:43:23 -0800 To: IPsec WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ipsec] New draft on hash use in IKE and 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 Greetings again. A number of my members have asked how the IPsec industry is affected by the the recent attacks which have reduced the collision resistance of MD5 and SHA-1. I have published an Internet Draft that discusses how IKE and IPsec use hash functions; it is now available at . It is expected to eventually become an Informational RFC. The draft covers the many ways in which hash functions are used, and say whether or not there are vulnerabilities. It is important that we lay out all the areas in which hashes are used, and how they are used, so that an outside observer can see whether or not IKE and IPsec need to be changed, particularly if the collision-resistance attacks get better (as we should expect). I would greatly appreciate careful review of my assumptions both of where we use hash functions in our protocols and how they are used. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec