From nicolas.michel@lemail.be Thu Sep 8 02:28:00 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2C021F8B13 for ; Thu, 8 Sep 2011 02:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.105 X-Spam-Level: ** X-Spam-Status: No, score=2.105 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTxovtzqpI9s for ; Thu, 8 Sep 2011 02:28:00 -0700 (PDT) Received: from ulysse.talessa.com (unknown [85.234.192.2]) by ietfa.amsl.com (Postfix) with ESMTP id C358C21F8B08 for ; Thu, 8 Sep 2011 02:27:59 -0700 (PDT) Received: from [91.179.52.54] (helo=[172.22.0.177]) by ulysse.talessa.com with esmtpa (Exim 4.63) (envelope-from ) id 1R1ave-0002Ev-AF for ipsec@ietf.org; Thu, 08 Sep 2011 11:29:50 +0200 Message-ID: <4E688B0D.60900@lemail.be> Date: Thu, 08 Sep 2011 11:29:49 +0200 From: Nicolas Michel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Can't establish a gateway to gateway X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 09:32:20 -0000 Helo, I'm searching for two days now to establish an IPSEC TUNNEL between two hosts. The tunnel is established but I can't ping through the tunnel. I don't really understand what's wrong. If someone could help me it would be really nice ;) Here are all of the information : Schema ------- [DUMMY] (81.246.56.70) x | x (81.246.56.69) [###IPSEC1###] (172.22.150.1) x | x (172.22.254.254) [MAIN GATEWAY] (192.168.63.254) x | x (192.168.63.100) [###IPSEC2###] (192.168.80.1) The tunnel is established but I can't ping from dummy to ipsec2 (192.168.80.1) SERVER1 : ipsec1 ---------------- eth0 : 172.22.150.1 eth1 : 81.246.56.69 SERVER2 : ipsec2 ---------------- eth0 : 192.168.63.100 eth1 : 192.168.80.1 SERVER3 : dummy --------------- eth0 : 81.246.56.70 default gateway : ipsec1 (81.246.56.69) ipsec-tools.conf on SERVER1 --------------------------- #!/usr/sbin/setkey -f flush; spdflush; spdadd 81.246.56.64/27 192.168.80.0/24 any -P out ipsec esp/tunnel/172.22.150.1-192.168.63.100/require; spdadd 192.168.80.0/24 81.246.56.64/27 any -P in ipsec esp/tunnel/192.168.63.100-172.22.150.1/require; racoon.conf on SERVER1 ---------------------- path pre_shared_key "/etc/racoon/psk.txt"; remote 192.168.63.100 { exchange_mode main,aggressive; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2; } } sainfo address 81.246.56.64/27 any address 192.168.80.0/24 any { pfs_group 2; lifetime time 1 hour ; encryption_algorithm 3des, blowfish 448, rijndael ; authentication_algorithm hmac_sha1, hmac_md5 ; compression_algorithm deflate ; } routes on SERVER1 ----------------- $ ip route 81.246.56.64/27 dev eth1 proto kernel scope link src 81.246.56.69 192.168.80.0/24 via 172.22.150.1 dev eth0 src 172.22.150.1 172.22.0.0/16 dev eth0 proto kernel scope link src 172.22.150.1 default via 172.22.254.254 dev eth0 ipsec-tools.conf on SERVER2 --------------------------- #!/usr/sbin/setkey -f flush; spdflush; spdadd 192.168.80.0/24 81.246.56.64/27 any -P out ipsec esp/tunnel/192.168.63.100-172.22.150.1/require; spdadd 81.246.56.64/27 192.168.80.0/24 any -P in ipsec esp/tunnel/172.22.150.1-192.168.63.100/require; racoon.conf on SERVER2 ---------------------- path pre_shared_key "/etc/racoon/psk.txt"; remote 172.22.150.1 { exchange_mode main,aggressive; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2; } } sainfo address 192.168.80.0/24 any address 81.246.56.64/27 any { pfs_group 2; lifetime time 1 hour ; encryption_algorithm 3des, blowfish 448, rijndael ; authentication_algorithm hmac_sha1, hmac_md5 ; compression_algorithm deflate ; } routes on SERVER2 ----------------- ip route 81.246.56.64/27 via 192.168.63.100 dev eth0 src 192.168.63.100 192.168.80.0/24 dev eth1 proto kernel scope link src 192.168.80.1 192.168.63.0/24 dev eth0 proto kernel scope link src 192.168.63.100 default via 192.168.63.254 dev eth0 log on SERVER1 -------------- 2011-09-08 10:51:35: DEBUG: get pfkey UPDATE message 2011-09-08 10:51:35: DEBUG: pfkey UPDATE succeeded: ESP/Tunnel 192.168.63.100[0]->172.22.150.1[0] spi=132545011(0x7e679f3) 2011-09-08 10:51:35: INFO: IPsec-SA established: ESP/Tunnel 192.168.63.100[0]->172.22.150.1[0] spi=132545011(0x7e679f3) 2011-09-08 10:51:35: DEBUG: === 2011-09-08 10:51:35: DEBUG: pk_recv: retry[0] recv() 2011-09-08 10:51:35: DEBUG: get pfkey ADD message 2011-09-08 10:51:35: INFO: IPsec-SA established: ESP/Tunnel 172.22.150.1[500]->192.168.63.100[500] spi=168459473(0xa0a7cd1) 2011-09-08 10:51:35: DEBUG: === log on SERVER2 -------------- 2011-09-08 10:51:34: DEBUG: pfkey UPDATE succeeded: ESP/Tunnel 172.22.150.1[0]->192.168.63.100[0] spi=168459473(0xa0a7cd1) 2011-09-08 10:51:34: INFO: IPsec-SA established: ESP/Tunnel 172.22.150.1[0]->192.168.63.100[0] spi=168459473(0xa0a7cd1) 2011-09-08 10:51:34: DEBUG: === 2011-09-08 10:51:34: DEBUG: pk_recv: retry[0] recv() 2011-09-08 10:51:34: DEBUG: get pfkey ADD message 2011-09-08 10:51:34: INFO: IPsec-SA established: ESP/Tunnel 192.168.63.100[500]->172.22.150.1[500] spi=132545011(0x7e679f3) 2011-09-08 10:51:34: DEBUG: === From nicolas.michel@lemail.be Thu Sep 8 03:04:55 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CA821F8A6F for ; Thu, 8 Sep 2011 03:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.155 X-Spam-Level: X-Spam-Status: No, score=0.155 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wkxz1GBdlHsr for ; Thu, 8 Sep 2011 03:04:54 -0700 (PDT) Received: from ulysse.talessa.com (unknown [85.234.192.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5B34821F8AE9 for ; Thu, 8 Sep 2011 03:04:54 -0700 (PDT) Received: from [91.179.52.54] (helo=[172.22.0.177]) by ulysse.talessa.com with esmtpa (Exim 4.63) (envelope-from ) id 1R1bVL-0002hv-Bb for ipsec@ietf.org; Thu, 08 Sep 2011 12:06:43 +0200 Message-ID: <4E6893AE.70301@lemail.be> Date: Thu, 08 Sep 2011 12:06:38 +0200 From: Nicolas Michel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: ipsec@ietf.org References: <4E688B0D.60900@lemail.be> In-Reply-To: <4E688B0D.60900@lemail.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] Can't establish a gateway to gateway X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 10:04:55 -0000 I'm sorry to post it because some minutes after it was working well ;) Forgot to apply changes made to ipsec-tools.conf on SERVER2 On 09/08/2011 11:29 AM, Nicolas Michel wrote: > Helo, > > I'm searching for two days now to establish an IPSEC TUNNEL between two > hosts. The tunnel is established but I can't ping through the tunnel. I > don't really understand what's wrong. > > If someone could help me it would be really nice ;) > > Here are all of the information : > > Schema > ------- > > [DUMMY] > (81.246.56.70) > x > | > x > (81.246.56.69) > [###IPSEC1###] > (172.22.150.1) > x > | > x > (172.22.254.254) > [MAIN GATEWAY] > (192.168.63.254) > x > | > x > (192.168.63.100) > [###IPSEC2###] > (192.168.80.1) > > The tunnel is established but I can't ping from dummy to ipsec2 > (192.168.80.1) > > > SERVER1 : ipsec1 > ---------------- > eth0 : 172.22.150.1 > eth1 : 81.246.56.69 > > SERVER2 : ipsec2 > ---------------- > eth0 : 192.168.63.100 > eth1 : 192.168.80.1 > > SERVER3 : dummy > --------------- > eth0 : 81.246.56.70 > default gateway : ipsec1 (81.246.56.69) > > > ipsec-tools.conf on SERVER1 > --------------------------- > > #!/usr/sbin/setkey -f > > flush; > spdflush; > > spdadd 81.246.56.64/27 192.168.80.0/24 any -P out ipsec > esp/tunnel/172.22.150.1-192.168.63.100/require; > > spdadd 192.168.80.0/24 81.246.56.64/27 any -P in ipsec > esp/tunnel/192.168.63.100-172.22.150.1/require; > > > racoon.conf on SERVER1 > ---------------------- > > path pre_shared_key "/etc/racoon/psk.txt"; > > remote 192.168.63.100 { > exchange_mode main,aggressive; > proposal { > encryption_algorithm 3des; > hash_algorithm sha1; > authentication_method pre_shared_key; > dh_group 2; > } > } > > sainfo address 81.246.56.64/27 any address 192.168.80.0/24 any { > pfs_group 2; > lifetime time 1 hour ; > encryption_algorithm 3des, blowfish 448, rijndael ; > authentication_algorithm hmac_sha1, hmac_md5 ; > compression_algorithm deflate ; > } > > routes on SERVER1 > ----------------- > $ ip route > 81.246.56.64/27 dev eth1 proto kernel scope link src 81.246.56.69 > 192.168.80.0/24 via 172.22.150.1 dev eth0 src 172.22.150.1 > 172.22.0.0/16 dev eth0 proto kernel scope link src 172.22.150.1 > default via 172.22.254.254 dev eth0 > > > ipsec-tools.conf on SERVER2 > --------------------------- > > #!/usr/sbin/setkey -f > > flush; > spdflush; > > spdadd 192.168.80.0/24 81.246.56.64/27 any -P out ipsec > esp/tunnel/192.168.63.100-172.22.150.1/require; > > spdadd 81.246.56.64/27 192.168.80.0/24 any -P in ipsec > esp/tunnel/172.22.150.1-192.168.63.100/require; > > > racoon.conf on SERVER2 > ---------------------- > > path pre_shared_key "/etc/racoon/psk.txt"; > > remote 172.22.150.1 { > exchange_mode main,aggressive; > proposal { > encryption_algorithm 3des; > hash_algorithm sha1; > authentication_method pre_shared_key; > dh_group 2; > } > } > > sainfo address 192.168.80.0/24 any address 81.246.56.64/27 any { > pfs_group 2; > lifetime time 1 hour ; > encryption_algorithm 3des, blowfish 448, rijndael ; > authentication_algorithm hmac_sha1, hmac_md5 ; > compression_algorithm deflate ; > } > > routes on SERVER2 > ----------------- > ip route > 81.246.56.64/27 via 192.168.63.100 dev eth0 src 192.168.63.100 > 192.168.80.0/24 dev eth1 proto kernel scope link src 192.168.80.1 > 192.168.63.0/24 dev eth0 proto kernel scope link src 192.168.63.100 > default via 192.168.63.254 dev eth0 > > log on SERVER1 > -------------- > 2011-09-08 10:51:35: DEBUG: get pfkey UPDATE message > 2011-09-08 10:51:35: DEBUG: pfkey UPDATE succeeded: ESP/Tunnel > 192.168.63.100[0]->172.22.150.1[0] spi=132545011(0x7e679f3) > 2011-09-08 10:51:35: INFO: IPsec-SA established: ESP/Tunnel > 192.168.63.100[0]->172.22.150.1[0] spi=132545011(0x7e679f3) > 2011-09-08 10:51:35: DEBUG: === > 2011-09-08 10:51:35: DEBUG: pk_recv: retry[0] recv() > 2011-09-08 10:51:35: DEBUG: get pfkey ADD message > 2011-09-08 10:51:35: INFO: IPsec-SA established: ESP/Tunnel > 172.22.150.1[500]->192.168.63.100[500] spi=168459473(0xa0a7cd1) > 2011-09-08 10:51:35: DEBUG: === > > log on SERVER2 > -------------- > 2011-09-08 10:51:34: DEBUG: pfkey UPDATE succeeded: ESP/Tunnel > 172.22.150.1[0]->192.168.63.100[0] spi=168459473(0xa0a7cd1) > 2011-09-08 10:51:34: INFO: IPsec-SA established: ESP/Tunnel > 172.22.150.1[0]->192.168.63.100[0] spi=168459473(0xa0a7cd1) > 2011-09-08 10:51:34: DEBUG: === > 2011-09-08 10:51:34: DEBUG: pk_recv: retry[0] recv() > 2011-09-08 10:51:34: DEBUG: get pfkey ADD message > 2011-09-08 10:51:34: INFO: IPsec-SA established: ESP/Tunnel > 192.168.63.100[500]->172.22.150.1[500] spi=132545011(0x7e679f3) > 2011-09-08 10:51:34: DEBUG: === > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From woohwankim@gmail.com Thu Sep 15 01:22:15 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38D521F84FA for ; Thu, 15 Sep 2011 01:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CH31q-RLzIpX for ; Thu, 15 Sep 2011 01:22:14 -0700 (PDT) Received: from mail-vw0-f50.google.com (mail-vw0-f50.google.com [209.85.212.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE1021F84ED for ; Thu, 15 Sep 2011 01:22:14 -0700 (PDT) Received: by vws14 with SMTP id 14so3837472vws.37 for ; Thu, 15 Sep 2011 01:24:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=K+TgdJ0f7+RXQ/bWaUK0tqVeXrH5Rq5p6AA5D4yT3hc=; b=i9cn31zYlZzFhq4hzsaVeBAiWiXqN7M0Z3vdjoe07DWLj0LTNHeEJyUF5SdSA25fbJ BqX255lStyX7TZMiFBMb5j+BEmXG0iT51MAsezFOVMHJBb8pYFfs3V4rnIQKP0WZvBv5 eqi924JEriLqphKJmNbbdgqFyx64w/TiVeKDE= MIME-Version: 1.0 Received: by 10.52.34.50 with SMTP id w18mr661109vdi.505.1316075064066; Thu, 15 Sep 2011 01:24:24 -0700 (PDT) Sender: woohwankim@gmail.com Received: by 10.220.187.76 with HTTP; Thu, 15 Sep 2011 01:24:23 -0700 (PDT) Date: Thu, 15 Sep 2011 17:24:23 +0900 X-Google-Sender-Auth: z-Oa8-Tw_SWYDMSzo3xqKlsI0Oo Message-ID: From: Woo-Hwan Kim To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=20cf30780c12b1010d04acf69a2b Cc: Daesung Kwon , Jungkeon Lee , Je Hong Park Subject: [IPsec] Request for review: The ARIA Cipher Algorithm and Its Use with IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 08:24:39 -0000 --20cf30780c12b1010d04acf69a2b Content-Type: text/plain; charset=ISO-8859-1 IPsec experts, Let me make a request for review on the draft "The ARIA Cipher Algorithm and Its Use with IPsec". Any comments would be appreciated. http://tools.ietf.org/html/draft-nsri-ipsecme-aria-ipsec-00 ---------- Forwarded message ---------- From: Date: 2011/9/15 Subject: New Version Notification for draft-nsri-ipsecme-aria-ipsec-00.txt To: whkim5@ensec.re.kr Cc: ds_kwon@ensec.re.kr, whkim5@ensec.re.kr, jhpark@ensec.re.kr, jklee@ensec.re.kr A new version of I-D, draft-nsri-ipsecme-aria-ipsec-00.txt has been successfully submitted by Woo-Hwan Kim and posted to the IETF repository. Filename: draft-nsri-ipsecme-aria-ipsec Revision: 00 Title: The ARIA Cipher Algorithm and Its Use with IPsec Creation date: 2011-09-15 WG ID: Individual Submission Number of pages: 10 Abstract: This document describes the use of the ARIA block cipher algorithm in conjunction with several different modes of operation within IKE and IPsec. It describes the use of ARIA in CBC, CTR, GCM and CCM modes to encrypt and/or authenticate IKE and ESP traffic. It also describes the use of ARIA in XCBC, CMAC, and GMAC modes to authenticate IKE, ESP and AH traffic. The use of ARIA in XCBC and CMAC modes for pseudorandom functions is also included. The IETF Secretariat --20cf30780c12b1010d04acf69a2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable IPsec experts,

Let me make a request for review=A0<= /div>
on the draft "The ARIA Cipher Algorithm and Its Use with IPs= ec".

Any comments would be appreciated.


---------- Forwarded message= ----------
From: <internet-drafts@ietf.org>
= Date: 2011/9/15
Subject: New Version Notification for draft-nsri-ipsecme= -aria-ipsec-00.txt
To: whkim5@ensec.re.kr
Cc: ds_kwon@ensec.re.kr, whkim5@ensec.re.kr, jhpark@ensec.re.kr, jkl= ee@ensec.re.kr


A new version of I-D, draft-nsri-ipsecme-aria-ipsec-00.txt has been= successfully submitted by Woo-Hwan Kim and posted to the IETF repository.<= br>
Filename: =A0 =A0 =A0 =A0draft-nsri-ipsecme-aria-ipsec
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 The ARIA Cipher Algorithm and Its Use with IPsec=
Creation date: =A0 2011-09-15
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 10

Abstract:
=A0 This document describes the use of the ARIA block cipher algorithm in<= br> =A0 conjunction with several different modes of operation within IKE and =A0 IPsec. =A0It describes the use of ARIA in CBC, CTR, GCM and CCM modes<= br> =A0 to encrypt and/or authenticate IKE and ESP traffic. =A0It also
=A0 describes the use of ARIA in XCBC, CMAC, and GMAC modes to
=A0 authenticate IKE, ESP and AH traffic. =A0The use of ARIA in XCBC and =A0 CMAC modes for pseudorandom functions is also included.




The IETF Secretariat

--20cf30780c12b1010d04acf69a2b-- From Paul_Koning@Dell.com Thu Sep 15 03:50:35 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7831721F86EE for ; Thu, 15 Sep 2011 03:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ro-7405NynMH for ; Thu, 15 Sep 2011 03:50:33 -0700 (PDT) Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) by ietfa.amsl.com (Postfix) with ESMTP id 44CF421F84E1 for ; Thu, 15 Sep 2011 03:50:31 -0700 (PDT) X-Loopcount0: from 10.175.216.250 From: To: , Date: Thu, 15 Sep 2011 05:52:32 -0500 Thread-Topic: [IPsec] Request for review: The ARIA Cipher Algorithm and Its Use with IPsec Thread-Index: AcxzgTsr2MLIMph8RXaI/s5sD26sEAAFCrSQ Message-ID: <09787EF419216C41A903FD14EE5506DD0307EF973F@AUSX7MCPC103.AMER.DELL.COM> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_09787EF419216C41A903FD14EE5506DD0307EF973FAUSX7MCPC103A_" MIME-Version: 1.0 Cc: ds_kwon@ensec.re.kr, jhpark@ensec.re.kr, jklee@ensec.re.kr Subject: Re: [IPsec] Request for review: The ARIA Cipher Algorithm and Its Use with IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 10:50:35 -0000 --_000_09787EF419216C41A903FD14EE5506DD0307EF973FAUSX7MCPC103A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Should this be added to IPSec? It's not clear to me that proliferation of = ciphers is helpful. A small set of very well vetted ciphers is better than= a larger set that add others without a strong track record. paul From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of W= oo-Hwan Kim Sent: Thursday, September 15, 2011 4:24 AM To: ipsec@ietf.org Cc: Daesung Kwon; Jungkeon Lee; Je Hong Park Subject: [IPsec] Request for review: The ARIA Cipher Algorithm and Its Use = with IPsec IPsec experts, Let me make a request for review on the draft "The ARIA Cipher Algorithm and Its Use with IPsec". Any comments would be appreciated. http://tools.ietf.org/html/draft-nsri-ipsecme-aria-ipsec-00 ---------- Forwarded message ---------- From: > Date: 2011/9/15 Subject: New Version Notification for draft-nsri-ipsecme-aria-ipsec-00.txt To: whkim5@ensec.re.kr Cc: ds_kwon@ensec.re.kr, whkim5@ensec.re.kr, jhpark@ensec.re.kr, jkl= ee@ensec.re.kr A new version of I-D, draft-nsri-ipsecme-aria-ipsec-00.txt has been success= fully submitted by Woo-Hwan Kim and posted to the IETF repository. Filename: draft-nsri-ipsecme-aria-ipsec Revision: 00 Title: The ARIA Cipher Algorithm and Its Use with IPsec Creation date: 2011-09-15 WG ID: Individual Submission Number of pages: 10 Abstract: This document describes the use of the ARIA block cipher algorithm in conjunction with several different modes of operation within IKE and IPsec. It describes the use of ARIA in CBC, CTR, GCM and CCM modes to encrypt and/or authenticate IKE and ESP traffic. It also describes the use of ARIA in XCBC, CMAC, and GMAC modes to authenticate IKE, ESP and AH traffic. The use of ARIA in XCBC and CMAC modes for pseudorandom functions is also included. The IETF Secretariat --_000_09787EF419216C41A903FD14EE5506DD0307EF973FAUSX7MCPC103A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Should th= is be added to IPSec?  It’s not clear to me that proliferation o= f ciphers is helpful.  A small set of very well vetted ciphers is bett= er than a larger set that add others without a strong track record.

 

        &nbs= p;       paul

 

From: ip= sec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Wo= o-Hwan Kim
Sent: Thursday, September 15, 2011 4:24 AM
To: ipsec@ietf.org
Cc: Daesung Kwon; Jungkeon Lee; Je Hong ParkSubject: [IPsec] Request for review: The ARIA Cipher Algorithm and = Its Use with IPsec

 

IPsec experts,

 

Let me ma= ke a request for review 

on the draft "The ARIA Cipher Algorithm and Its Use with IPsec".=

 

<= div>

Any comments would be appreciated.

<= /div>

 

 

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Da= te: 2011/9/15
Subject: New Version Notification for draft-nsri-ipsecme-a= ria-ipsec-00.txt
To: whkim5@ensec.= re.kr
Cc: ds_kwon@ensec.re.kr= , whkim5@ensec.re.kr, jhpark@ensec.re.kr, jklee@ensec.re.kr


A new version of I-D, dra= ft-nsri-ipsecme-aria-ipsec-00.txt has been successfully submitted by Woo-Hw= an Kim and posted to the IETF repository.

Filename:     &n= bsp;  draft-nsri-ipsecme-aria-ipsec
Revision:       =  00
Title:           The ARIA Cipher Algor= ithm and Its Use with IPsec
Creation date:   2011-09-15
WG ID: &= nbsp;         Individual Submission
Number of pages:= 10

Abstract:
  This document describes the use of the ARIA = block cipher algorithm in
  conjunction with several different mode= s of operation within IKE and
  IPsec.  It describes the use o= f ARIA in CBC, CTR, GCM and CCM modes
  to encrypt and/or authentic= ate IKE and ESP traffic.  It also
  describes the use of ARIA = in XCBC, CMAC, and GMAC modes to
  authenticate IKE, ESP and AH tra= ffic.  The use of ARIA in XCBC and
  CMAC modes for pseudorand= om functions is also included.




The IETF Secretariat=

 

= --_000_09787EF419216C41A903FD14EE5506DD0307EF973FAUSX7MCPC103A_-- From paul.hoffman@vpnc.org Thu Sep 15 08:14:10 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD60A21F88A0 for ; Thu, 15 Sep 2011 08:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vZYKyiaw6+n for ; Thu, 15 Sep 2011 08:14:10 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFB721F87D3 for ; Thu, 15 Sep 2011 08:14:10 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p8FFGLww046347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 15 Sep 2011 08:16:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1244.3) From: Paul Hoffman In-Reply-To: <09787EF419216C41A903FD14EE5506DD0307EF973F@AUSX7MCPC103.AMER.DELL.COM> Date: Thu, 15 Sep 2011 08:16:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <60C9D66F-DF2C-4E07-BBFE-A3B8FDAA38E8@vpnc.org> References: <09787EF419216C41A903FD14EE5506DD0307EF973F@AUSX7MCPC103.AMER.DELL.COM> To: IPsecme WG X-Mailer: Apple Mail (2.1244.3) Subject: Re: [IPsec] Request for review: The ARIA Cipher Algorithm and Its Use with IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 15:14:10 -0000 On Sep 15, 2011, at 3:52 AM, = wrote: > Should this be added to IPSec? It=92s not clear to me that = proliferation of ciphers is helpful. A small set of very well vetted = ciphers is better than a larger set that add others without a strong = track record. IPsec (and IKE) allow the addition of new ciphers without those ciphers = being considered "part of" IPsec. That is, no one should feel compelled = to implement every cipher for which there is an RFC and a number in the = registry. This document is currently not being considered as a WG item. The = authors have, correctly, proposed it as an informational submission. --Paul Hoffman From Paul_Koning@Dell.com Thu Sep 15 08:26:47 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685EF21F87FC for ; Thu, 15 Sep 2011 08:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bp3RRm3xkKn for ; Thu, 15 Sep 2011 08:26:46 -0700 (PDT) Received: from ausxipps301.us.dell.com (ausxipps301.us.dell.com [143.166.148.223]) by ietfa.amsl.com (Postfix) with ESMTP id BBF4821F87C9 for ; Thu, 15 Sep 2011 08:26:46 -0700 (PDT) X-Loopcount0: from 10.170.28.41 From: To: , Date: Thu, 15 Sep 2011 10:28:56 -0500 Thread-Topic: [IPsec] Request for review: The ARIA Cipher Algorithm and Its Use with IPsec Thread-Index: AcxzunCdL4Jz/yLrQ3KA2KT9wnfu2AAAbnFw Message-ID: <09787EF419216C41A903FD14EE5506DD0307F9CBCC@AUSX7MCPC103.AMER.DELL.COM> References: <09787EF419216C41A903FD14EE5506DD0307EF973F@AUSX7MCPC103.AMER.DELL.COM> <60C9D66F-DF2C-4E07-BBFE-A3B8FDAA38E8@vpnc.org> In-Reply-To: <60C9D66F-DF2C-4E07-BBFE-A3B8FDAA38E8@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] Request for review: The ARIA Cipher Algorithm and Its Use with IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 15:26:47 -0000 Ok, thanks, that makes sense. paul -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of P= aul Hoffman Sent: Thursday, September 15, 2011 11:16 AM To: IPsecme WG Subject: Re: [IPsec] Request for review: The ARIA Cipher Algorithm and Its = Use with IPsec On Sep 15, 2011, at 3:52 AM, = wrote: > Should this be added to IPSec? It's not clear to me that proliferation o= f ciphers is helpful. A small set of very well vetted ciphers is better th= an a larger set that add others without a strong track record. IPsec (and IKE) allow the addition of new ciphers without those ciphers bei= ng considered "part of" IPsec. That is, no one should feel compelled to imp= lement every cipher for which there is an RFC and a number in the registry. This document is currently not being considered as a WG item. The authors h= ave, correctly, proposed it as an informational submission. --Paul Hoffman _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From jobyts@yahoo.com Thu Sep 15 15:39:27 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2341C21F869E for ; Thu, 15 Sep 2011 15:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.36 X-Spam-Level: *** X-Spam-Status: No, score=3.36 tagged_above=-999 required=5 tests=[AWL=2.360, BAYES_60=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgnxY0e8kyJO for ; Thu, 15 Sep 2011 15:39:26 -0700 (PDT) Received: from nm28.bullet.mail.ac4.yahoo.com (nm28.bullet.mail.ac4.yahoo.com [98.139.52.225]) by ietfa.amsl.com (Postfix) with SMTP id 91FEA21F8678 for ; Thu, 15 Sep 2011 15:39:26 -0700 (PDT) Received: from [98.139.52.189] by nm28.bullet.mail.ac4.yahoo.com with NNFMP; 15 Sep 2011 22:41:36 -0000 Received: from [98.139.52.179] by tm2.bullet.mail.ac4.yahoo.com with NNFMP; 15 Sep 2011 22:41:36 -0000 Received: from [127.0.0.1] by omp1062.mail.ac4.yahoo.com with NNFMP; 15 Sep 2011 22:41:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 774790.17668.bm@omp1062.mail.ac4.yahoo.com Received: (qmail 16744 invoked by uid 60001); 15 Sep 2011 22:41:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1316126496; bh=JPAh5iH89HK+UY6wuqs5xC13PPArH2veemPklgNKdoQ=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=kVfqYoNDSI04nY/djR7C4OKVqx3cwqiu3S+VIYIx6yhZt932FMaewDGfYb0WlasuaDhNl3XStdc5QWnLW9s63qpile5M3zzUFyjkNjs6L7aV65vHYZNFrTkk5m3e2VUWGx0gqizylr0OI2+HObQfNkrF7HPaIcrs/Qvfg8yv7zM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=ejkoCVeZs7pBZpQbtxKxFlQ7ouqw/o4eKJaaIy37RPIvKgFJHaiPCsLdXQ8zHOn7pNVFYlDeLAjEWC0o1Dyx70+Q2heuZsgSQwvsPMzW/B2NlIn0NrXFpCarDyzQ9ZyfLV0GYSOGJN0bY5by+cIKF/4B6Tl38hbE8h/Hxxq1ztQ=; X-YMail-OSG: iVOI0BMVM1k2U.BmIv1qj2uFgJAxrdAtK5VfPfpAmsRVHcU PfTB_NFu124ihHb_Qpo5nW6Na4D4t.TAJhBer5ihFKsPdHvkJEyPpFtBslmO fTBCU_X0ptNdYqqVLH1q5FW3PcJDmmWWPFWFMkH0EBbIOavK59tc.cLJ7EJK b_69QjST0YYMtL6y6_PJMNx8pXdu32P7uptSWCXUDSHZVcIrDRFdf_OorOVU 1BKt6pVTCbp_upkrUkqK99zXgG1J0CkVSJLvHFJ_I7i8hXsJowES3qpfRBn4 no_Qla8D3l.PqedH0nA7jrbEDXd_4oxGNtX1EsjDeuqrpAwVl2ijAe_cbwY5 Ja1zOkvPGgIxvafz8oV1hNBuZqvja1O4wpUdfK2iJpF8EGY.1s6oS.nvxFHc wkU7w1BGV5FMw5xGVcyBYx.NWZQf8DKMIqGDVNazg Received: from [66.129.224.36] by web36406.mail.mud.yahoo.com via HTTP; Thu, 15 Sep 2011 15:41:36 PDT X-Mailer: YahooMailClassic/14.0.5 YahooMailWebService/0.8.113.315625 Message-ID: <1316126496.5636.YahooMailClassic@web36406.mail.mud.yahoo.com> Date: Thu, 15 Sep 2011 15:41:36 -0700 (PDT) From: Joby Sebastian To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Sat, 17 Sep 2011 08:01:21 -0700 Subject: [IPsec] Replay window size X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 18:02:28 -0000 Hi, If my ESP replay window implementation supports a largest replay window size (say 4096), and there is no significant performance drop in managing a bigger window size, is it is always better to use the biggest window size? Is there a case where using a smaller window size is more desirable? Does a bigger window size introduce a security hole and more prone to an attack? Thanks, Joby From cuiyang@huawei.com Sun Sep 18 18:41:15 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9C221F8B71; Sun, 18 Sep 2011 18:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.251 X-Spam-Level: X-Spam-Status: No, score=-5.251 tagged_above=-999 required=5 tests=[AWL=1.348, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dAdJEfIaPt8; Sun, 18 Sep 2011 18:41:14 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 55BCC21F8B6D; Sun, 18 Sep 2011 18:41:14 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRQ006UTY1ZN5@szxga05-in.huawei.com>; Mon, 19 Sep 2011 09:41:59 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRQ005EOY1Y71@szxga05-in.huawei.com>; Mon, 19 Sep 2011 09:41:58 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADT38429; Mon, 19 Sep 2011 09:41:58 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 19 Sep 2011 09:41:56 +0800 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.65]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0270.001; Mon, 19 Sep 2011 09:41:52 +0800 Date: Mon, 19 Sep 2011 01:41:51 +0000 From: Cui Yang X-Originating-IP: [10.108.64.159] To: "ipsec@ietf.org" Message-id: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: Review request for IPsec security for packet based synchronization (Yang Cui) Thread-index: Acx2bU0nGnMbOv0GSKWyrWTZm9gvcw== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: "TICTOC@ietf.org" Subject: [IPsec] Review request for IPsec security for packet based synchronization (Yang Cui) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 01:41:15 -0000 Dear IPsec experts, cc TICTOC WG May I make a review request for the draft on "IPsec security for packet based synchronization" http://datatracker.ietf.org/doc/draft-xu-tictoc-ipsec-security-for-synchronization/ Abstract: Cellular networks often use Internet standard technologies to handle synchronization. This document defines an extension based on WESP. Usually, several traffic flows are carried in one IPsec tunnel, for some applications, such as, 1588 or NTP, the packets need to be identified after IPsec encryption to handle specially. In order to achieve high scalability in implement, a separate IPsec tunnel will not be established for some special traffic. This document analyses the need for security methods for synchronization messages distributed over the Internet. This document also gives a solution on how to mark the synchronization message when IPSec is implemented in end to end frequency synchronization." This work is proposed in TICTOC WG, but closely related to the IPsec security issues in synchronization. We would like to get advices from security experts. Any comments will be highly appreciated. Thanks! Best regards, -- Yang Cui Huawei Technologies cuiyang@huawei.com From ramaswamy.bm@globaledgesoft.com Mon Sep 19 07:25:27 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5559721F8C3F for ; Mon, 19 Sep 2011 07:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.152 X-Spam-Level: X-Spam-Status: No, score=0.152 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_20=-0.74, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmIkGw+f2gvz for ; Mon, 19 Sep 2011 07:25:26 -0700 (PDT) Received: from gesmail.globaledgesoft.com (gesmail.globaledgesoft.com [119.82.106.22]) by ietfa.amsl.com (Postfix) with ESMTP id 60DBE21F8C39 for ; Mon, 19 Sep 2011 07:25:26 -0700 (PDT) Received: from RamaswamySM (ramaswamy_sm.globaledgesoft.com [172.16.8.54]) by gesmail.globaledgesoft.com (Postfix) with ESMTP id ED90F588225; Mon, 19 Sep 2011 20:00:40 +0530 (IST) From: "ramaswamy" To: "'Tero Kivinen'" References: <20013.29623.491247.654466@fireball.kivinen.iki.fi> <90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com> <4E2EA248.70708@gmail.com> <008901cc63b8$e5c9c640$b15d52c0$@bm@globaledgesoft.com> <20060.43306.157789.942917@fireball.kivinen.iki.fi> In-Reply-To: <20060.43306.157789.942917@fireball.kivinen.iki.fi> Date: Mon, 19 Sep 2011 19:57:32 +0530 Message-ID: <00e301cc76d8$44b0e940$ce12bbc0$@bm@globaledgesoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acxm9RwEPTnFAoxnTfyMsDhIPElU8gP4yXSA Content-Language: en-us Cc: ipsec@ietf.org, ipsec-tools-devel@lists.sourceforge.net, ipsec-tools-users@lists.sourceforge.net, ikev2-devel@lists.sourceforge.net Subject: Re: [IPsec] New method to resist replay attack in ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 14:25:27 -0000 Thanks for the response, I agree with your comments, I think we can use certificates to avoid man in the middle attacks and error message flooding in the INIT phase only, as certificates are signed by trusted certificate authorities authenticity is ensured. If certificates are used in INIT message exchanges [mutual authentication], we can effectively avoid afore said attacks as it avoids huge computation of IKE-keys before the client OR server is authenticated. To avoid Replay attacks: By using RSA private key of certificate to encrypt the nonce (Ni) in INIT_REQUEST message we can avoid replay attacks, at the receiving end, first certificate is verified using root CA and nonce is decrypted using public key of the received certificate which ensures that sender holds the valid private key of the certificate and not an attacker. By using nonce we can avoid Replay attacks[Packets can be rejected if the same nonce is received within a particular session]. Please assert and also let us know if any related drafts/rfc to avoid these attacks. Best Regards , Ram -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi] Sent: Tuesday, August 30, 2011 2:41 PM To: ramaswamy Cc: ipsec@ietf.org; ipsec-tools-devel@lists.sourceforge.net; ipsec-tools-users@lists.sourceforge.net; ikev2-devel@lists.sourceforge.net Subject: [IPsec] New method to resist replay attack in ikev2 ramaswamy writes: > Proposed new negotiations > > Before initial exchange begins initiator looks up to the pre shared > secret with the intended responder and does the hash value on first > half of pre shared secret, nonce of the initiator. Once the > responder receives the request it looks up the correspondence pre > shared key in its table and it takes the nonce form initiator > request message then it does a hash value to authenticate the > initiator. This is bit like how IKEv1 did it, and it has same problem than IKEv1 had with that, meaning it does not provide ANY identity protection at all. The responder needs to find the pre-shared key for the initiator based only with the information that are in the first IKE_SA_INIT packet. This DOES NOT include identity of the initiator, and SAi1, KEi, and Ni does not help at all in this process. The only information that responder has which it can use is the source IP-address of the IKE_SA_INIT packet. This has the effect that the pre-shared key will be tied to the source IP-address of the initiator, which mean every passive listener will also see that same IP-address and will know the identity of the initiator. The method in IKEv2 where the PSK is not tied to the IP-address of the initiator offers much better identity protection, as now the responder identity is only releaved to the active attacker. -- kivinen@iki.fi From kivinen@iki.fi Mon Sep 19 17:43:18 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E527321F8B5E for ; Mon, 19 Sep 2011 17:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qERFj-xsl5HQ for ; Mon, 19 Sep 2011 17:43:18 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1443321F8B2F for ; Mon, 19 Sep 2011 17:43:17 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p8K0jYFE005828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Sep 2011 03:45:34 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p8K0jWCh023697; Tue, 20 Sep 2011 03:45:32 +0300 (EEST) 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: <20087.57900.897702.835641@fireball.kivinen.iki.fi> Date: Tue, 20 Sep 2011 03:45:32 +0300 From: Tero Kivinen To: "ramaswamy" In-Reply-To: <00e301cc76d8$44b0e940$ce12bbc0$@bm@globaledgesoft.com> References: <20013.29623.491247.654466@fireball.kivinen.iki.fi> <90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com> <4E2EA248.70708@gmail.com> <008901cc63b8$e5c9c640$b15d52c0$@bm@globaledgesoft.com> <20060.43306.157789.942917@fireball.kivinen.iki.fi> <00e301cc76d8$44b0e940$ce12bbc0$@bm@globaledgesoft.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min Cc: ipsec@ietf.org, ipsec-tools-devel@lists.sourceforge.net, ipsec-tools-users@lists.sourceforge.net, ikev2-devel@lists.sourceforge.net Subject: Re: [IPsec] New method to resist replay attack in ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 00:43:19 -0000 ramaswamy writes: > Thanks for the response, I agree with your comments, I think we can use > certificates to avoid man in the middle attacks and error message flooding > in the INIT phase only, as certificates are signed by trusted certificate > authorities authenticity is ensured. > > If certificates are used in INIT message exchanges [mutual authentication], > we can effectively avoid afore said attacks as it avoids huge computation of > IKE-keys before the client OR server is authenticated. RSA operations are already huge computation. There is no big difference whether you do RSA or Diffie-Hellman. > To avoid Replay attacks: > By using RSA private key of certificate to encrypt the nonce (Ni) in > INIT_REQUEST message we can avoid replay attacks, at the receiving end, > first certificate is verified using root CA and nonce is decrypted using > public key of the received certificate which ensures that sender holds the > valid private key of the certificate and not an attacker. By using nonce we > can avoid Replay attacks[Packets can be rejected if the same nonce is > received within a particular session]. So you plan to store that nonce forever, and always verify that the nonce is not used before? That would be extremely expensive way to solve the replay attack. -- kivinen@iki.fi From ramaswamy.bm@globaledgesoft.com Tue Sep 20 00:10:41 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA8F21F8A67 for ; Tue, 20 Sep 2011 00:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.592 X-Spam-Level: X-Spam-Status: No, score=-0.592 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NN0CQLbQF4EE for ; Tue, 20 Sep 2011 00:10:40 -0700 (PDT) Received: from gesmail.globaledgesoft.com (gesmail.globaledgesoft.com [119.82.106.22]) by ietfa.amsl.com (Postfix) with ESMTP id 0452621F8A64 for ; Tue, 20 Sep 2011 00:10:37 -0700 (PDT) Received: from RamaswamySM (ramaswamy_sm.globaledgesoft.com [172.16.8.54]) by gesmail.globaledgesoft.com (Postfix) with ESMTP id 8B7025882C2; Tue, 20 Sep 2011 12:45:54 +0530 (IST) From: "ramaswamy" To: "'Tero Kivinen'" References: <20013.29623.491247.654466@fireball.kivinen.iki.fi> <90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com> <4E2EA248.70708@gmail.com> <008901cc63b8$e5c9c640$b15d52c0$@bm@globaledgesoft.com> <20060.43306.157789.942917@fireball.kivinen.iki.fi> <00e301cc76d8$44b0e940$ce12bbc0$@bm@globaledgesoft.com> <20087.57900.897702.835641@fireball.kivinen.iki.fi> In-Reply-To: <20087.57900.897702.835641@fireball.kivinen.iki.fi> Date: Tue, 20 Sep 2011 12:42:45 +0530 Message-ID: <00a901cc7764$b1da4b10$158ee130$@bm@globaledgesoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acx3Lw/ZXwa4JV2PQYSqB5taTHlj8gALYVdA Content-Language: en-us Cc: ipsec@ietf.org, ipsec-tools-devel@lists.sourceforge.net, ipsec-tools-users@lists.sourceforge.net, ikev2-devel@lists.sourceforge.net Subject: Re: [IPsec] New method to resist replay attack in ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 07:10:41 -0000 Please see my comments inline. Best Regards , Ram -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen Sent: Tuesday, September 20, 2011 6:16 AM To: ramaswamy Cc: ipsec@ietf.org; ipsec-tools-devel@lists.sourceforge.net; ipsec-tools-users@lists.sourceforge.net; ikev2-devel@lists.sourceforge.net Subject: Re: [IPsec] New method to resist replay attack in ikev2 ramaswamy writes: > Thanks for the response, I agree with your comments, I think we can use > certificates to avoid man in the middle attacks and error message flooding > in the INIT phase only, as certificates are signed by trusted certificate > authorities authenticity is ensured. > > If certificates are used in INIT message exchanges [mutual authentication], > we can effectively avoid afore said attacks as it avoids huge computation of > IKE-keys before the client OR server is authenticated. RSA operations are already huge computation. There is no big difference whether you do RSA or Diffie-Hellman. >>>>>>>>>>> [Ram] I agree with you, but we have certificate verification done at AUTH phase, our suggestion is the same can be moved to initial phase of ikev2 exchanges and this will ensure authenticity before IKEv2-KEYS[seven keys] are generated. As IKE users are already authenticated there is no need of CERT message exchanges in AUTH phase and also which in turn will help to avoid man in the middle attacks and error message flooding at IKEv2-INIT level only. And also it will avoid unnecessary computation of ikev2-keys[seven keys: which involves huge computation] at server end due to INIT-REQESTS sent by attackers. >>>>>>>>>>>>>>>>>>>>>>>>>>> > To avoid Replay attacks: > By using RSA private key of certificate to encrypt the nonce (Ni) in > INIT_REQUEST message we can avoid replay attacks, at the receiving end, > first certificate is verified using root CA and nonce is decrypted using > public key of the received certificate which ensures that sender holds the > valid private key of the certificate and not an attacker. By using nonce we > can avoid Replay attacks[Packets can be rejected if the same nonce is > received within a particular session]. So you plan to store that nonce forever, and always verify that the nonce is not used before? That would be extremely expensive way to solve the replay attack. >>>>>>>>>>> [Ram] I agree that storing nonce forever is not an best solution to solve replay attacks, but our suggestion is to store the nonce from particular client for particular session [time limit Eg: 2 minutes]. If it receives same nonce with in the permissible time limit it should rejected. If it more than permissible limit server will throw an error SKEW_ERROR, handling of which is explained below. To do it more effectively Ikev2 client should be clock synchronized with server by negotiating client time by using encrypted nonce(Ni) --> timestamp [Ni is encrypted by RSA private key of certificate of ikev2 client certificate] in INIT-REQUEST it self, and server can check the received time [encrypted nonce(Ni):timestamp] and if it is more than permissible time limit say Eg: 2 minutes it can throw an clock skew error[SKEW_ERROR], by putting its server time using encrypted server nonce (Nr) using RSA private key of certificate of ikev2 server certificate. Upon receipt of skew error ikev2 client must compute the difference (in seconds) between the two clocks based upon the client and server time contained in the SKEW_ERROR message. The client should store this clock difference in non-volatile memory and must use it to adjust ikev2 client timestamps[Ni] in subsequent INIT-REQ request messages by adding the clock skew to its local clock value each time. If the encrypted nonce differs from server time by permissible limit it can reject the INIT-REQ and avoid replay attacks. >>>>>>>>>>>>>>>>>> -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From xiangyang.zhang@huawei.com Fri Sep 23 17:55:51 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBED21F8C15 for ; Fri, 23 Sep 2011 17:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUABWhGKg1F3 for ; Fri, 23 Sep 2011 17:55:51 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 407F121F8BF8 for ; Fri, 23 Sep 2011 17:55:51 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS000AAS5DD9P@usaga02-in.huawei.com> for ipsec@ietf.org; Fri, 23 Sep 2011 19:58:26 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LS0008EU5DDHA@usaga02-in.huawei.com> for ipsec@ietf.org; Fri, 23 Sep 2011 19:58:25 -0500 (CDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 23 Sep 2011 17:58:27 -0700 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Fri, 23 Sep 2011 17:58:24 -0700 Date: Sat, 24 Sep 2011 00:58:24 +0000 From: Xiangyang zhang In-reply-to: <1316126496.5636.YahooMailClassic@web36406.mail.mud.yahoo.com> X-Originating-IP: [10.193.34.188] To: Joby Sebastian , "ipsec@ietf.org" Message-id: <00E6CDB229A4CF4487D6E0326EDE5A0317EFCDEF@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [IPsec] Replay window size Thread-index: AQHMdUsa3Qm/FMvHwkWwimWTDW/msZVbs2AQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1316126496.5636.YahooMailClassic@web36406.mail.mud.yahoo.com> Subject: Re: [IPsec] Replay window size X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 00:55:51 -0000 The replay window is used to tolerate the out-of-order packets, which is unpredictable before arrivals. The bigger window size should not introduce the security hole and be more prone to the attack. If an attacker eavesdrops the IPsec packet and if he/she has the capability of dropping the original packet, he/she sends only the replayed packet instead of original packet. In this case, even the small window has the same problem. It does not mean the bigger window size give the attacker more time to prepare the attack. But if the window is bigger, the performance may be affected. So it is a tradeoff and depends on the network bandwidth. -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Joby Sebastian Sent: Thursday, September 15, 2011 3:42 PM To: ipsec@ietf.org Subject: [IPsec] Replay window size Hi, If my ESP replay window implementation supports a largest replay window size (say 4096), and there is no significant performance drop in managing a bigger window size, is it is always better to use the biggest window size? Is there a case where using a smaller window size is more desirable? Does a bigger window size introduce a security hole and more prone to an attack? Thanks, Joby _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ramaswamy.bm@globaledgesoft.com Tue Sep 27 03:25:43 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1F121F8B7D for ; Tue, 27 Sep 2011 03:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpvnDfuSfTfY for ; Tue, 27 Sep 2011 03:25:43 -0700 (PDT) Received: from gesmail.globaledgesoft.com (gesmail.globaledgesoft.com [119.82.106.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8A33221F8B12 for ; Tue, 27 Sep 2011 03:25:41 -0700 (PDT) Received: from RamaswamySM (ramaswamy_sm.globaledgesoft.com [172.16.8.54]) by gesmail.globaledgesoft.com (Postfix) with ESMTP id 51D451820001; Tue, 27 Sep 2011 16:01:30 +0530 (IST) From: "ramaswamy" To: "'Tero Kivinen'" References: <20013.29623.491247.654466@fireball.kivinen.iki.fi> <90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com> <4E2EA248.70708@gmail.com> <008901cc63b8$e5c9c640$b15d52c0$@bm@globaledgesoft.com> <20060.43306.157789.942917@fireball.kivinen.iki.fi> <00e301cc76d8$44b0e940$ce12bbc0$@bm@globaledgesoft.com> <20087.57900.897702.835641@fireball.kivinen.iki.fi> In-Reply-To: Date: Tue, 27 Sep 2011 15:58:08 +0530 Message-ID: <00e901cc7d00$26a4ac60$73ee0520$@bm@globaledgesoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acx3Lw/ZXwa4JV2PQYSqB5taTHlj8gALYVdAAWjgLsA= Content-Language: en-us Cc: ipsec@ietf.org, ipsec-tools-devel@lists.sourceforge.net, ipsec-tools-users@lists.sourceforge.net, ikev2-devel@lists.sourceforge.net Subject: Re: [IPsec] New method to resist replay attack in ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 10:25:43 -0000 Please see my comments inline. Best Regards , Ram -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen Sent: Tuesday, September 20, 2011 6:16 AM To: ramaswamy Cc: ipsec@ietf.org; ipsec-tools-devel@lists.sourceforge.net; ipsec-tools-users@lists.sourceforge.net; ikev2-devel@lists.sourceforge.net Subject: Re: [IPsec] New method to resist replay attack in ikev2 ramaswamy writes: > Thanks for the response, I agree with your comments, I think we can > use certificates to avoid man in the middle attacks and error message > flooding in the INIT phase only, as certificates are signed by trusted > certificate authorities authenticity is ensured. > > If certificates are used in INIT message exchanges [mutual > authentication], we can effectively avoid afore said attacks as it > avoids huge computation of IKE-keys before the client OR server is authenticated. RSA operations are already huge computation. There is no big difference whether you do RSA or Diffie-Hellman. >>>>>>>>>>> [Ram] I agree with you, but we have certificate verification done at AUTH phase, our suggestion is the same can be moved to initial phase of ikev2 exchanges and this will ensure authenticity before IKEv2-KEYS[seven keys] are generated. As IKE users are already authenticated there is no need of CERT message exchanges in AUTH phase and also which in turn will help to avoid man in the middle attacks and error message flooding at IKEv2-INIT level only. And also it will avoid unnecessary computation of ikev2-keys[seven keys: which involves huge computation] at server end due to INIT-REQESTS sent by attackers. >>>>>>>>>>>>>>>>>>>>>>>>>>> > To avoid Replay attacks: > By using RSA private key of certificate to encrypt the nonce (Ni) in > INIT_REQUEST message we can avoid replay attacks, at the receiving > end, first certificate is verified using root CA and nonce is > decrypted using public key of the received certificate which ensures > that sender holds the valid private key of the certificate and not an > attacker. By using nonce we can avoid Replay attacks[Packets can be > rejected if the same nonce is received within a particular session]. So you plan to store that nonce forever, and always verify that the nonce is not used before? That would be extremely expensive way to solve the replay attack. >>>>>>>>>>> [Ram] I agree that storing nonce forever is not an best solution to solve replay attacks, but our suggestion is to store the nonce from particular client for particular session [time limit Eg: 2 minutes]. If it receives same nonce with in the permissible time limit it should rejected. If it more than permissible limit server will throw an error SKEW_ERROR, handling of which is explained below. To do it more effectively Ikev2 client should be clock synchronized with server by negotiating client time by using encrypted nonce(Ni) --> timestamp [Ni is encrypted by RSA private key of certificate of ikev2 client certificate] in INIT-REQUEST it self, and server can check the received time [encrypted nonce(Ni):timestamp] and if it is more than permissible time limit say Eg: 2 minutes it can throw an clock skew error[SKEW_ERROR], by putting its server time using encrypted server nonce (Nr) using RSA private key of certificate of ikev2 server certificate. Upon receipt of skew error ikev2 client must compute the difference (in seconds) between the two clocks based upon the client and server time contained in the SKEW_ERROR message. The client should store this clock difference in non-volatile memory and must use it to adjust ikev2 client timestamps[Ni] in subsequent INIT-REQ request messages by adding the clock skew to its local clock value each time. If the encrypted nonce differs from server time by permissible limit it can reject the INIT-REQ and avoid replay attacks. >>>>>>>>>>>>>>>>>> -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec