From ipsec-bounces@ietf.org Thu Jul 3 12:38:17 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D65D43A6919; Thu, 3 Jul 2008 12:38:17 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 797E23A691F for ; Thu, 3 Jul 2008 12:38:16 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ey1xSilv88gH for ; Thu, 3 Jul 2008 12:38:15 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id B28E03A6774 for ; Thu, 3 Jul 2008 12:38:15 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m63JbgnP029234 for ; Thu, 3 Jul 2008 14:38:22 -0500 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Jul 2008 22:35:33 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Jul 2008 22:35:28 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Jul 2008 22:34:35 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720112A978@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPSECME WG approved Thread-Index: AcjdQ9Ll3AH7G+/+T7uy1G+4rqgnBw== From: To: X-OriginalArrivalTime: 03 Jul 2008 19:35:28.0800 (UTC) FILETIME=[F2E99200:01C8DD43] X-Nokia-AV: Clean Subject: [IPsec] IPSECME WG approved X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Congratulations, we have a new WG! We'd like to welcome Paul Hoffman and Yaron Sheffer as the WG chairs, and also thank everyone who volunteered. If you've checked the IETF72 agenda within the last hour or so, you've noticed that we're also scheduled to meet in Dublin, on Monday morning 0900-1130 (subject to late changes, as usual). Let's help Paul and Yaron in getting the WG up and running, and organizing a productive meeting in Dublin! Best regards, Pasi & Tim _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jul 3 12:46:48 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F7E63A6AD1; Thu, 3 Jul 2008 12:46:48 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B2C03A6AA2 for ; Thu, 3 Jul 2008 12:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bynoHVwPu8SO for ; Thu, 3 Jul 2008 12:46:45 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 4C99B3A6822 for ; Thu, 3 Jul 2008 12:46:45 -0700 (PDT) Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m63JkoAC060358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 Jul 2008 12:46:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1696498986EFEC4D9153717DA325CB720112A978@vaebe104.NOE.Nokia.com> References: <1696498986EFEC4D9153717DA325CB720112A978@vaebe104.NOE.Nokia.com> Date: Thu, 3 Jul 2008 12:46:47 -0700 To: From: Paul Hoffman Subject: Re: [IPsec] IPSECME WG approved X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Thanks, Pasi! We hope to be one of the few IETF WGs who turns in high-quality documents on time. We will start the discussions of which documents to use in the WG shortly. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jul 4 15:07:08 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D18DD3A69C0; Fri, 4 Jul 2008 15:07:08 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E75A23A69AC for ; Fri, 4 Jul 2008 15:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxT+6Mlkpk6l for ; Fri, 4 Jul 2008 15:07:07 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by core3.amsl.com (Postfix) with ESMTP id 353373A69C0 for ; Fri, 4 Jul 2008 15:07:07 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m64M24CC027788 for ; Fri, 4 Jul 2008 18:02:04 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m64M79vG147706 for ; Fri, 4 Jul 2008 16:07:09 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m64M79gW021012 for ; Fri, 4 Jul 2008 16:07:09 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m64M79j2021009 for ; Fri, 4 Jul 2008 16:07:09 -0600 Auto-Submitted: auto-generated From: John Majikes To: ipsec@ietf.org Message-ID: Date: Fri, 4 Jul 2008 16:07:08 -0600 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.0.1|February 07, 2008) at 07/04/2008 16:07:09 MIME-Version: 1.0 Subject: [IPsec] vacation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1978162650==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1978162650== Content-type: multipart/alternative; Boundary="0__=08BBFEEFDFEA066F8f9e8a93df938690918c08BBFEEFDFEA066F" Content-Disposition: inline --0__=08BBFEEFDFEA066F8f9e8a93df938690918c08BBFEEFDFEA066F Content-type: text/plain; charset=US-ASCII I will be out of the office starting 07/02/2008 and will not return until 07/08/2008. I will be out of the office until MTuesday July 8. I will not answer phone message, e-mails, etcetera. For questions, please contact my manager Greg Stefanicki. gregs@us.ibm.com. --0__=08BBFEEFDFEA066F8f9e8a93df938690918c08BBFEEFDFEA066F Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I will be out of the office starting 07/02/2008 and will not return until 07/08/2008.

I will be out of the office until MTuesday July 8. I will not answer phone message, e-mails, etcetera. For questions, please contact my manager Greg Stefanicki. gregs@us.ibm.com.

--0__=08BBFEEFDFEA066F8f9e8a93df938690918c08BBFEEFDFEA066F-- --===============1978162650== 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://www.ietf.org/mailman/listinfo/ipsec --===============1978162650==-- From ipsec-bounces@ietf.org Sun Jul 6 12:44:21 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33DF73A68AD; Sun, 6 Jul 2008 12:44:21 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 798683A68AD for ; Sun, 6 Jul 2008 12:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMTb8tVSiErm for ; Sun, 6 Jul 2008 12:44:18 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 1F81B3A67B6 for ; Sun, 6 Jul 2008 12:44:18 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id A2D60294002; Sun, 6 Jul 2008 22:44:21 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 5E695294001 for ; Sun, 6 Jul 2008 22:42:24 +0300 (IDT) Received: from [172.16.10.243] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m66JgNjI015849 for ; Sun, 6 Jul 2008 22:42:24 +0300 (IDT) Message-ID: <4871201F.3010403@checkpoint.com> Date: Sun, 06 Jul 2008 22:42:23 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: ipsec@ietf.org Subject: [IPsec] [Fwd: I-D Action:draft-sheffer-ikev2-gtc-00.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0874991685==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0874991685== Content-Type: multipart/alternative; boundary="------------070900060101090008020108" This is a multi-part message in MIME format. --------------070900060101090008020108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I have posted this draft as an individual, informational draft. This issue has been discussed on this list a few years ago, but it still bears some more analysis. Thanks, Yaron -------- Original Message -------- Subject: I-D Action:draft-sheffer-ikev2-gtc-00.txt Date: Sun, 6 Jul 2008 09:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using EAP-GTC for Simple User Authentication in IKEv2 Author(s) : Y. Sheffer Filename : draft-sheffer-ikev2-gtc-00.txt Pages : 9 Date : 2008-07-06 Despite many years of effort, simple username-password authentication is still prevalent. In many cases a password is the only credential available to the end user. IKEv2 uses EAP as a sub-protocol for user authentication. This provides a well-specified and extensible architecture. To this day EAP does not provide a simple password- based authentication method. The only existing password authentication methods either require the peer to know the password in advance (EAP-MD5), or are needlessly complex when used within IKEv2 (e.g. PEAP). This document codifies the common practice of using EAP-GTC for this type of authentication, with the goal of achieving maximum interoperability. The various security issues are extensively analyzed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sheffer-ikev2-gtc-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------070900060101090008020108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hi,


I have posted this draft as an individual, informational draft. This issue has been discussed on this list a few years ago, but it still bears some more analysis.


Thanks,

    Yaron


-------- Original Message --------
Subject: I-D Action:draft-sheffer-ikev2-gtc-00.txt
Date: Sun, 6 Jul 2008 09:30:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Using EAP-GTC for Simple User Authentication in IKEv2
	Author(s)       : Y. Sheffer
	Filename        : draft-sheffer-ikev2-gtc-00.txt
	Pages           : 9
	Date            : 2008-07-06

Despite many years of effort, simple username-password authentication
is still prevalent.  In many cases a password is the only credential
available to the end user.  IKEv2 uses EAP as a sub-protocol for user
authentication.  This provides a well-specified and extensible
architecture.  To this day EAP does not provide a simple password-
based authentication method.  The only existing password
authentication methods either require the peer to know the password
in advance (EAP-MD5), or are needlessly complex when used within
IKEv2 (e.g.  PEAP).  This document codifies the common practice of
using EAP-GTC for this type of authentication, with the goal of
achieving maximum interoperability.  The various security issues are
extensively analyzed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sheffer-ikev2-gtc-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--------------070900060101090008020108-- --===============0874991685== 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://www.ietf.org/mailman/listinfo/ipsec --===============0874991685==-- From ipsec-bounces@ietf.org Sun Jul 6 13:00:46 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43EC53A684E; Sun, 6 Jul 2008 13:00:46 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B3103A684E for ; Sun, 6 Jul 2008 13:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJoGOMY620F4 for ; Sun, 6 Jul 2008 13:00:44 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 0BF503A6768 for ; Sun, 6 Jul 2008 13:00:43 -0700 (PDT) Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m66K0ge0051862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jul 2008 13:00:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4871201F.3010403@checkpoint.com> References: <4871201F.3010403@checkpoint.com> Date: Sun, 6 Jul 2008 13:00:40 -0700 To: Yaron Sheffer , ipsec@ietf.org From: Paul Hoffman Subject: Re: [IPsec] [Fwd: I-D Action:draft-sheffer-ikev2-gtc-00.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 10:42 PM +0300 7/6/08, Yaron Sheffer wrote: >I have posted this draft as an individual, informational draft. This >issue has been discussed on this list a few years ago, but it still >bears some more analysis. Just as a note: this is *not* a WG work item. It's an IPsec-related draft that people here should know about. Yaron and I are putting together some materials for the WG now, particularly a proposed agenda for our f2f meeting. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 7 02:05:16 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F1FD3A6A71; Mon, 7 Jul 2008 02:05:16 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3B23A6A71 for ; Mon, 7 Jul 2008 02:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4binKUbDfg7F for ; Mon, 7 Jul 2008 02:05:14 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 818F23A6918 for ; Mon, 7 Jul 2008 02:05:14 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so2273401wfd.31 for ; Mon, 07 Jul 2008 02:05:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=7Y1W7itvsbsTnJETcSN6sqMheYFlP9Zi5pq35+1TJ9U=; b=jviL0/gj1nkIgolCGvF2vNseqpqO4jQ393wQ2ylJDxBMWig+G5byGikKNJGeTDovJb TTVoWI9WC6NjJxaH/u2R9aEf53N7AajvbBDMwjIsRPj0wMX50Koas5Esoxec9XJNznRi OoorUAnlrUAOcI1qDPBcboJhGykWoPkfABiw0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=vk7M7oKgPG+Cztq3uDN7g6E1Gzd3OVwWMnsksSJFnVffiqa3aRRJ5CV5Bg45KccVyG 8HAIZzay7z0y6TOR9H/BXk6TDDi13xf/UG5tF6f05b6xFg528+YoV/gDT0Q0+WfpUbzI dnMH9UJcJFUN3pRjAlrUtehJDCazbh731GK/U= Received: by 10.142.222.21 with SMTP id u21mr1198839wfg.318.1215421520385; Mon, 07 Jul 2008 02:05:20 -0700 (PDT) Received: by 10.142.161.15 with HTTP; Mon, 7 Jul 2008 02:05:20 -0700 (PDT) Message-ID: <4c5c7a6d0807070205v484436c5y3b5ab836a7175f67@mail.gmail.com> Date: Mon, 7 Jul 2008 18:05:20 +0900 From: "Peny Yang" To: ipsec@ietf.org In-Reply-To: <029d01c8e00e$203b99c0$2302600a@hitachichina.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_20959_26390511.1215421520379" References: <029d01c8e00e$203b99c0$2302600a@hitachichina.com> Cc: paul.hoffman@vpnc.org Subject: [IPsec] Fwd: FW: I-D Action:draft-xu-ike-sa-sync-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ------=_Part_20959_26390511.1215421520379 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, folks: We have submitted the draft on IKEv2 SA synchronization. Please check it. Comments are more than welcome. And, if possible, I would like to apply for a slot to present our work in the incoming IPsec WG meeting in Dublin. Thanks a lot BRG Peny > >-----Original Message----- > >From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > >On Behalf Of Internet-Drafts@ietf.org > >Sent: Monday, July 07, 2008 4:30 PM > >To: i-d-announce@ietf.org > >Subject: I-D Action:draft-xu-ike-sa-sync-00.txt > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > Title : IKE SA Synchronization > > Author(s) : Y. Xu, et al. > > Filename : draft-xu-ike-sa-sync-00.txt > > Pages : 17 > > Date : 2008-07-07 > > > >It will take a long time to do security association syncronization > >among IKE/IPsec gateways possibly maintaining huge numbers of IKEv2/ > >IPsec SAs. The major reason is that the prcocedure of IKEv2 SA re- > >establishment will incur a time-consuming computation especially in > >the Diffie-Hellman exchange. In this draft, a new IKE security > >associations synchronization solution is proposed to reduce the > >computation by directly transferring the indexed IKE SA from old > >gateway to new gateway, wherein the most expensive Diffie-Hellman > >calculation can be avoided. Without some time-consuming IKEv2 > >exchanges, the huge amount of IKE/IPsec SA synchronization procedures > >can be finished in a short time. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-xu-ike-sa-sync-00.txt > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >Below is the data which will enable a MIME compliant mail reader > >implementation to automatically retrieve the ASCII version of the > >Internet-Draft. ------=_Part_20959_26390511.1215421520379 Content-Type: text/plain; name=draft-xu-ike-sa-sync-00.txt Content-Transfer-Encoding: base64 X-Attachment-Id: 0.1 Content-Disposition: attachment; filename=draft-xu-ike-sa-sync-00.txt Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6IDwyMDA4LTA3LTA3MDEyNTQwLkkt REBpZXRmLm9yZz4KCg== ------=_Part_20959_26390511.1215421520379 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://www.ietf.org/mailman/listinfo/ipsec ------=_Part_20959_26390511.1215421520379-- From ipsec-bounces@ietf.org Mon Jul 7 03:32:08 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5F4528C18B; Mon, 7 Jul 2008 03:32:08 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C97D528C18A for ; Mon, 7 Jul 2008 03:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pktYRkTAFX9i for ; Mon, 7 Jul 2008 03:32:06 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id D714528C193 for ; Mon, 7 Jul 2008 03:31:48 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 2D465294002; Mon, 7 Jul 2008 13:31:54 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 3EBF1294001; Mon, 7 Jul 2008 13:31:53 +0300 (IDT) Received: from RnD-Test.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m67AVqjI020010; Mon, 7 Jul 2008 13:31:53 +0300 (IDT) Message-Id: <403C9D3A-5D1B-43B6-91CF-078C7F209136@checkpoint.com> From: Yoav Nir To: Peny Yang In-Reply-To: <4c5c7a6d0807070205v484436c5y3b5ab836a7175f67@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 7 Jul 2008 13:31:52 +0300 References: <029d01c8e00e$203b99c0$2302600a@hitachichina.com> <4c5c7a6d0807070205v484436c5y3b5ab836a7175f67@mail.gmail.com> X-Mailer: Apple Mail (2.926) Cc: ipsec@ietf.org, paul.hoffman@vpnc.org Subject: Re: [IPsec] Fwd: FW: I-D Action:draft-xu-ike-sa-sync-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Peny. Looks like we have a lot of drafts lately dealing with crash recovery: IFARE, QCD, SIR, and now yours (in chronological order). Specifically, it looks like your proposal is competing with the IFARE proposal: http://www.ietf.org/internet-drafts/draft-sheffer-ipsec-failover-03.txt I've only gave it a cursory read, but if I understand it correctly, you propose to follow something like session resumption in TLS, where the client detects the failure of the gateway, and begins a new IKE_INIT. You add a payload to the IKE_INIT exchange with the IKE cookies of the old IKE SA. If the server has a copy, the asymmetric operations are not performed, and we get the keys with relatively cheap operations. You may want to post to the list some cons/pros of your proposal vs ipsec-failover. Specific comments about the draft: - I think you should add a specific description about how keys are derived with a successful stub lookup - I think you should remove the text that deals with internal structure (and the use of STL). We only need to know what the gateway should be able to look up - I'm not sure I understand section 3.6. I understand the format of the SYN payload, but I don't get the stub-related signaling. Are you specifying the signaling protocol between the gateways, or is that left as a local matter? Is interoperability between different vendor's gateways a goal of this specification? Thanks Yoav On Jul 7, 2008, at 12:05 PM, Peny Yang wrote: > Hi, folks: > > We have submitted the draft on IKEv2 SA synchronization. Please > check it. > Comments are more than welcome. > > And, if possible, I would like to apply for a slot to present our work > in the incoming IPsec WG meeting in Dublin. > > Thanks a lot > BRG > Peny > > > >>> -----Original Message----- >>> From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] >>> On Behalf Of Internet-Drafts@ietf.org >>> Sent: Monday, July 07, 2008 4:30 PM >>> To: i-d-announce@ietf.org >>> Subject: I-D Action:draft-xu-ike-sa-sync-00.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : IKE SA Synchronization >>> Author(s) : Y. Xu, et al. >>> Filename : draft-xu-ike-sa-sync-00.txt >>> Pages : 17 >>> Date : 2008-07-07 >>> >>> It will take a long time to do security association syncronization >>> among IKE/IPsec gateways possibly maintaining huge numbers of IKEv2/ >>> IPsec SAs. The major reason is that the prcocedure of IKEv2 SA re- >>> establishment will incur a time-consuming computation especially in >>> the Diffie-Hellman exchange. In this draft, a new IKE security >>> associations synchronization solution is proposed to reduce the >>> computation by directly transferring the indexed IKE SA from old >>> gateway to new gateway, wherein the most expensive Diffie-Hellman >>> calculation can be avoided. Without some time-consuming IKEv2 >>> exchanges, the huge amount of IKE/IPsec SA synchronization >>> procedures >>> can be finished in a short time. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-xu-ike-sa-sync-00.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. > > > Scanned by Check Point Total Security Gateway. > sync-00.txt>_______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 7 05:53:55 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B6F63A6A6A; Mon, 7 Jul 2008 05:53:55 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7B453A69F8 for ; Mon, 7 Jul 2008 05:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnUBiBXndWsY for ; Mon, 7 Jul 2008 05:53:53 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 396EE3A6AA0 for ; Mon, 7 Jul 2008 05:53:53 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id CB19229400F; Mon, 7 Jul 2008 15:53:58 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7CD4D29400E; Mon, 7 Jul 2008 15:53:57 +0300 (IDT) Received: from [91.90.139.89] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m67CrujI021628; Mon, 7 Jul 2008 15:53:57 +0300 (IDT) Message-ID: <487211E6.2060607@checkpoint.com> Date: Mon, 07 Jul 2008 15:53:58 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Peny Yang References: <029d01c8e00e$203b99c0$2302600a@hitachichina.com> <4c5c7a6d0807070205v484436c5y3b5ab836a7175f67@mail.gmail.com> In-Reply-To: <4c5c7a6d0807070205v484436c5y3b5ab836a7175f67@mail.gmail.com> Cc: ipsec@ietf.org, paul.hoffman@vpnc.org Subject: Re: [IPsec] Fwd: FW: I-D Action:draft-xu-ike-sa-sync-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0611078793==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0611078793== Content-Type: multipart/alternative; boundary="------------030004060000060202030400" This is a multi-part message in MIME format. --------------030004060000060202030400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Peny, thanks for your submission. Please note that while session resumption is on the ipsecme charter, failover from one gateway to another is explicitly outside the charter. The agenda for Dublin is likely to be busy; we will make an effort to accommodate short presentations of IPsec-related drafts, even when they don't strictly fall within the charter. Regards, Yaron Peny Yang wrote: > Hi, folks: > > We have submitted the draft on IKEv2 SA synchronization. Please check it. > Comments are more than welcome. > > And, if possible, I would like to apply for a slot to present our work > in the incoming IPsec WG meeting in Dublin. > > Thanks a lot > BRG > Peny > > > > >>> -----Original Message----- >>> From: i-d-announce-bounces@ietf.org >>> > [mailto:i-d-announce-bounces@ietf.org] > >>> On Behalf Of Internet-Drafts@ietf.org >>> Sent: Monday, July 07, 2008 4:30 PM >>> To: i-d-announce@ietf.org >>> Subject: I-D Action:draft-xu-ike-sa-sync-00.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : IKE SA Synchronization >>> Author(s) : Y. Xu, et al. >>> Filename : draft-xu-ike-sa-sync-00.txt >>> Pages : 17 >>> Date : 2008-07-07 >>> >>> It will take a long time to do security association syncronization >>> among IKE/IPsec gateways possibly maintaining huge numbers of IKEv2/ >>> IPsec SAs. The major reason is that the prcocedure of IKEv2 SA re- >>> establishment will incur a time-consuming computation especially in >>> the Diffie-Hellman exchange. In this draft, a new IKE security >>> associations synchronization solution is proposed to reduce the >>> computation by directly transferring the indexed IKE SA from old >>> gateway to new gateway, wherein the most expensive Diffie-Hellman >>> calculation can be avoided. Without some time-consuming IKEv2 >>> exchanges, the huge amount of IKE/IPsec SA synchronization procedures >>> can be finished in a short time. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-xu-ike-sa-sync-00.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> > > > Scanned by Check Point Total Security Gateway. > --------------030004060000060202030400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hi Peny,


thanks for your submission. Please note that while session resumption is on the ipsecme charter, failover from one gateway to another is explicitly outside the charter.


The agenda for Dublin is likely to be busy; we will make an effort to accommodate short presentations of IPsec-related drafts, even when they don't strictly fall within the charter.


Regards,

    Yaron


Peny Yang wrote:

Hi, folks:

We have submitted the draft on IKEv2 SA synchronization. Please check it.
Comments are more than welcome.

And, if possible, I would like to apply for a slot to present our work
in the incoming IPsec WG meeting in Dublin.

Thanks a lot
BRG
Peny



  
-----Original Message-----
From: i-d-announce-bounces@ietf.org
      
[mailto:i-d-announce-bounces@ietf.org]
  
On Behalf Of Internet-Drafts@ietf.org
Sent: Monday, July 07, 2008 4:30 PM
To: i-d-announce@ietf.org
Subject: I-D Action:draft-xu-ike-sa-sync-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

    Title           : IKE SA Synchronization
    Author(s)       : Y. Xu, et al.
    Filename        : draft-xu-ike-sa-sync-00.txt
    Pages           : 17
    Date            : 2008-07-07

It will take a long time to do security association syncronization
among IKE/IPsec gateways possibly maintaining huge numbers of IKEv2/
IPsec SAs.  The major reason is that the prcocedure of IKEv2 SA re-
establishment will incur a time-consuming computation especially in
the Diffie-Hellman exchange.  In this draft, a new IKE security
associations synchronization solution is proposed to reduce the
computation by directly transferring the indexed IKE SA from old
gateway to new gateway, wherein the most expensive Diffie-Hellman
calculation can be avoided.  Without some time-consuming IKEv2
exchanges, the huge amount of IKE/IPsec SA synchronization procedures
can be finished in a short time.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-xu-ike-sa-sync-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
      


Scanned by Check Point Total Security Gateway.
--------------030004060000060202030400-- --===============0611078793== 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://www.ietf.org/mailman/listinfo/ipsec --===============0611078793==-- From ipsec-bounces@ietf.org Mon Jul 7 08:05:53 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5713A6AE3; Mon, 7 Jul 2008 08:05:52 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59B253A6AE3 for ; Mon, 7 Jul 2008 08:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exRzKIKxJ37d for ; Mon, 7 Jul 2008 08:05:51 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by core3.amsl.com (Postfix) with ESMTP id ABC3B3A6ACA for ; Mon, 7 Jul 2008 08:05:40 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id i29so981027wxd.31 for ; Mon, 07 Jul 2008 08:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=b5n0xRC0c0NC6L6AvuiECVXv0uQ+aO1e+evvg6qwUHA=; b=hqzQgoOnqtCo471EwLYGW9NK2jy5SMqhurdmtXSrDofIsPLsbizN3MMpgL/mp3Q2jj ZEtf2s47YMZS9vznquf0K+o/wxro7haid2yDOmCSvDkTCCnGhx0m4LNJpuHaOVJHY/Ma bYPNdWX8qkXGGxl885QNIf0Opby/MSkMhNSMs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=A8Eo08JFE1z6oHcZ8E2NQq+Kpawwd7BKjC5DDW84YMtx56rhtuXzJILkPV7/IKDUtP ntyjo1Z3mFC/0o5IL9EnSTuVEqQ7hCkTRkId/nnO4JMdRf0mIkjWZsRfc+mNZcVjE93z I56lejYEKMgdEpbz3up7TVYNXUxomNwFBfi0c= Received: by 10.142.52.9 with SMTP id z9mr1338668wfz.30.1215443146171; Mon, 07 Jul 2008 08:05:46 -0700 (PDT) Received: by 10.142.161.15 with HTTP; Mon, 7 Jul 2008 08:05:46 -0700 (PDT) Message-ID: <4c5c7a6d0807070805v106ed03fpd319c656abc1e964@mail.gmail.com> Date: Mon, 7 Jul 2008 23:05:46 +0800 From: "Peny Yang" To: "Yoav Nir" In-Reply-To: <403C9D3A-5D1B-43B6-91CF-078C7F209136@checkpoint.com> MIME-Version: 1.0 Content-Disposition: inline References: <029d01c8e00e$203b99c0$2302600a@hitachichina.com> <4c5c7a6d0807070205v484436c5y3b5ab836a7175f67@mail.gmail.com> <403C9D3A-5D1B-43B6-91CF-078C7F209136@checkpoint.com> Cc: ipsec@ietf.org, paul.hoffman@vpnc.org Subject: Re: [IPsec] Fwd: FW: I-D Action:draft-xu-ike-sa-sync-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, Yoav: Firstly, thanks a lot for your comments. Please check my words in-line below: > Looks like we have a lot of drafts lately dealing with crash recovery: > IFARE, QCD, SIR, and now yours (in chronological order). > > Specifically, it looks like your proposal is competing with the IFARE > proposal: > http://www.ietf.org/internet-drafts/draft-sheffer-ipsec-failover-03.txt [Peny] Well, considering problem of the IPsec failover, some operator may need a stateful network-centric solution. > You may want to post to the list some cons/pros of your proposal vs > ipsec-failover. [Peny] Just as I mentioned above, this solution is about a stateful network-centric one to solve the problem of IPsec failover. Especially when we consider the possibility that the IPsec client may be cracked, our solution can be an useful alternative for operators. It only incurs a very small extension on the base IKEv2 protocol. And, I agree that our solution may need to be improved for the cases when the mobile IPsec client does the IKE SYNC during handover. But, such kind of cases are quite unusual. We will make the improvement in the following updates. > Specific comments about the draft: > - I think you should add a specific description about how keys are derived > with a successful stub lookup > - I think you should remove the text that deals with internal structure > (and the use of STL). We only need to know what the gateway should be able > to look up > - I'm not sure I understand section 3.6. I understand the format of the > SYN payload, but I don't get the stub-related signaling. Are you specifying > the signaling protocol between the gateways, or is that left as a local > matter? Is interoperability between different vendor's gateways a goal of > this specification? [Peny] Thank you very much for your comments. We will update our draft based on your comments within next week. Thank you again for your help. BRG Peny > > On Jul 7, 2008, at 12:05 PM, Peny Yang wrote: > > > > > Hi, folks: > > > > We have submitted the draft on IKEv2 SA synchronization. Please check it. > > Comments are more than welcome. > > > > And, if possible, I would like to apply for a slot to present our work > > in the incoming IPsec WG meeting in Dublin. > > > > Thanks a lot > > BRG > > Peny > > > > > > > > > > > > > > > -----Original Message----- > > > > From: i-d-announce-bounces@ietf.org > > > > > > > > > [mailto:i-d-announce-bounces@ietf.org] > > > > > > > > > On Behalf Of Internet-Drafts@ietf.org > > > > Sent: Monday, July 07, 2008 4:30 PM > > > > To: i-d-announce@ietf.org > > > > Subject: I-D Action:draft-xu-ike-sa-sync-00.txt > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > > directories. > > > > > > > > Title : IKE SA Synchronization > > > > Author(s) : Y. Xu, et al. > > > > Filename : draft-xu-ike-sa-sync-00.txt > > > > Pages : 17 > > > > Date : 2008-07-07 > > > > > > > > It will take a long time to do security association syncronization > > > > among IKE/IPsec gateways possibly maintaining huge numbers of IKEv2/ > > > > IPsec SAs. The major reason is that the prcocedure of IKEv2 SA re- > > > > establishment will incur a time-consuming computation especially in > > > > the Diffie-Hellman exchange. In this draft, a new IKE security > > > > associations synchronization solution is proposed to reduce the > > > > computation by directly transferring the indexed IKE SA from old > > > > gateway to new gateway, wherein the most expensive Diffie-Hellman > > > > calculation can be avoided. Without some time-consuming IKEv2 > > > > exchanges, the huge amount of IKE/IPsec SA synchronization procedures > > > > can be finished in a short time. > > > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-xu-ike-sa-sync-00.txt > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > Below is the data which will enable a MIME compliant mail reader > > > > implementation to automatically retrieve the ASCII version of the > > > > Internet-Draft. > > > > > > > > > > > > > Scanned by Check Point Total Security Gateway. > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 7 08:13:24 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2EEC3A69F9; Mon, 7 Jul 2008 08:13:24 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCBEA3A69EC for ; Mon, 7 Jul 2008 08:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtUlI6vzAV+E for ; Mon, 7 Jul 2008 08:13:23 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id BE8D33A69BC for ; Mon, 7 Jul 2008 08:13:22 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so385618yxg.49 for ; Mon, 07 Jul 2008 08:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=MEESzlidGlBh1erDpWxMhU8s9beu2UZUXqApgiVeCvM=; b=YMths3/y3RHNHohs+eYlG/LU7dlnSVxRGwPJepfThS+d0v5FQxnq5MQOyEyw5WWjeP faZf9bPiOO40/PBN31uChffYJkxvOYZReEAJESExN6s8cB5yMHSaCMsEKdoWNjDQLOOX 9ayuej0UpSZXfSjkoj4GnhzSg77wocb8lTTpM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=GIpREMYviU8T9QgXfpX/DqRpk/CwLIm97pL5yCpE0YlX8ab3g3cSn/kzp65T0KdKZ6 Sb3nXhRa0+2FBmEDap7hGf3/P5kvCXgmtXSaTq4JrWBobZ2BFHnfWMYTo+A8W/FvI++g usjgpV3tLbmqJ5wuriyNSlDqRmy47dfgQzy+0= Received: by 10.142.14.20 with SMTP id 20mr1343667wfn.149.1215443608195; Mon, 07 Jul 2008 08:13:28 -0700 (PDT) Received: by 10.142.161.15 with HTTP; Mon, 7 Jul 2008 08:13:28 -0700 (PDT) Message-ID: <4c5c7a6d0807070813i5ce199a9w144336e1e60df1f3@mail.gmail.com> Date: Mon, 7 Jul 2008 23:13:28 +0800 From: "Peny Yang" To: "Yaron Sheffer" In-Reply-To: <487211E6.2060607@checkpoint.com> MIME-Version: 1.0 Content-Disposition: inline References: <029d01c8e00e$203b99c0$2302600a@hitachichina.com> <4c5c7a6d0807070205v484436c5y3b5ab836a7175f67@mail.gmail.com> <487211E6.2060607@checkpoint.com> Cc: ipsec@ietf.org, paul.hoffman@vpnc.org Subject: Re: [IPsec] Fwd: FW: I-D Action:draft-xu-ike-sa-sync-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, Yaron: > thanks for your submission. Please note that while session resumption is on > the ipsecme charter, failover from one gateway to another is explicitly > outside the charter. [Peny] Thanks a lot for your comments. As many people in this list are interested in this topic and some drafts are posted like "IPsec GW failover" and my draft, will you please kindly help us to open a related discussion for IPsec failover? > The agenda for Dublin is likely to be busy; we will make an effort to > accommodate short presentations of IPsec-related drafts, even when they > don't strictly fall within the charter. [Peny] Thank you very much for your arrangement. :) BRG Peny > > > > > > > > > > Peny Yang wrote: > > Hi, folks: We have submitted the draft on IKEv2 SA synchronization. Please > check it. Comments are more than welcome. And, if possible, I would like to > apply for a slot to present our work in the incoming IPsec WG meeting in > Dublin. Thanks a lot BRG Peny > > -----Original Message----- From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] > > On Behalf Of Internet-Drafts@ietf.org Sent: Monday, July 07, 2008 4:30 > PM To: i-d-announce@ietf.org Subject: I-D > Action:draft-xu-ike-sa-sync-00.txt A New Internet-Draft is > available from the on-line Internet-Drafts directories. Title : IKE SA > Synchronization Author(s) : Y. Xu, et al. Filename : > draft-xu-ike-sa-sync-00.txt Pages : 17 Date : 2008-07-07 It will take a > long time to do security association syncronization among IKE/IPsec gateways > possibly maintaining huge numbers of IKEv2/ IPsec SAs. The major reason is > that the prcocedure of IKEv2 SA re- establishment will incur a > time-consuming computation especially in the Diffie-Hellman exchange. In > this draft, a new IKE security associations synchronization solution is > proposed to reduce the computation by directly transferring the indexed IKE > SA from old gateway to new gateway, wherein the most expensive > Diffie-Hellman calculation can be avoided. Without some time-consuming > IKEv2 exchanges, the huge amount of IKE/IPsec SA synchronization > procedures can be finished in a short time. A URL for this Internet-Draft > is: http://www.ietf.org/internet-drafts/draft-xu-ike-sa-sync-00.txt Internet-Drafts > are also available by anonymous FTP > at: ftp://ftp.ietf.org/internet-drafts/ Below is the data > which will enable a MIME compliant mail reader implementation to > automatically retrieve the ASCII version of the Internet-Draft. > Scanned by Check Point Total Security Gateway. > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 7 12:03:23 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E98828C0F9; Mon, 7 Jul 2008 12:03:23 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755EB28C0F9 for ; Mon, 7 Jul 2008 12:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtDZIIREFIIF for ; Mon, 7 Jul 2008 12:03:21 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id ACCCB3A6B0B for ; Mon, 7 Jul 2008 12:02:57 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id ECE75294003; Mon, 7 Jul 2008 22:03:03 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A9113294002 for ; Mon, 7 Jul 2008 22:03:02 +0300 (IDT) Received: from [172.16.10.230] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m67J2rjI022908 for ; Mon, 7 Jul 2008 22:03:02 +0300 (IDT) Message-ID: <4872685D.40007@checkpoint.com> Date: Mon, 07 Jul 2008 22:02:53 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: ipsec@ietf.org Subject: [IPsec] Proposed ipsecme agenda for Dublin X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Here is the proposed agenda that Paul and I came up with. Please review and comment. Also, if you have additional topics that are out of scope for the WG and you want to discuss, please let us know as soon as possible. - Welcome and WG overview (chairs) - 15 mins Quick charter review What is in and out of scope Review of when things can be added to the charter - IKEv2bis status (Paul Hoffman) - 15 mins Refresh status List open issues Request an additional author who is an IKEv2 implementer - Roadmap document (chairs) - 10 mins Review what is in the charter Ask for additional ideas Ask for volunteers for an editor - IKEv2 IPv6 config status (Pasi Eronen) - 20 mins Describe why it's needed Discuss different approaches Request for additional author who is an IKEv2 and IPv6 implementer - IKE session resumption status (Yaron Sheffer) - 10 mins What is and is not in scope from the charter Very brief overview of the proposed solution - IKE redirect status (Vijay Devarapalli) - 10 mins What is and is not in scope from the charter Very brief overview of the proposed solution - Short presentations on out-of-scope-for-the-WG documents - 40 minutes 5 minutes for each item, and three slides max (title, overview, where it is being discussed). Planned so far: -- IPsec benchmarking (Merike Kaeo) -- ESP-null visibility (possibly two different approaches) -- GRE traffic selectors -- Quick crash detection -- EAP-GTC - Open mic on items from the charter - Open mic on non-charter items - Wrap-up (chairs) - 5 mins What will happen on the list Milestones for the rest of the year _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 7 12:26:14 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DC813A6ADB; Mon, 7 Jul 2008 12:26:14 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E1B03A67F7 for ; Mon, 7 Jul 2008 12:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMC2efCmr7t1 for ; Mon, 7 Jul 2008 12:26:12 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 877473A6AE3 for ; Mon, 7 Jul 2008 12:26:01 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 03284294002; Mon, 7 Jul 2008 22:26:07 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 4CB0D294001 for ; Mon, 7 Jul 2008 22:24:14 +0300 (IDT) Received: from [172.16.10.230] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m67JODjI000458 for ; Mon, 7 Jul 2008 22:24:13 +0300 (IDT) Message-ID: <48726D5F.7080706@checkpoint.com> Date: Mon, 07 Jul 2008 22:24:15 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: ipsec@ietf.org Subject: [IPsec] Proposed document list for ipsecme X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, the following list attempts to cover the working group's charter. Please review and comment. o A revision to IKEv2 (RFC 4306) that incorporates the clarifications from RFC 4718, and otherwise improves the quality of the specification, taking into account implementation and interoperability experience. Proposed filename: draft-ietf-ipsecme-ikev2bis Proposed authors: Charlie Kaufman, Paul Hoffman, plus one implementer o An IPsec document roadmap that describes the various RFC documents covering IPsec, including both the core RFC 240x and RFC 430x versions of IPsec, and extensions specified in other documents. Proposed filename: draft-ietf-ipsecme-roadmap Proposed editor(s): one or two volunteers o A standards-track extension to IKEv2 that provides full IPv6 support for IPsec remote access clients that use configuration payloads. Proposed filename: draft-ietf-ipsecme-ikev2-ipv6-config Proposed authors: Pasi Eronen, plus one implementer o A standards-track extension that allows an IPsec remote access client to "resume" a session with a gateway; that is, to skip certain parts of IKE negotation when connecting again to the same gateway (or possibly a cluster of closely cooperating gateways). Proposed filename: draft-ietf-ipsecme-resumption Proposed authors: Authors of draft-sheffer-ipsec-failover-03.txt o A standards-track extension to IPsec that allows an IPsec remote access gateway to redirect VPN clients to another gateway. Proposed filename: draft-ietf-ipsecme-ikev2-redirect Proposed authors: Authors of draft-devarapalli-ipsec-ikev2-redirect-00.txt Note that the session resumption draft and the redirection drafts might be merged into a single draft if it makes technical sense. Paul & Yaron _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 7 12:37:28 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B6613A6B07; Mon, 7 Jul 2008 12:37:28 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E95FF3A6B05 for ; Mon, 7 Jul 2008 12:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWmO6yWPfUSn for ; Mon, 7 Jul 2008 12:37:26 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8F05E3A6B02 for ; Mon, 7 Jul 2008 12:37:25 -0700 (PDT) Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67JbRJ6051515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 12:37:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4c5c7a6d0807070813i5ce199a9w144336e1e60df1f3@mail.gmail.com> References: <029d01c8e00e$203b99c0$2302600a@hitachichina.com> <4c5c7a6d0807070205v484436c5y3b5ab836a7175f67@mail.gmail.com> <487211E6.2060607@checkpoint.com> <4c5c7a6d0807070813i5ce199a9w144336e1e60df1f3@mail.gmail.com> Date: Mon, 7 Jul 2008 12:37:25 -0700 To: "Peny Yang" From: Paul Hoffman Cc: ipsec@ietf.org Subject: Re: [IPsec] Fwd: FW: I-D Action:draft-xu-ike-sa-sync-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 11:13 PM +0800 7/7/08, Peny Yang wrote: > As many people in this list are >interested in this topic and some drafts are posted like "IPsec GW >failover" and my draft, will you please kindly help us to open a >related discussion for IPsec failover? We cannot start such a WG discussion until one of our other charter items is finished. Our charter is completely clear on this topic. Once we finish one of the items in our charter, the WG can hopefully come to consensus about the next item of future work. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jul 8 09:30:12 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A07D3A6A76; Tue, 8 Jul 2008 09:30:12 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15A4528C122 for ; Mon, 7 Jul 2008 12:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s++9Z5mb0svx for ; Mon, 7 Jul 2008 12:35:38 -0700 (PDT) Received: from web81907.mail.mud.yahoo.com (web81907.mail.mud.yahoo.com [68.142.207.186]) by core3.amsl.com (Postfix) with SMTP id 0F8773A6983 for ; Mon, 7 Jul 2008 12:35:38 -0700 (PDT) Received: (qmail 76106 invoked by uid 60001); 7 Jul 2008 19:35:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=F8wPmW4DZFDRR7q1W/qpIL0Q9k9MXCLaNNvo48yEr++kAU+48hYMW6dnL98oQUQ0ET/tNDSupAURIt/BaUTfpmrMz/g4CipnLnDL9hW2rYB2Fr8i6U7Dl4DZXpJgcQsxwuGOqkEsq3BEKnI6Nv7T+fhD8RAivbWHYONzjFRmd40=; Received: from [131.107.0.103] by web81907.mail.mud.yahoo.com via HTTP; Mon, 07 Jul 2008 12:35:41 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.199 Date: Mon, 7 Jul 2008 12:35:41 -0700 (PDT) From: gabriel montenegro To: Yaron Sheffer , ipsec@ietf.org MIME-Version: 1.0 Message-ID: <224918.75976.qm@web81907.mail.mud.yahoo.com> X-Mailman-Approved-At: Tue, 08 Jul 2008 09:30:10 -0700 Subject: Re: [IPsec] Proposed document list for ipsecme X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2039100690==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============2039100690== Content-Type: multipart/alternative; boundary="0-865970690-1215459341=:75976" --0-865970690-1215459341=:75976 Content-Type: text/plain; charset=us-ascii What about the ESP visibility deliverable? Did this get dropped? ----- Original Message ---- From: Yaron Sheffer To: ipsec@ietf.org Sent: Monday, July 7, 2008 12:24:15 PM Subject: [IPsec] Proposed document list for ipsecme Hi, the following list attempts to cover the working group's charter. Please review and comment. o A revision to IKEv2 (RFC 4306) that incorporates the clarifications from RFC 4718, and otherwise improves the quality of the specification, taking into account implementation and interoperability experience. Proposed filename: draft-ietf-ipsecme-ikev2bis Proposed authors: Charlie Kaufman, Paul Hoffman, plus one implementer o An IPsec document roadmap that describes the various RFC documents covering IPsec, including both the core RFC 240x and RFC 430x versions of IPsec, and extensions specified in other documents. Proposed filename: draft-ietf-ipsecme-roadmap Proposed editor(s): one or two volunteers o A standards-track extension to IKEv2 that provides full IPv6 support for IPsec remote access clients that use configuration payloads. Proposed filename: draft-ietf-ipsecme-ikev2-ipv6-config Proposed authors: Pasi Eronen, plus one implementer o A standards-track extension that allows an IPsec remote access client to "resume" a session with a gateway; that is, to skip certain parts of IKE negotation when connecting again to the same gateway (or possibly a cluster of closely cooperating gateways). Proposed filename: draft-ietf-ipsecme-resumption Proposed authors: Authors of draft-sheffer-ipsec-failover-03.txt o A standards-track extension to IPsec that allows an IPsec remote access gateway to redirect VPN clients to another gateway. Proposed filename: draft-ietf-ipsecme-ikev2-redirect Proposed authors: Authors of draft-devarapalli-ipsec-ikev2-redirect-00.txt Note that the session resumption draft and the redirection drafts might be merged into a single draft if it makes technical sense. Paul & Yaron _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --0-865970690-1215459341=:75976 Content-Type: text/html; charset=us-ascii
What about the ESP visibility deliverable? Did this get dropped?

----- Original Message ----
From: Yaron Sheffer <yaronf@checkpoint.com>
To: ipsec@ietf.org
Sent: Monday, July 7, 2008 12:24:15 PM
Subject: [IPsec] Proposed document list for ipsecme

Hi,

the following list attempts to cover the working group's charter. Please
review and comment.

o A revision to IKEv2 (RFC 4306) that incorporates the clarifications
from RFC 4718, and otherwise improves the quality of the specification,
taking into account implementation and interoperability experience.
Proposed filename: draft-ietf-ipsecme-ikev2bis
Proposed authors: Charlie Kaufman, Paul Hoffman, plus one implementer

o An IPsec document roadmap that describes the various RFC documents
covering IPsec, including both the core RFC 240x and RFC 430x versions
of IPsec, and extensions specified in other documents.
Proposed filename: draft-ietf-ipsecme-roadmap
Proposed editor(s): one or two volunteers

o A standards-track extension to IKEv2 that provides full IPv6 support
for IPsec remote access clients that use configuration payloads.
Proposed filename: draft-ietf-ipsecme-ikev2-ipv6-config
Proposed authors: Pasi Eronen, plus one implementer

o A standards-track extension that allows an IPsec remote access client
to "resume" a session with a gateway; that is, to skip certain parts of
IKE negotation when connecting again to the same gateway (or possibly a
cluster of closely cooperating gateways).
Proposed filename: draft-ietf-ipsecme-resumption
Proposed authors: Authors of draft-sheffer-ipsec-failover-03.txt

o A standards-track extension to IPsec that allows an IPsec remote
access gateway to redirect VPN clients to another gateway.
Proposed filename: draft-ietf-ipsecme-ikev2-redirect
Proposed authors: Authors of draft-devarapalli-ipsec-ikev2-redirect-00.txt

Note that the session resumption draft and the redirection drafts might
be merged into a single draft if it makes technical sense.

Paul & Yaron
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--0-865970690-1215459341=:75976-- --===============2039100690== 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://www.ietf.org/mailman/listinfo/ipsec --===============2039100690==-- From ipsec-bounces@ietf.org Tue Jul 8 11:09:12 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A68883A6A98; Tue, 8 Jul 2008 11:09:12 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8606B3A6A9F for ; Tue, 8 Jul 2008 11:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R72Ydk61neha for ; Tue, 8 Jul 2008 11:09:10 -0700 (PDT) Received: from web81901.mail.mud.yahoo.com (web81901.mail.mud.yahoo.com [68.142.207.180]) by core3.amsl.com (Postfix) with SMTP id 677CF3A6A98 for ; Tue, 8 Jul 2008 11:09:10 -0700 (PDT) Received: (qmail 168 invoked by uid 60001); 8 Jul 2008 18:09:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=Nv5K2ZZ7EAOrfXLUQ0NuKSjCZQCy4y8dh6HkSkuYxxEKXY2FwNSX9NTq/LONsbIe1cPa+k15J2fXBRMnRJYSaYVf50DkIcKQTLzaS2c+PhMmKLQoObm1EYl7PKL5yadok0kcplAMdFk1whkkffsuOQj/8qsUTrN2mN94aSregaA=; Received: from [131.107.0.103] by web81901.mail.mud.yahoo.com via HTTP; Tue, 08 Jul 2008 11:09:00 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.199 Date: Tue, 8 Jul 2008 11:09:00 -0700 (PDT) From: gabriel montenegro To: Yaron Sheffer , ipsec@ietf.org MIME-Version: 1.0 Message-ID: <913091.99691.qm@web81901.mail.mud.yahoo.com> Subject: Re: [IPsec] Proposed document list for ipsecme X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org To answer my own question: it was not dropped, this was just an oversight. As confirmed by the IESG via separate email, the ESP visibility item is indeed in the approved charter. ----- Original Message ---- From: gabriel montenegro To: Yaron Sheffer ; ipsec@ietf.org Sent: Monday, July 7, 2008 12:35:41 PM Subject: Re: [IPsec] Proposed document list for ipsecme What about the ESP visibility deliverable? Did this get dropped? ----- Original Message ---- From: Yaron Sheffer To: ipsec@ietf.org Sent: Monday, July 7, 2008 12:24:15 PM Subject: [IPsec] Proposed document list for ipsecme Hi, the following list attempts to cover the working group's charter. Please review and comment. o A revision to IKEv2 (RFC 4306) that incorporates the clarifications from RFC 4718, and otherwise improves the quality of the specification, taking into account implementation and interoperability experience. Proposed filename: draft-ietf-ipsecme-ikev2bis Proposed authors: Charlie Kaufman, Paul Hoffman, plus one implementer o An IPsec document roadmap that describes the various RFC documents covering IPsec, including both the core RFC 240x and RFC 430x versions of IPsec, and extensions specified in other documents. Proposed filename: draft-ietf-ipsecme-roadmap Proposed editor(s): one or two volunteers o A standards-track extension to IKEv2 that provides full IPv6 support for IPsec remote access clients that use configuration payloads. Proposed filename: draft-ietf-ipsecme-ikev2-ipv6-config Proposed authors: Pasi Eronen, plus one implementer o A standards-track extension that allows an IPsec remote access client to "resume" a session with a gateway; that is, to skip certain parts of IKE negotation when connecting again to the same gateway (or possibly a cluster of closely cooperating gateways). Proposed filename: draft-ietf-ipsecme-resumption Proposed authors: Authors of draft-sheffer-ipsec-failover-03.txt o A standards-track extension to IPsec that allows an IPsec remote access gateway to redirect VPN clients to another gateway. Proposed filename: draft-ietf-ipsecme-ikev2-redirect Proposed authors: Authors of draft-devarapalli-ipsec-ikev2-redirect-00.txt Note that the session resumption draft and the redirection drafts might be merged into a single draft if it makes technical sense. Paul & Yaron _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jul 8 11:15:23 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA3E528C214; Tue, 8 Jul 2008 11:15:23 -0700 (PDT) X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 0F9AA3A69CE; Tue, 8 Jul 2008 11:07:31 -0700 (PDT) From: The IESG To: ietf-announce@ietf.org Mime-Version: 1.0 Message-Id: <20080708180732.0F9AA3A69CE@core3.amsl.com> Date: Tue, 8 Jul 2008 11:07:32 -0700 (PDT) X-Mailman-Approved-At: Tue, 08 Jul 2008 11:15:22 -0700 Cc: ipsec@ietf.org, paul.hoffman@vpnc.org Subject: [IPsec] WG Action: IP Security Maintenance and Extensions (ipsecme) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org A new IETF working group has been formed in the Security Area. For additional information, please contact the Area Directors or the WG Chairs. IP Security Maintenance and Extensions (ipsecme) --------------------------------------------------- Last Modified: June 19, 2008 Current Status: Active Working Group Chairs: Paul Hoffman (paul.hoffman@vpnc.org) Yaron Sheffer (yaronf@checkpoint.com) Security Area Directors: Pasi Eronen (pasi.eronen@nokia.com) Tim Polk (tim.polk@nist.gov) Security Area Advisor: Pasi Eronen (pasi.eronen@nokia.com) Mailing Lists: General Discussion: ipsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: http://www.ietf.org/mail-archive/web/ipsec/ Description of Working Group: The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group will continue the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions and improvements to IPsec, mostly to IKEv2. The working group will also be a focus point for other IETF Working Groups who use IPsec in their own protocols. The initial set of work items is: - A revision to IKEv2 (RFC 4306) that incorporates the clarifications from RFC 4718, and otherwise improves the quality of the specification, taking into account implementation and interoperability experience. In some cases, the revision may include small technical corrections; however, impact on existing implementations must be considered. Major changes and adding new features is beyond the scope of this work item. The starting point for this work is draft-hoffman-ikev2bis. - An IPsec document roadmap that describes the various RFC documents covering IPsec, including both the core RFC 240x and RFC 430x versions of IPsec, and extensions specified in other documents. Sections 2 and 3 of RFC 2411 can provide useful material, but the expected scope is slightly different from RFC 2411. This document will be informational. - A standards-track extension to IKEv2 that provides full IPv6 support for IPsec remote access clients that use configuration payloads. This work will be based on draft-eronen-ipsec-ikev2-ipv6-config. The WG shall solicit help and reviews from the 6MAN WG to ensure that all aspects of IPv6 are properly considered. - A standards-track extension that allows an IPsec remote access client to "resume" a session with a gateway; that is, to skip certain parts of IKE negotation when connecting again to the same gateway (or possibly a cluster of closely cooperating gateways). The idea is similar to TLS session resumption without server-side state, specified in RFC 5077. The main goals for this extension are to avoid public-key computations (to reduce VPN gateway load when a large number of clients reconnect to the geteway within a short period of time, such as following a network outage), and remove the need for user interaction for authentication (which may be required by some authentication mechanisms). The extension shall not have negative impact on IKEv2 security features. Failover from one gateway to another, mechanisms for detecting when a session should be resumed, and specifying communication mechanisms between gateways are beyond the scope of this work item. Specifying the detailed contents of the "session ticket" is also beyond the scope of this document; if there is sufficient interest, this could be specified later in a separate document. To the degree its content falls within the scope of this work item, text and ideas from draft-sheffer-ipsec-failover will be used as a starting point. - A standards-track extension to IPsec that allows an IPsec remote access gateway to redirect VPN clients to another gateway. This extension should be aligned with the session resumption extension, (the previous work item), and if so decided by the WG, could be specified in the same document. The starting point will be draft-devarapalli-ipsec-ikev2-redirect. - A standards-track mechanism that allows an intermediary device, such as a firewall or intrusion detection system, to easily and reliably determine whether an ESP packet is encrypted with the NULL cipher; and if it is, determine the location of the actual payload data inside the packet. The starting points for this work item are draft-grewal-ipsec-traffic-visibility and draft-hoffman- esp-null-protocol. The initial scope of the WG is restricted to the work items listed above. The WG shall not consider adding new work items until one or more of its documents progress to IESG evaluation. At that time, the WG can propose rechartering. Chartering this WG is not intended to have effect on documents that beyond the initial scope. In particular, work on IPsec extensions that are not included in this charter can happen as usual in other WGs (and there are currently several other WGs working on IPsec extensions; for example, BTNS and ROHC), or as individual submissions. This charter will expire in July 2010 (24 months from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Goals and Milestones: Dec 2008 WG last call on IPv6 configuration payloads Dec 2008 WG last call on IPsec roadmap Jan 2009 WG last call on session resumption Feb 2009 WG last call on redirect Mar 2009 WG last call on IKEv2bis Apr 2009 WG last call on ESP NULL traffic visibility _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jul 8 12:13:23 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26A4928C25D; Tue, 8 Jul 2008 12:13:23 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 154DD28C217 for ; Tue, 8 Jul 2008 12:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqtiEins-gob for ; Tue, 8 Jul 2008 12:13:21 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 9ADE328C25D for ; Tue, 8 Jul 2008 12:13:20 -0700 (PDT) Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m68JDRYR075907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Jul 2008 12:13:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4872685D.40007@checkpoint.com> References: <4872685D.40007@checkpoint.com> Date: Tue, 8 Jul 2008 12:10:39 -0700 To: ipsec@ietf.org From: Paul Hoffman Subject: Re: [IPsec] Proposed ipsecme agenda for Dublin X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org There are a few changes here. We moved the ESP-null discussion into the main body because we now know that it is in the charter. We also added a few of the short presentations that people have already asked for. Please comment. - Welcome and WG overview (chairs) - 15 mins Quick charter review What is in and out of scope Review of when things can be added to the charter - IKEv2bis status (Paul Hoffman) - 15 mins Refresh status List open issues Request an additional author who is an IKEv2 implementer - Roadmap document (chairs) - 10 mins Review what is in the charter Ask for additional ideas Ask for volunteers for an editor - IKEv2 IPv6 config status (Pasi Eronen) - 20 mins Describe why it's needed Discuss different approaches Request for additional author who is an IKEv2 and IPv6 implementer - IKE session resumption status (Yaron Sheffer) - 10 mins What is and is not in scope from the charter Very brief overview of the proposed solution - IKE redirect status (Vijay Devarapalli) - 10 mins What is and is not in scope from the charter Very brief overview of the proposed solution - ESP-null visibility (Gabriel Montenegro) - 15 mins Why this is desired Overview of multiple proposals - Short presentations on out-of-scope-for-the-WG documents - 40 minutes 5 minutes for each item, and three slides max (title, overview, where it is being discussed). Planned so far: -- IKEv2 testing activity at TAHI (Yukiyo Akisada) -- IPsec benchmarking (Merike Kaeo) -- GRE traffic selectors (Hui Deng) -- Quick crash detection (Yoav Nir) -- EAP-GTC (Yaron Sheffer) - Open mic on items from the charter - Open mic on non-charter items - Wrap-up (chairs) - 5 mins What will happen on the list Milestones for the rest of the year _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jul 8 12:16:15 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 873373A6839; Tue, 8 Jul 2008 12:16:15 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B679B28C25C for ; Tue, 8 Jul 2008 12:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yw3v2Pevj9Zh for ; Tue, 8 Jul 2008 12:16:13 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 58B563A6811 for ; Tue, 8 Jul 2008 12:16:13 -0700 (PDT) Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m68JDRYT075907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Jul 2008 12:13:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <48726D5F.7080706@checkpoint.com> References: <48726D5F.7080706@checkpoint.com> Date: Tue, 8 Jul 2008 12:13:23 -0700 To: ipsec@ietf.org From: Paul Hoffman Subject: Re: [IPsec] Proposed document list for ipsecme X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Updated to add the ESP-null work The following list attempts to cover the working group's charter. Please review and comment. o A revision to IKEv2 (RFC 4306) that incorporates the clarifications from RFC 4718, and otherwise improves the quality of the specification, taking into account implementation and interoperability experience. Proposed filename: draft-ietf-ipsecme-ikev2bis Proposed authors: Charlie Kaufman, Paul Hoffman, plus one implementer o An IPsec document roadmap that describes the various RFC documents covering IPsec, including both the core RFC 240x and RFC 430x versions of IPsec, and extensions specified in other documents. Proposed filename: draft-ietf-ipsecme-roadmap Proposed editor(s): one or two volunteers o A standards-track extension to IKEv2 that provides full IPv6 support for IPsec remote access clients that use configuration payloads. Proposed filename: draft-ietf-ipsecme-ikev2-ipv6-config Proposed authors: Pasi Eronen, plus one implementer o A standards-track extension that allows an IPsec remote access client to "resume" a session with a gateway; that is, to skip certain parts of IKE negotation when connecting again to the same gateway (or possibly a cluster of closely cooperating gateways). Proposed filename: draft-ietf-ipsecme-resumption Proposed authors: Authors of draft-sheffer-ipsec-failover-03.txt o A standards-track extension to IPsec that allows an IPsec remote access gateway to redirect VPN clients to another gateway. Proposed filename: draft-ietf-ipsecme-ikev2-redirect Proposed authors: Authors of draft-devarapalli-ipsec-ikev2-redirect-00.txt o A standards-track mechanism that allows an intermediary device, such as a firewall or intrusion detection system, to easily and reliably determine whether an ESP packet is encrypted with the NULL cipher; and if it is, determine the location of the actual payload data inside the packet. Proposed filename: draft-ietf-ipsecme-esp-null Proposed authors: Authors of draft-grewal-ipsec-traffic-visibility-01.txt Note that the session resumption draft and the redirection drafts might be merged into a single draft if it makes technical sense. Paul & Yaron _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jul 9 07:51:24 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 254303A6950; Wed, 9 Jul 2008 07:51:24 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 099423A6853 for ; Wed, 9 Jul 2008 07:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEdjQS6grSWp for ; Wed, 9 Jul 2008 07:51:21 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 6EFF928C124 for ; Wed, 9 Jul 2008 07:51:21 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id BFCD3294011; Wed, 9 Jul 2008 17:51:29 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7442C29400F; Wed, 9 Jul 2008 17:51:28 +0300 (IDT) Received: from [91.90.139.89] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m69EpRjI001416; Wed, 9 Jul 2008 17:51:28 +0300 (IDT) Message-ID: <4874D07C.8000807@checkpoint.com> Date: Wed, 09 Jul 2008 17:51:40 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Peny Yang References: <029d01c8e00e$203b99c0$2302600a@hitachichina.com> <4c5c7a6d0807070205v484436c5y3b5ab836a7175f67@mail.gmail.com> In-Reply-To: <4c5c7a6d0807070205v484436c5y3b5ab836a7175f67@mail.gmail.com> Cc: ipsec@ietf.org, paul.hoffman@vpnc.org Subject: Re: [IPsec] Fwd: FW: I-D Action:draft-xu-ike-sa-sync-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0008342570==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0008342570== Content-Type: multipart/alternative; boundary="------------010301040105010806000909" This is a multi-part message in MIME format. --------------010301040105010806000909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Peny, first, let me note that I'm a coauthor of draft-sheffer-ipsec-failover-03, which covers similar ground. Also, I am making the following comments irrespective of the current group's charter. I am commenting on the actual content of the draft, rather than its fit with the ipsecme charter. - The problem you are trying to solve is in my opinion very valid, and is described very well in the "scenarios" section. - "Stub" is not a common name for what you are proposing. Some names I can think of are "ticket", "token" or even "blob". There are surely others. - In general, the document expands too much on implementation issues, and too little on the essential protocol issues. To illustrate the first point, you mention a very specific implementation of a "map" data structure. So specific that it wouldn't apply to Java code. - Similarly, Sec. 3.4 (although interesting) is very much out of scope. Implementers can choose many ways to maintain and distribute the stubs. We are mainly interested in the interoperable protocol, i.e. that between client and gateway. - What I am missing is how the stub is acquired by the client, and possibly how it is updated. In fact the only example of an IKE exchange is that of *using* the stub. In addition, I couldn't find any mention of how the stub is protected (encrypted/authenticated) or even that it is protected at all. - It is also unclear to me how the proposed protocol protects against replay of the stub, to create multiple IKE SAs and eventually DOS the gateway. Thanks, Yaron Peny Yang wrote: > Hi, folks: > > We have submitted the draft on IKEv2 SA synchronization. Please check it. > Comments are more than welcome. > > And, if possible, I would like to apply for a slot to present our work > in the incoming IPsec WG meeting in Dublin. > > Thanks a lot > BRG > Peny > > > > >>> -----Original Message----- >>> From: i-d-announce-bounces@ietf.org >>> > [mailto:i-d-announce-bounces@ietf.org] > >>> On Behalf Of Internet-Drafts@ietf.org >>> Sent: Monday, July 07, 2008 4:30 PM >>> To: i-d-announce@ietf.org >>> Subject: I-D Action:draft-xu-ike-sa-sync-00.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : IKE SA Synchronization >>> Author(s) : Y. Xu, et al. >>> Filename : draft-xu-ike-sa-sync-00.txt >>> Pages : 17 >>> Date : 2008-07-07 >>> >>> It will take a long time to do security association syncronization >>> among IKE/IPsec gateways possibly maintaining huge numbers of IKEv2/ >>> IPsec SAs. The major reason is that the prcocedure of IKEv2 SA re- >>> establishment will incur a time-consuming computation especially in >>> the Diffie-Hellman exchange. In this draft, a new IKE security >>> associations synchronization solution is proposed to reduce the >>> computation by directly transferring the indexed IKE SA from old >>> gateway to new gateway, wherein the most expensive Diffie-Hellman >>> calculation can be avoided. Without some time-consuming IKEv2 >>> exchanges, the huge amount of IKE/IPsec SA synchronization procedures >>> can be finished in a short time. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-xu-ike-sa-sync-00.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> > > > Scanned by Check Point Total Security Gateway. > --------------010301040105010806000909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hi Peny,

first, let me note that I'm a coauthor of draft-sheffer-ipsec-failover-03, which covers similar ground. Also, I am making the following comments irrespective of the current group's charter. I am commenting on the actual content of the draft, rather than its fit with the ipsecme charter.

- The problem you are trying to solve is in my opinion very valid, and is described very well in the "scenarios" section.
- "Stub" is not a common name for what you are proposing. Some names I can think of are "ticket", "token" or even "blob". There are surely others.
- In general, the document expands too much on implementation issues, and too little on the essential protocol issues. To illustrate the first point, you mention a very specific implementation of a "map" data structure. So specific that it wouldn't apply to Java code.
- Similarly, Sec. 3.4 (although interesting) is very much out of scope. Implementers can choose many ways to maintain and distribute the stubs. We are mainly interested in the interoperable protocol, i.e. that between client and gateway.
- What I am missing is how the stub is acquired by the client, and possibly how it is updated. In fact the only example of an IKE exchange is that of *using* the stub. In addition, I couldn't find any mention of how the stub is protected (encrypted/authenticated) or even that it is protected at all.
- It is also unclear to me how the proposed protocol protects against replay of the stub, to create multiple IKE SAs and eventually DOS the gateway.

Thanks,
    Yaron




Peny Yang wrote:

Hi, folks:

We have submitted the draft on IKEv2 SA synchronization. Please check it.
Comments are more than welcome.

And, if possible, I would like to apply for a slot to present our work
in the incoming IPsec WG meeting in Dublin.

Thanks a lot
BRG
Peny



  
-----Original Message-----
From: i-d-announce-bounces@ietf.org
      
[mailto:i-d-announce-bounces@ietf.org]
  
On Behalf Of Internet-Drafts@ietf.org
Sent: Monday, July 07, 2008 4:30 PM
To: i-d-announce@ietf.org
Subject: I-D Action:draft-xu-ike-sa-sync-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

    Title           : IKE SA Synchronization
    Author(s)       : Y. Xu, et al.
    Filename        : draft-xu-ike-sa-sync-00.txt
    Pages           : 17
    Date            : 2008-07-07

It will take a long time to do security association syncronization
among IKE/IPsec gateways possibly maintaining huge numbers of IKEv2/
IPsec SAs.  The major reason is that the prcocedure of IKEv2 SA re-
establishment will incur a time-consuming computation especially in
the Diffie-Hellman exchange.  In this draft, a new IKE security
associations synchronization solution is proposed to reduce the
computation by directly transferring the indexed IKE SA from old
gateway to new gateway, wherein the most expensive Diffie-Hellman
calculation can be avoided.  Without some time-consuming IKEv2
exchanges, the huge amount of IKE/IPsec SA synchronization procedures
can be finished in a short time.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-xu-ike-sa-sync-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
      


Scanned by Check Point Total Security Gateway.
--------------010301040105010806000909-- --===============0008342570== 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://www.ietf.org/mailman/listinfo/ipsec --===============0008342570==-- From ipsec-bounces@ietf.org Fri Jul 11 07:50:54 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4BF33A67E3; Fri, 11 Jul 2008 07:50:54 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF483A67E3 for ; Fri, 11 Jul 2008 07:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hY1tKPU7RsBU for ; Fri, 11 Jul 2008 07:50:52 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.188]) by core3.amsl.com (Postfix) with ESMTP id 3C5A63A6768 for ; Fri, 11 Jul 2008 07:50:51 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so2387762tib.25 for ; Fri, 11 Jul 2008 07:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=OWronIxxNtA+60EGSYsOL+7crUE1Ha3T/wzevcFiXts=; b=lP1BR4jhC5hslt6kXODngP14jumGv23i0fcDjoh0ZzbjcXRIrFf4Eyre5fukGoqx61 4X/mAy9fJ5YFi03UuL1B/Ml+otoSFY/RMY+fMgTvgtKvXNA0UWUIRsInLMn8YrfGcBus yqQaw1SEl8klNYWf66XO6OU7MfKxDUZSGJnLs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=B96R9N/yr1RoM78HaQ4t4hcK+wsUiFtR8uErGzLzG05+iEwm8Eak73JezfRGJfa1Ui pqsWJcMozcd1SaXOMxq7so2ceisPGNNoTstBv9L1pGhoNix1hjjFuQehfNZeLHHJU4+8 OD+54GEp6jziGnOEFJpqvFJLXuSc9VBHtxCUQ= Received: by 10.110.10.16 with SMTP id 16mr6102953tij.15.1215787868755; Fri, 11 Jul 2008 07:51:08 -0700 (PDT) Received: by 10.110.53.11 with HTTP; Fri, 11 Jul 2008 07:51:08 -0700 (PDT) Message-ID: <1d38a3350807110751w424a33f2q9e992efdc003924c@mail.gmail.com> Date: Fri, 11 Jul 2008 22:51:08 +0800 From: "Hui Deng" To: "Yaron Sheffer" In-Reply-To: <4874D07C.8000807@checkpoint.com> MIME-Version: 1.0 References: <029d01c8e00e$203b99c0$2302600a@hitachichina.com> <4c5c7a6d0807070205v484436c5y3b5ab836a7175f67@mail.gmail.com> <4874D07C.8000807@checkpoint.com> Cc: ipsec@ietf.org, paul.hoffman@vpnc.org, Peny Yang Subject: Re: [IPsec] Fwd: FW: I-D Action:draft-xu-ike-sa-sync-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0132928667==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0132928667== Content-Type: multipart/alternative; boundary="----=_Part_88492_6741571.1215787868743" ------=_Part_88492_6741571.1215787868743 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Yaron, Thanks for your review and comments, firstly, let me note that I'am a co-author of draft-xu-ike-sa-sync-00, we planed to reply by Peny only, but he is on the business trip recently, so please allow me to cut in. 2008/7/9 Yaron Sheffer : > Hi Peny, > > first, let me note that I'm a coauthor of draft-sheffer-ipsec-failover-03, > which covers similar ground. Also, I am making the following comments > irrespective of the current group's charter. I am commenting on the actual > content of the draft, rather than its fit with the ipsecme charter. > ==> Many thanks, it is the advice. > > - The problem you are trying to solve is in my opinion very valid, and is > described very well in the "scenarios" section. > ==> Thanks again. > > - "Stub" is not a common name for what you are proposing. Some names I can > think of are "ticket", "token" or even "blob". There are surely others. > ==> We will consider to replace it based on your suggestion. > > - In general, the document expands too much on implementation issues, and > too little on the essential protocol issues. To illustrate the first point, > you mention a very specific implementation of a "map" data structure. So > specific that it wouldn't apply to Java code. > ==> Ok, we will readjust the content for this part to not exclude the Java code. > > - Similarly, Sec. 3.4 (although interesting) is very much out of scope. > Implementers can choose many ways to maintain and distribute the stubs. We > are mainly interested in the interoperable protocol, i.e. that between > client and gateway. > ==> Thanks for your suggestion, it should be discarded. > > - What I am missing is how the stub is acquired by the client, and possibly > how it is updated. In fact the only example of an IKE exchange is that of > *using* the stub. In addition, I couldn't find any mention of how the stub > is protected (encrypted/authenticated) or even that it is protected at all. > ==> good catch, we missed the descrition of stub in the client side, will append in the next version, it is quite similar to gateway side. > > - It is also unclear to me how the proposed protocol protects against > replay of the stub, to create multiple IKE SAs and eventually DOS the > gateway. > ==> current consideration is that IKE itself has mechanism of against replay. or we could add identification field. > > Thanks, > Yaron > ==>many thanks for your discussion. Best regards, -Hui > > > > > Peny Yang wrote: > > Hi, folks: > > We have submitted the draft on IKEv2 SA synchronization. Please check it. > Comments are more than welcome. > > And, if possible, I would like to apply for a slot to present our work > in the incoming IPsec WG meeting in Dublin. > > Thanks a lot > BRG > Peny > > > > > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > > [mailto:i-d-announce-bounces@ietf.org ] > > > On Behalf Of Internet-Drafts@ietf.org > Sent: Monday, July 07, 2008 4:30 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-xu-ike-sa-sync-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : IKE SA Synchronization > Author(s) : Y. Xu, et al. > Filename : draft-xu-ike-sa-sync-00.txt > Pages : 17 > Date : 2008-07-07 > > It will take a long time to do security association syncronization > among IKE/IPsec gateways possibly maintaining huge numbers of IKEv2/ > IPsec SAs. The major reason is that the prcocedure of IKEv2 SA re- > establishment will incur a time-consuming computation especially in > the Diffie-Hellman exchange. In this draft, a new IKE security > associations synchronization solution is proposed to reduce the > computation by directly transferring the indexed IKE SA from old > gateway to new gateway, wherein the most expensive Diffie-Hellman > calculation can be avoided. Without some time-consuming IKEv2 > exchanges, the huge amount of IKE/IPsec SA synchronization procedures > can be finished in a short time. > > A URL for this Internet-Draft is:http://www.ietf.org/internet-drafts/draft-xu-ike-sa-sync-00.txt > > Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > Scanned by Check Point Total Security Gateway. > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > ------=_Part_88492_6741571.1215787868743 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi, Yaron,
 
Thanks for your review and comments,
firstly, let me note that I'am a co-author of draft-xu-ike-sa-sync-00, we planed to reply by Peny only, but he is on the business trip recently, so please allow me to cut in.
2008/7/9 Yaron Sheffer <yaronf@checkpoint.com>:

Hi Peny,

first, let me note that I'm a coauthor of draft-sheffer-ipsec-failover-03, which covers similar ground. Also, I am making the following comments irrespective of the current group's charter. I am commenting on the actual content of the draft, rather than its fit with the ipsecme charter.

==> Many thanks, it is the advice.


- The problem you are trying to solve is in my opinion very valid, and is described very well in the "scenarios" section.

==> Thanks again.


- "Stub" is not a common name for what you are proposing. Some names I can think of are "ticket", "token" or even "blob". There are surely others.

==> We will consider to replace it based on your suggestion.


- In general, the document expands too much on implementation issues, and too little on the essential protocol issues. To illustrate the first point, you mention a very specific implementation of a "map" data structure. So specific that it wouldn't apply to Java code.

==> Ok, we will readjust the content for this part to not exclude the Java code.
 


- Similarly, Sec. 3.4 (although interesting) is very much out of scope. Implementers can choose many ways to maintain and distribute the stubs. We are mainly interested in the interoperable protocol, i.e. that between client and gateway.

==> Thanks for your suggestion, it should be discarded.
 


- What I am missing is how the stub is acquired by the client, and possibly how it is updated. In fact the only example of an IKE exchange is that of *using* the stub. In addition, I couldn't find any mention of how the stub is protected (encrypted/authenticated) or even that it is protected at all.

==> good catch, we missed the descrition of stub in the client side, will append
in the next version, it is quite similar to gateway side.
 


- It is also unclear to me how the proposed protocol protects against replay of the stub, to create multiple IKE SAs and eventually DOS the gateway.

==> current consideration is that IKE itself has mechanism of against replay.
or we could add identification field.
 
 


Thanks,
    Yaron

 
==>many thanks for your discussion.
Best regards,
 
-Hui
 
 





Peny Yang wrote:

Hi, folks:

We have submitted the draft on IKEv2 SA synchronization. Please check it.
Comments are more than welcome.

And, if possible, I would like to apply for a slot to present our work
in the incoming IPsec WG meeting in Dublin.

Thanks a lot
BRG
Peny



  
-----Original Message-----
From: i-d-announce-bounces@ietf.org
      
[mailto:i-d-announce-bounces@ietf.org]
  
On Behalf Of Internet-Drafts@ietf.org
Sent: Monday, July 07, 2008 4:30 PM
To: i-d-announce@ietf.org
Subject: I-D Action:draft-xu-ike-sa-sync-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

    Title           : IKE SA Synchronization
    Author(s)       : Y. Xu, et al.
    Filename        : draft-xu-ike-sa-sync-00.txt
    Pages           : 17
    Date            : 2008-07-07

It will take a long time to do security association syncronization
among IKE/IPsec gateways possibly maintaining huge numbers of IKEv2/
IPsec SAs.  The major reason is that the prcocedure of IKEv2 SA re-
establishment will incur a time-consuming computation especially in
the Diffie-Hellman exchange.  In this draft, a new IKE security
associations synchronization solution is proposed to reduce the
computation by directly transferring the indexed IKE SA from old
gateway to new gateway, wherein the most expensive Diffie-Hellman
calculation can be avoided.  Without some time-consuming IKEv2
exchanges, the huge amount of IKE/IPsec SA synchronization procedures
can be finished in a short time.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-xu-ike-sa-sync-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
      
Scanned by Check Point Total Security Gateway.

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


------=_Part_88492_6741571.1215787868743-- --===============0132928667== 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://www.ietf.org/mailman/listinfo/ipsec --===============0132928667==-- From ipsec-bounces@ietf.org Fri Jul 11 16:29:07 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 715FD3A692B; Fri, 11 Jul 2008 16:29:07 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD40B3A68E4 for ; Fri, 11 Jul 2008 16:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUuptzp7fkQv for ; Fri, 11 Jul 2008 16:29:04 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 421D73A67EF for ; Fri, 11 Jul 2008 16:29:04 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so3566544rvf.49 for ; Fri, 11 Jul 2008 16:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=nRZ7dSXsZ03MZ12EJfBOyC6lRhw6qiYKL5REXhU4e1A=; b=RA3l3sBrAPmDjSW/pprA0ZbJy11eCfUHeTbylFB5L1OeVdFHDbqIJgZWnAooWzFAhb IrhLnrHaQV+xlAa8y7koRuHQnIhztzhkzIuTpdQeKUFo7sQgNs/IagcKWqVmA6k1XGsl +kvhjTddB/3DZyqGsi1g/MJ6ISuziSCIJY1sA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=rsyY861tdUj+tVVDXPqs4fR7vX4YL7LqnDVvEXoZ3cAF//JBvgAiGSZOoE9YAh5hWb 46OR0zAoErOM5Hm1pXE68K0ax2C6PhrYGRnSrrK5ez+0sCEERbGnM2EnzjpWexDLwBms QzcVitUVEga73VaaKvFFrE0uatkT0kmEEbkws= Received: by 10.115.46.10 with SMTP id y10mr14868742waj.137.1215818962784; Fri, 11 Jul 2008 16:29:22 -0700 (PDT) Received: by 10.141.76.15 with HTTP; Fri, 11 Jul 2008 16:29:22 -0700 (PDT) Message-ID: Date: Fri, 11 Jul 2008 16:29:22 -0700 From: "Vijay Devarapalli" To: "Arnaud Ebalard" In-Reply-To: <87r6c2r3bu.fsf@natisbad.org> MIME-Version: 1.0 Content-Disposition: inline References: <87r6c2r3bu.fsf@natisbad.org> Cc: ipsec@ietf.org, mext@ietf.org Subject: Re: [IPsec] Redirect mechanism for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Arnaud, I apologize for the delay in responding to your email. On Fri, May 16, 2008 at 2:44 AM, Arnaud Ebalard wrote: > Hi Vijay, > > "Vijay Devarapallli" writes: > >> The draft at the URL below describes a mechanism for re-directing an >> IKEv2 initiator to another gateway during the IKE_SA_INIT exchange. >> This could be used for Mobile IPv6 also for a home agent to re-direct >> a mobile node to another home agent. >> >> Comments/reviews are welcome. > > Some comments below, with quoted parts from the draft. Sorry for > cross-posting but the discussion probably belongs to both ML. > > Mostly, the idea of the mechanim and the coverage looks ok to me but the > relationships with MIPv6 does not. > > To summarize most of my comments, the draft makes the redirect mechanism > happen at the IKE level and expects that it has no impact on the work of > the MIPv6 part. In practice, the address of the Home Agent being also > the address of the IKE GW and the IPsec SA (even if the negotiation > could be modified to be for different addresses regarding the IPsec SA > and the IKE GW), there is a need for synchronization between IKE and > MIPv6. IMHO, this is missing in the draft and should be stated. I am not sure if this document should talk about the interactions between the MIPv6 and IKEv2 processes in a particular implementation. > Note that this summary and some of my comments/questions below can also > be applied to Section 9 of RFC 4877, which describes Dynamic Home > Address configuration using IKEv2. > > For me, the redirect mechanism described in the draft is in some way the > dual of the Dynamic HoA configuration using IKE described in section 9 > of RFC 4877. > > Basically: > > - triggering event: IKE seems to initiate connections just like that, > without real triggering events, i.e. some packets being sent that > require protection and match some selector of a SPD entry. > - communications/synchronization: IKE is used (addresses here and in > 4877) for configuring/negotiating MIPv6 parameters but the > synchronization of those elements is not covered. I would also include > the IPsec in the picture. In practice, the MIPv6 modules, the IKE > daemon and the IPsec stack must work *together*. At the moment, some > draft and RFC on those elements have expectation but do not cover the > interactions between those elements. I have seen other emails from you on this subject, especially the interactions between IKEv2 and MIPv6 as described in RFC 4877 and RFC 5026. Perhaps, as you suggest, it might be a good idea to write a separate document that describes how these two protocols can interact with each other. Personally, it is not clear to me on what sort of details you are looking for. I think many of the details you are looking for is implementation specific. >> Mobile IPv6 [3] uses IKEv2 for mutual authentication between the >> mobile node and the home agent. IKEv2 is also used for home address >> configuration and setting up IPsec security associations for >> protecting Mobile IPv6 signaling messages [4]." > > uses -> may/can use. The mechanism is not required. IKEv1 is also > usable, so using IKE without any version might be better here. Fixed. >> The IKEv2 exchange precedes the exchange of Mobile IPv6 signaling >> messages. > > In practice, AFAICT, the IKE exchange is *triggered* by the emission of > the BU. It seems that RFC 4877 has started to take a different direction > where IKE is used to configure MIPv6, but the details are missing. When the mobile node boots up and figures that it needs to configure a home address, it can trigger an IKEv2 exchange with the home agent. Nothing needs to be said. This would be implementation specific on the mobile node. >> Therefore the mechanism described in this document can be also be >> used by a Mobile IPv6 home agent to re-direct a mobile node to >> another home agent. > > Collusion between Key Manager and HA operation. Yes. So? >> There is a Home Agent Switch mechanism available for re-directing a >> mobile node to another home agent, described in [5]. The Home Agent >> Switch mechanism can only be used after the binding cache had been >> created at the home agent for the mobile node. The disadvantage with >> this is that quite a bit of state is created on the home agent before >> the mobile node can be re-directed to another home agent. The >> mechanism described in this document can be used for re-directing a >> mobile node before any state is created on the home agent. > > IMHO, there is a difference between IKE and MIPv6 operations: > > 1) A Home Agent is overloaded and start redirecting MN to another HA: > for instance, it is already using all its available upload bandwidth > for registered MN (which is unrelated to IPsec/IKE). > 2) There are too many IKE peers connecting at the same time on an IKE > daemon (for the setup of IPsec SA between MN and HA or common > clients) and the IKE daemon starts redirecting clients to another IKE > daemon. > > What I mean is that, AFAICT, the two mechanism solve different problems, > through different channels. Do you see the need for any changes in the draft for this? > In section 3 > >> When the VPN client receives the IKE_SA_INIT response with the >> REDIRECT payload, it initiates a new IKE_SA_INIT exchange with the >> VPN gateway listed in the REDIRECT payload. The VPN client includes >> the IP address of the original VPN gateway that re-directed the >> client. The IKEv2 exchange then proceeds as normal with the selected >> VPN gateway. > > IMHO, the last sentence simply does not cover the possible associated > issues and how things should be done, *how* the associated users (IPsec > stack, MIPv6 module) are notified (on both sides). I am considering that > MIPv6 is used to cover all cases. > > - address of the IKE GW on the remote side > - the address of the HA used by the client > - the remote address of currently negotiated transport mode SA > protecting MIPv6 signaling > - endpoints of negotiated tunnel mode SA protecting data traffic if any > > I imagine that they will be set to the new IP. AFAICT, if the > negotiation was triggered by a BU, there will be a mismatch between the > triggering packet and the new destination. It does not have to be triggered by the Binding Update. The bootstrapping procedure on a Mobile IPv6 mobile node could be triggered for some other reason. >> When this mechanism is used with Mobile IPv6, a mobile node's >> security associations with its home agent may expire while it still >> has a valid binding cache entry at the home agent. In this case, the >> mobile node MUST NOT use an anycast address as the destination >> address in the IKE_SA_INIT exchange to setup new security >> associations. It MUST try to setup security associations with its >> existing home agent. > > How does the MN knows the address is anycast? The MIPv6 home agents anycast address is well known. See http://www.iana.org/assignments/ipv6-anycast-addresses. But I understand what you mean. I modified the paragraph as follows. When this mechanism is used with Mobile IPv6, a mobile node's security associations with its home agent may expire while it still has a valid binding cache entry at the home agent. In this case, the mobile node MUST NOT use the original home agent address as the destination address in the IKE_SA_INIT exchange to setup new security associations. It MUST try to setup security associations with its existing home agent. >> Section 4. > > Perhaps the previous point regarding interactions of MIPv6 clients with > IKE daemons that are part of an anycast domain belong here. You should > probably add some clear statements regarding the use of anycast > addresses for IKE daemon for MIPv6 clients. More precisely, what are the > conditions for a MIPv6 client to be configured with an anycast address > (or a name resolving to an anycast address) for the IKE daemon of its > HA. > > Can you tell me if I am wrong on this summary: you expect that a MIPv6 > client can be configured with an anycast address (or a name resolving > to an anycast address) for the IKE daemon of its HA if: > > - its local IKE Daemon support the Redirect > - it is redirected to a non-anycast unicast address when it connects the > first time > - it uses the address for all future connections to the remote IKE > daemon while it is registered with its HA. The re-direct should work irrespective of whether an anycast address is used. If anycast addresses are used, you don't have to necessarily configure the mobile node with the anycast address. The DNS lookup for the home agent can return an anycast address too. Vijay > > >> 5. > > I skipped it at the moment but will review in a future version of the > draft. > > >> 6. Security Considerations > > ok. > > > Cheers, > > a+ > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jul 11 16:33:27 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32EA33A6881; Fri, 11 Jul 2008 16:33:27 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54A7E3A6881 for ; Fri, 11 Jul 2008 16:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ce2jywVqk4GU for ; Fri, 11 Jul 2008 16:33:25 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 8E0DA3A67D9 for ; Fri, 11 Jul 2008 16:33:25 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so4102390wfd.31 for ; Fri, 11 Jul 2008 16:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=C7kssGjNDL4ZN9ELtoqx5/7xqLaIFte8sey/Ys7XPik=; b=dR7H4+8UHUGyKSO5fmgeK8+7RLUyvONAGz7iyENWLXvih7fvWgBgrkolDOpRKy+0Ck U2PhegrM7q6YPWmKxTU9c9FyaC5RkkLBtbhiB/fFPrL6dV2jsBuXt+8dcskJ4gdOxVNH xn+4gczKX8lIgGywOV3k4HBJu9ZycNHOAvz+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=I1l3yNdUxrp79kehxLxCidnFILLvC6yr3iFQYsb29Vd1aID0MqmBZ1wgNByESctsJm XIS9vgT1xFjHikdoqqItWiOao2mgNULMg7e/0f7A7brNe9YqRhA7OZPdl3aYtHDh1sVU ylbkd7I0K3qMA6bX6cZrGA/C5zupMS54V+uu8= Received: by 10.142.179.7 with SMTP id b7mr3383951wff.128.1215819224255; Fri, 11 Jul 2008 16:33:44 -0700 (PDT) Received: by 10.142.200.13 with HTTP; Fri, 11 Jul 2008 16:33:44 -0700 (PDT) Message-ID: Date: Fri, 11 Jul 2008 16:33:44 -0700 From: "Vijay Devarapalli" To: "Yaron Sheffer" In-Reply-To: <483078D8.3080309@checkpoint.com> MIME-Version: 1.0 Content-Disposition: inline References: <483078D8.3080309@checkpoint.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] Redirect mechanism for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Yaron, On Sun, May 18, 2008 at 11:43 AM, Yaron Sheffer wrote: > - In addition to IP addresses, I propose to allow an FQDN in the redirect, > both to make it more flexible (you don't need to configure all your > gateways' IP addresses into each of your gateways) and also because the > gateway's secure identity can be a DNS name, not just an address. Fixed this to allow either an FQDN or an IP address to be returned in the REDIRECT payload. > - Also on this field: it is not a very clean solution to parse the address > type (whether it's IPv4 or v6) based on the payload's length. Fixed. There is an explicit type field that indicates whether it is an IPv4 or IPv6 address. I will be submitting a new version over the weekend. > - The Security Considerations section mentions the case when "all clients > need to be moved to another Home Agent/VPN server" which is obviously not > solved by this solution - only *new* sessions will be moved. Fixed. Thanks Vijay _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jul 11 23:50:27 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 936643A6909; Fri, 11 Jul 2008 23:50:27 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 014453A6909 for ; Fri, 11 Jul 2008 23:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.746 X-Spam-Level: X-Spam-Status: No, score=0.746 tagged_above=-999 required=5 tests=[AWL=0.716, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, WHOIS_MYPRIVREG=1.499] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3Zpb3HLUWoK for ; Fri, 11 Jul 2008 23:50:26 -0700 (PDT) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by core3.amsl.com (Postfix) with ESMTP id 0290F3A67D6 for ; Fri, 11 Jul 2008 23:50:26 -0700 (PDT) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1KHYwP-00081B-Jd for ipsec@ietf.org; Fri, 11 Jul 2008 23:50:45 -0700 Message-ID: <18415382.post@talk.nabble.com> Date: Fri, 11 Jul 2008 23:50:45 -0700 (PDT) From: Arvind_s To: ipsec@ietf.org MIME-Version: 1.0 X-Nabble-From: arvind.phd@gmail.com Subject: [IPsec] [Ipsec] MULTIPLE_AUTH_SUPPORTED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, I have a question about AUTH computation in message exchange given in page 6 of RFC 4739 describing multiple auth exchanges. I would like to know how the AUTH paylaods are computed in message exchange 9, 10, 17 and 18. What is the data used and what are teh keys used. My understanding is Messages 9 and 17: Key is the MSK and data is the 1st IKE_SA_INIT message Messages 10 and 18: Key is the MSK and data is the 2nd IKE_SA_INIT message I'd appreciate it if one of the experts in this forum could shed some light on this. Thanks, Arvind -- View this message in context: http://www.nabble.com/MULTIPLE_AUTH_SUPPORTED-tp18415382p18415382.html Sent from the IETF - Ipsec mailing list archive at Nabble.com. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Jul 12 03:22:16 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9985B3A68B2; Sat, 12 Jul 2008 03:22:16 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A4543A68B2; Sat, 12 Jul 2008 03:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwRtcQzoSiTF; Sat, 12 Jul 2008 03:22:15 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id BBBA93A68A6; Sat, 12 Jul 2008 03:22:14 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KHcFF-0000Nc-Do; Sat, 12 Jul 2008 12:22:25 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: "Vijay Devarapalli" References: <87r6c2r3bu.fsf@natisbad.org> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:080712:dvijay@gmail.com::RoGN7nN3vk0ntLYA:009lJ X-Hashcash: 1:20:080712:mext@ietf.org::gH98/IrUqET2G+6P:00003gtX X-Hashcash: 1:20:080712:ipsec@ietf.org::mr4jWbda/ykmogwe:0006t6d Date: Sat, 12 Jul 2008 12:21:47 +0200 In-Reply-To: (Vijay Devarapalli's message of "Fri, 11 Jul 2008 16:29:22 -0700") Message-ID: <87tzevbdxg.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: ipsec@ietf.org, mext@ietf.org Subject: Re: [IPsec] Redirect mechanism for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1226426531==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1226426531== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable Hi Vijay, "Vijay Devarapalli" writes: > I apologize for the delay in responding to your email. no problem. Some responses below. >> To summarize most of my comments, the draft makes the redirect mechanism >> happen at the IKE level and expects that it has no impact on the work of >> the MIPv6 part. In practice, the address of the Home Agent being also >> the address of the IKE GW and the IPsec SA (even if the negotiation >> could be modified to be for different addresses regarding the IPsec SA >> and the IKE GW), there is a need for synchronization between IKE and >> MIPv6. IMHO, this is missing in the draft and should be stated. > > I am not sure if this document should talk about the interactions > between the MIPv6 and IKEv2 processes in a particular implementation. If it does not, everything is left as an implementation issue, which prevents IKE deamon from vendor "A" to be used out of the box with MIPv6 daemon from vendor "B" on a given platform. My question would be: if someone implements the mechanism proposed by the draft in an IKE daemon, will that work out of the box when the IKE daemon is used on a MN. AFAICT, no.=20 IMHO, if it is time consuming to understand the precise associated needs for interaction or to address them in the draft, it should be stated in the document so noone thinks it will work without more work. > I have seen other emails from you on this subject, especially the > interactions between IKEv2 and MIPv6 as described in RFC 4877 and RFC > 5026. Perhaps, as you suggest, it might be a good idea to write a > separate document that describes how these two protocols can interact > with each other.=20 Yes, now that there is some implementation feedback on the topic, it would be good to: 1) consider them 2) address them The difficulties are that the subject is both IPsec/IKE and MIPv6-related which makes it a less obvious item on ipsec or mext ML than a new functionality for one of the protocol. > Personally, it is not clear to me on what sort of > details you are looking for. I think many of the details you are > looking for is implementation specific. The ones described and addressed in draft-sugimoto-mip6-pfkey-migrate and draft-qi-mip6-ikev2-interfacing, to start with. Simply put: don't expect MIPv6+IKE to work (bootstrapping, movement) without what is in the drafts. >>> The IKEv2 exchange precedes the exchange of Mobile IPv6 signaling >>> messages. >> >> In practice, AFAICT, the IKE exchange is *triggered* by the emission of >> the BU. It seems that RFC 4877 has started to take a different direction >> where IKE is used to configure MIPv6, but the details are missing. > > When the mobile node boots up and figures that it needs to configure a > home address, it can trigger an IKEv2 exchange with the home agent. > Nothing needs to be said. This would be implementation specific on the > mobile node. Precisely and in the order of the sentence: =2D I agree that a MN will manage to know that it needs a Home Addres =2D I don't see *how* it will trigger an IKEv2 exchange =2D I don't see *how* it will retrieve the address gathered during the IKEv2 exchange Again, at the end of the day, if 'A' develops a MIPv6 Daemon, and 'B' develops an IKEv2 daemon, there is no way you can even start to make them interoperate WRT HoA assignement *IF* they have not work together to define a *custom* interface. What do you think? >>> Therefore the mechanism described in this document can be also be >>> used by a Mobile IPv6 home agent to re-direct a mobile node to >>> another home agent. >> >> Collusion between Key Manager and HA operation. > > Yes. So? I don't follow you: are you considering that MIPv6 and IKEv2 operations must be implemented in a single application in all cases? Hence, the lack of interface because you consider that as internal plumbering?=20 >>> There is a Home Agent Switch mechanism available for re-directing a >>> mobile node to another home agent, described in [5]. The Home Agent >>> Switch mechanism can only be used after the binding cache had been >>> created at the home agent for the mobile node. The disadvantage with >>> this is that quite a bit of state is created on the home agent before >>> the mobile node can be re-directed to another home agent. The >>> mechanism described in this document can be used for re-directing a >>> mobile node before any state is created on the home agent. >> >> IMHO, there is a difference between IKE and MIPv6 operations: >> >> 1) A Home Agent is overloaded and start redirecting MN to another HA: >> for instance, it is already using all its available upload bandwidth >> for registered MN (which is unrelated to IPsec/IKE). >> 2) There are too many IKE peers connecting at the same time on an IKE >> daemon (for the setup of IPsec SA between MN and HA or common >> clients) and the IKE daemon starts redirecting clients to another IKE >> daemon. >> >> What I mean is that, AFAICT, the two mechanism solve different problems, >> through different channels. > > Do you see the need for any changes in the draft for this? perhaps adding some use cases by discussing how the IKE could monitor some values (number of IKE peer, upload bandwidth consumed by MN, ...) or how you expect an administrator would use the proposed solution: what specific need does the solution address? >> IMHO, the last sentence simply does not cover the possible associated >> issues and how things should be done, *how* the associated users (IPsec >> stack, MIPv6 module) are notified (on both sides). I am considering that >> MIPv6 is used to cover all cases. >> >> - address of the IKE GW on the remote side >> - the address of the HA used by the client >> - the remote address of currently negotiated transport mode SA >> protecting MIPv6 signaling >> - endpoints of negotiated tunnel mode SA protecting data traffic if any >> >> I imagine that they will be set to the new IP. AFAICT, if the >> negotiation was triggered by a BU, there will be a mismatch between the >> triggering packet and the new destination. > > It does not have to be triggered by the Binding Update. The > bootstrapping procedure on a Mobile IPv6 mobile node could be > triggered for some other reason. Can you elaborate on that ? >> How does the MN knows the address is anycast? > > The MIPv6 home agents anycast address is well known. See > http://www.iana.org/assignments/ipv6-anycast-addresses. But I > understand what you mean. I modified the paragraph as follows. > > When this mechanism is used with Mobile IPv6, a mobile node's > security associations with its home agent may expire while it still > has a valid binding cache entry at the home agent. In this case, the > mobile node MUST NOT use the original home agent address as the > destination address in the IKE_SA_INIT exchange to setup new security > associations. It MUST try to setup security associations with its > existing home agent. ack. Thanks. Cheers, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIeIXBAlWVfAR6UCYRAtOPAKCI3rGJ9+Grw+U7CtWcMRDo9Qg4QQCcCU7a l6wTOyt30Rlhdtvnl2u9vIM= =KJ9q -----END PGP SIGNATURE----- --=-=-=-- --===============1226426531== 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://www.ietf.org/mailman/listinfo/ipsec --===============1226426531==-- From ipsec-bounces@ietf.org Sat Jul 12 11:29:10 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2051C28C134; Sat, 12 Jul 2008 11:29:10 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFF873A683E for ; Fri, 11 Jul 2008 18:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ho2BCItDCcMq for ; Fri, 11 Jul 2008 18:33:35 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by core3.amsl.com (Postfix) with ESMTP id D23013A6838 for ; Fri, 11 Jul 2008 18:33:34 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id b11so1117382nfh.39 for ; Fri, 11 Jul 2008 18:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=J4PYIQq/KPeIlD6YucgZzpf2KyTnlOIHQZGN7F1iKHQ=; b=lniwQ4XvQZsWwvBOHdSwlCVdXbZ0XGwDEwvnfdq0A6HQIQq6sHPfUsRMrM/mjPHg8X z1UWS22nfrG8/nNpNPYoxDt2yEgsTnVkXzZCrc+pW3op35WGA8LMUZt9zntLY37Blyun pgAsn3XsKpBZPDT/wH3Mk3FK2dlMYrhcBrt24= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=tQ/hcVmuq2hXEzWWnyNj7vyScXKKpUE3BTlRywi1Y++btMUF89xIC0OdiQFIG76/0t D7h5aPZjGZ/9hzx2KfTA6waB39VsPuq/WzeqgQTZJcrMcop+pG92h7v2OkSx/IfRg0Ar 7gQmT0iVKN5oY94ARsnit/mI9EmEXa15Pr8Tk= Received: by 10.210.36.8 with SMTP id j8mr7026721ebj.155.1215826428464; Fri, 11 Jul 2008 18:33:48 -0700 (PDT) Received: by 10.210.139.17 with HTTP; Fri, 11 Jul 2008 18:33:48 -0700 (PDT) Message-ID: <363a4c90807111833k22855304hbc43db273d59f74a@mail.gmail.com> Date: Fri, 11 Jul 2008 18:33:48 -0700 From: "Arvind Swaminathan" To: ipsec@ietf.org MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 12 Jul 2008 11:29:08 -0700 Subject: [IPsec] Data used in AUTH computation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0661192495==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0661192495== Content-Type: multipart/alternative; boundary="----=_Part_21778_18066157.1215826428459" ------=_Part_21778_18066157.1215826428459 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I have some questions regrading the IKEv2 RFC and would appreciate help from the IPSec experts. The sequence of steps when using EAP in IKEv2 is shown in page 32 of RFC4306. How is the AUTH payload computed in message 4 in this page? The one with IKE_AUTH_RESPONSE( HDR, SK {IDr, [CERT,] AUTH, EAP}). I think the Responder digitally signs some data with its private key. If yes, what is the data that is digitally signed? If no, what is done? Thanks, Arvind ------=_Part_21778_18066157.1215826428459 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

I have some questions regrading the IKEv2 RFC and would appreciate help from the IPSec experts.

The sequence of steps when using EAP in IKEv2 is shown in page 32 of RFC4306.

How is the AUTH payload computed in message 4 in this page?  The one with IKE_AUTH_RESPONSE( HDR, SK {IDr, [CERT,] AUTH, EAP}).

I think the Responder digitally signs some data with its private key.  If yes, what is the data that is digitally signed?  If no, what is done?

Thanks,
Arvind
------=_Part_21778_18066157.1215826428459-- --===============0661192495== 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://www.ietf.org/mailman/listinfo/ipsec --===============0661192495==-- From ipsec-bounces@ietf.org Sat Jul 12 11:29:10 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FAFD28C167; Sat, 12 Jul 2008 11:29:10 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D45F33A6B23 for ; Fri, 11 Jul 2008 19:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.03 X-Spam-Level: X-Spam-Status: No, score=0.03 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, WHOIS_MYPRIVREG=1.499] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdgJv+skj1k3 for ; Fri, 11 Jul 2008 19:30:28 -0700 (PDT) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by core3.amsl.com (Postfix) with ESMTP id 2BB2E3A6A62 for ; Fri, 11 Jul 2008 19:30:28 -0700 (PDT) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1KHUso-0001BP-TU for ipsec@ietf.org; Fri, 11 Jul 2008 19:30:46 -0700 Message-ID: <18415382.post@talk.nabble.com> Date: Fri, 11 Jul 2008 19:30:46 -0700 (PDT) From: Arvind_s To: ipsec@ietf.org MIME-Version: 1.0 X-Nabble-From: arvind.phd@gmail.com X-Mailman-Approved-At: Sat, 12 Jul 2008 11:29:08 -0700 Subject: [IPsec] [Ipsec] MULTIPLE_AUTH_SUPPORTED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, I have a question about AUTH computation in message exchange given in page 6 of RFC 4739 describing multiple auth exchanges. I would like to know how the AUTH paylaods are computed in message exchange 9, 10, 17 and 18. What is the data used and what are teh keys used. My understanding is Messages 9 and 17: Key is the MSK and data is the 1st IKE_SA_INIT message Messages 10 and 18: Key is the MSK and data is the 2nd IKE_SA_INIT message I'd appreciate it if one of the experts in this forum could shed some light on this. Thanks, Arvind -- View this message in context: http://www.nabble.com/MULTIPLE_AUTH_SUPPORTED-tp18415382p18415382.html Sent from the IETF - Ipsec mailing list archive at Nabble.com. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jul 13 22:19:13 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A90A3A6A20; Sun, 13 Jul 2008 22:19:13 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74A1F3A6A20 for ; Sun, 13 Jul 2008 22:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWngXMeLIHjC for ; Sun, 13 Jul 2008 22:19:10 -0700 (PDT) Received: from barracuda.intoto.com (unknown [66.88.133.2]) by core3.amsl.com (Postfix) with ESMTP id 9DFF33A6817 for ; Sun, 13 Jul 2008 22:19:10 -0700 (PDT) Received: from brahma.hyd.intoto.com (unknown [172.16.1.10]) by barracuda.intoto.com (Spam Firewall) with ESMTP id CEFA951C92; Sun, 13 Jul 2008 22:19:34 -0700 (PDT) Received: from nsm.intoto.com (1mc237.hyd.intoto.com [172.16.1.237]) by brahma.hyd.intoto.com (8.13.1/8.13.1) with ESMTP id m6E5JTeq012388; Mon, 14 Jul 2008 10:49:33 +0530 Message-Id: <7.0.1.0.1.20080714110040.03a432b0@intoto.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 14 Jul 2008 11:04:46 +0530 To: "Arvind Swaminathan" , ipsec@ietf.org From: ns srinivasa murthy In-Reply-To: <363a4c90807111833k22855304hbc43db273d59f74a@mail.gmail.com > References: <363a4c90807111833k22855304hbc43db273d59f74a@mail.gmail.com> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.62 on 172.16.1.10 Subject: Re: [IPsec] Data used in AUTH computation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0732084080==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0732084080== Content-Type: multipart/alternative; boundary="=====================_4745765==.ALT" --=====================_4745765==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, RFC 4306 Section 2.15 listed the data to be used for signing by the responder.In case of EAP ,the AUTH pay load is sent only by the responder. -nsmurthy At 07:03 AM 7/12/2008, Arvind Swaminathan wrote: >Hi, > >I have some questions regrading the IKEv2 RFC and would appreciate >help from the IPSec experts. > >The sequence of steps when using EAP in IKEv2 is shown in page 32 of RFC4306. > >How is the AUTH payload computed in message 4 in this page? The one >with IKE_AUTH_RESPONSE( HDR, SK {IDr, [CERT,] AUTH, EAP}). > >I think the Responder digitally signs some data with its private >key. If yes, what is the data that is digitally signed? If no, what is done? > >Thanks, >Arvind >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec ******************************************************************************** This email message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential, proprietary and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately notify the sender by reply email and destroy all copies of the original message. Thank you. Intoto Inc. --=====================_4745765==.ALT Content-Type: text/html; charset="us-ascii"
Hi,

RFC 4306 Section 2.15 listed the data to be used for signing by the responder.In case of EAP ,the AUTH pay load is sent only by the responder.

-nsmurthy


At 07:03 AM 7/12/2008, Arvind Swaminathan wrote:
Hi,

I have some questions regrading the IKEv2 RFC and would appreciate help from the IPSec experts.

The sequence of steps when using EAP in IKEv2 is shown in page 32 of RFC4306.

How is the AUTH payload computed in message 4 in this page?  The one with IKE_AUTH_RESPONSE( HDR, SK {IDr, [CERT,] AUTH, EAP}).

I think the Responder digitally signs some data with its private key.  If yes, what is the data that is digitally signed?  If no, what is done?

Thanks,
Arvind
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=====================_4745765==.ALT-- --===============0732084080== 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://www.ietf.org/mailman/listinfo/ipsec --===============0732084080==-- From ipsec-bounces@ietf.org Mon Jul 14 09:23:06 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46FE53A6B39; Mon, 14 Jul 2008 09:23:06 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82CE43A6AF8 for ; Mon, 14 Jul 2008 09:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wB9enHAJFFgV for ; Mon, 14 Jul 2008 09:23:03 -0700 (PDT) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id D8F213A67EE for ; Mon, 14 Jul 2008 09:22:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,360,1212364800"; d="scan'208,217";a="23268593" Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by ind-iport-1.cisco.com with ESMTP; 14 Jul 2008 16:23:20 +0000 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6EGNJ1W024314 for ; Tue, 15 Jul 2008 00:23:19 +0800 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6EGNIsn007499 for ; Mon, 14 Jul 2008 16:23:19 GMT Received: from xfe-blr-412.apac.cisco.com ([64.104.140.152]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 21:53:18 +0530 Received: from [64.103.178.251] ([64.103.178.251]) by xfe-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 21:53:18 +0530 Message-ID: <487B7DD8.5080706@cisco.com> Date: Mon, 14 Jul 2008 21:54:56 +0530 From: Pratima Sethi User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: ipsec@ietf.org X-OriginalArrivalTime: 14 Jul 2008 16:23:18.0301 (UTC) FILETIME=[ECBE4CD0:01C8E5CD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5158; t=1216052599; x=1216916599; c=relaxed/simple; s=hkgdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=psethi@cisco.com; z=From:=20Pratima=20Sethi=20 |Subject:=20[Fwd=3A=20New=20Version=20Notification=20for=20 draft-detienne-ikev2-recovery-01] |Sender:=20; bh=S76s3ZudUb5TLvulm3X2X60rr8KL8DnbRhIlZogB/qs=; b=JQAa+AevDrI5SjlQ4DbFhNCUjW0SbjW5jI9Fq+Avl13F4CAB4vpn7T6/wB u8wPphQo/kd1UAcvJ/51GsvPIAVKRU8kueqHKo7zI+jpEMddkp1VE3ur4eK1 /lHyxwGE2Iz9DDmcE4GDhLutDxFsrfOu41K8vZeAqcwk32XYBwzFs=; Authentication-Results: hkg-dkim-2; header.From=psethi@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; ); Subject: [IPsec] [Fwd: New Version Notification for draft-detienne-ikev2-recovery-01] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0466556650==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0466556650== Content-Type: multipart/alternative; boundary="------------090004080306010003000109" This is a multi-part message in MIME format. --------------090004080306010003000109 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit We posted a new version of safe ike recovery. Notable changes to this draft are - We have elaborated on the integration with IKE Session Resumption which was cited as one of the ways of recovery in the previous version of the draft. This draft cites a way for using IKE Session Resumption with Safe IKE recovery without increasing the number of round trips needed for detection and recovery together.We have included a potential MitM attack that could be launch on Safe IKE recovery and described the protection mechanisms built into IKE recovery that make such attacks not so interesting. Please review the draft which is available at http://www.ietf.org/internet-drafts/draft-detienne-ikev2-recovery-01.txt -------- Original Message -------- Subject: New Version Notification for draft-detienne-ikev2-recovery-01 Date: Mon, 14 Jul 2008 09:08:03 -0700 (PDT) From: IETF I-D Submission Tool To: psethi@cisco.com CC: fd@cisco.com, yir@checkpoint.com A new version of I-D, draft-detienne-ikev2-recovery-01.txt has been successfuly submitted by Pratima Sethi and posted to the IETF repository. Filename: draft-detienne-ikev2-recovery Revision: 01 Title: Safe IKE Recovery Creation_date: 2008-07-14 WG ID: Independent Submission Number_of_pages: 23 Abstract: The Internet Key Exchange protocol version 2 (IKEv2) suffers from the limitation of not having a means to quickly recover from a stale state known as dangling Security Associations (SA's) where one side has SA's that the corresponding party does not have anymore. This Draft proposes to address the limitation by offering an immediate, DoS-free recovery mechanism for IKE. The IETF Secretariat. --------------090004080306010003000109 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit We posted a new version of  safe ike recovery. Notable changes to this draft are -  We have elaborated on the integration with IKE Session Resumption which was cited as one of the ways of recovery in the previous version of the draft. This draft cites a way for using IKE Session Resumption with Safe IKE recovery without increasing the number of round trips needed for detection and recovery together.We have included a potential MitM attack that could be launch on Safe IKE recovery and described the protection mechanisms built into IKE recovery that make such attacks not so interesting.

Please review the draft which is available at http://www.ietf.org/internet-drafts/draft-detienne-ikev2-recovery-01.txt

-------- Original Message --------
Subject: New Version Notification for draft-detienne-ikev2-recovery-01
Date: Mon, 14 Jul 2008 09:08:03 -0700 (PDT)
From: IETF I-D Submission Tool <idsubmission@ietf.org>
To: psethi@cisco.com
CC: fd@cisco.com, yir@checkpoint.com 


A new version of I-D, draft-detienne-ikev2-recovery-01.txt has been successfuly submitted by Pratima Sethi and posted to the IETF repository.

Filename:	 draft-detienne-ikev2-recovery
Revision:	 01
Title:		 Safe IKE Recovery
Creation_date:	 2008-07-14
WG ID:		 Independent Submission
Number_of_pages: 23

Abstract:
The Internet Key Exchange protocol version 2 (IKEv2) suffers from the
limitation of not having a means to quickly recover from a stale
state known as dangling Security Associations (SA's) where one side
has SA's that the corresponding party does not have anymore.

This Draft proposes to address the limitation by offering an
immediate, DoS-free recovery mechanism for IKE.
                                                                                  


The IETF Secretariat.
--------------090004080306010003000109-- --===============0466556650== 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://www.ietf.org/mailman/listinfo/ipsec --===============0466556650==-- From ipsec-bounces@ietf.org Mon Jul 14 13:18:45 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 592BC3A6B61; Mon, 14 Jul 2008 13:18:45 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 054643A67E1 for ; Mon, 14 Jul 2008 13:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Syh6hSIYdNUu for ; Mon, 14 Jul 2008 13:18:43 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 764643A6B16 for ; Mon, 14 Jul 2008 13:18:37 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id C6430294004; Mon, 14 Jul 2008 23:19:02 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 798D2294001 for ; Mon, 14 Jul 2008 23:19:01 +0300 (IDT) Received: from [172.31.24.139] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m6EKJ0jI019152 for ; Mon, 14 Jul 2008 23:19:00 +0300 (IDT) Message-Id: From: Yoav Nir To: ipsec@ietf.org Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 14 Jul 2008 23:18:58 +0300 References: <20080714144501.E7BD03A67A4@core3.amsl.com> X-Mailer: Apple Mail (2.928.1) Subject: [IPsec] Fwd: I-D Action:draft-nir-ike-qcd-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1050299530==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1050299530== Content-Type: multipart/alternative; boundary=Apple-Mail-8--611146673 --Apple-Mail-8--611146673 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi all. This is version -01 of the crash detection draft. Major changes: - changed the protocol so that the token need not be stored across reboots - Added a stateless variation based on IKE recovery. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: July 14, 2008 5:45:01 PM GMT+03:00 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-nir-ike-qcd-01.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : A Quick Crash Detection Method for IKE > Author(s) : Y. Nir, et al. > Filename : draft-nir-ike-qcd-01.txt > Pages : 22 > Date : 2008-07-14 > > This document describes an extension to the IKEv2 protocol that > allows for faster crash recovery using a saved token. > > When an IPsec tunnel between two IKEv2 implementations is > disconnected due to a restart of one peer, it can take as much as > several minutes for the other peer to discover that the reboot has > occurred, thus delaying recovery. In this text we propose an > extension to the protocol, that allows for recovery immediately > following the reboot. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-nir-ike-qcd-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Scanned by Check Point Total Security Gateway. --Apple-Mail-8--611146673 Content-Type: multipart/mixed; boundary=Apple-Mail-9--611146672 --Apple-Mail-9--611146672 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi all.

This = is version -01 of the crash detection = draft. 

Major changes:
 - = changed the protocol so that the token need not be stored across = reboots
 - Added a stateless variation based on IKE = recovery.



Begin forwarded = message:

Date: July 14, 2008 5:45:01 PM = GMT+03:00
To: i-d-announce@ietf.org
Subject: = I-D Action:draft-nir-ike-qcd-01.txt 

A New = Internet-Draft is available from the on-line Internet-Drafts = directories.

Title =           : A Quick = Crash Detection Method for IKE
Author(s) =       : Y. Nir, et al.
Filename =        : = draft-nir-ike-qcd-01.txt
Pages =           : = 22
= Date =            : = 2008-07-14

This document describes an extension to the IKEv2 = protocol that
allows for faster crash recovery using a saved = token.

When an IPsec tunnel between two IKEv2 implementations = is
disconnected due to a restart of one peer, it can take as much = as
several minutes for the other peer to discover that the reboot = has
occurred, thus delaying recovery.  In this text we propose = an
extension to the protocol, that allows for recovery = immediately
following the reboot.

A URL for this = Internet-Draft is:
http= ://www.ietf.org/internet-drafts/draft-nir-ike-qcd-01.txt

Intern= et-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data = which will enable a MIME compliant mail reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
= --Apple-Mail-9--611146672 Content-Disposition: attachment; filename=mime-attachment Content-Type: message/external-body; x-unix-mode=0666; name="mime-attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2008-07-14073623.I-D@ietf.org>

--Apple-Mail-9--611146672 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Scanned by Check Point Total Security Gateway.

--Apple-Mail-9--611146672-- --Apple-Mail-8--611146673-- --===============1050299530== 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://www.ietf.org/mailman/listinfo/ipsec --===============1050299530==-- From ipsec-bounces@ietf.org Mon Jul 14 13:39:24 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EF313A67B7; Mon, 14 Jul 2008 13:39:24 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 246183A6BCF for ; Mon, 14 Jul 2008 13:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHf2OwpJM+dF for ; Mon, 14 Jul 2008 13:39:22 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id F2C1E3A6AD3 for ; Mon, 14 Jul 2008 13:39:14 -0700 (PDT) Received: from [10.20.30.162] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6EKdXrt049099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 13:39:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 14 Jul 2008 13:39:31 -0700 To: IPsecme WG From: Paul Hoffman Subject: [IPsec] Agenda for Dublin X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Whole meeting: IPsecme WG: Please let us know if there any changes needed. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 14 14:39:15 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 350ED28C1D0; Mon, 14 Jul 2008 14:39:15 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 101A63A6C3E for ; Mon, 14 Jul 2008 14:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJTtku-QjKGV for ; Mon, 14 Jul 2008 14:39:12 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 7EB8A3A6C23 for ; Mon, 14 Jul 2008 14:39:12 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so4856777wfd.31 for ; Mon, 14 Jul 2008 14:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition; bh=H2UGdct3wdi986zHaqO7aR1RlkP82s5B8qqwVED1w/c=; b=Cxy4/pRJbFBuhfNyDVtUMCPmDYd/sY1JcBm8vUymj6KXcykp4+GKWFxg0HnJF2Tj8p HO1lXpXmNdB8vzOc+ieQRPZx85hE9XnCYZQxcy5l/+lHxsKnQa++NtcC3vkNaPFYvEs6 UOkZTrveKwAAqPdyckhli8XsOTL9/ckzrrxU8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition; b=exKBvtB6Tkj0IoWFuV7D8p3iVzCj3wri3KsvMuteJr4cAAnXsBPxbHCN1g/qJBADxx bk4hBnNfM3uD8HA9Kcbh2gjetX/rJ7+uC5qX5M/mNQdKfGAbIXzfiW0i1viIffnmGT2h jZfBMfga8foXMQMSPX94V+X9SIKyqd3D2y1qM= Received: by 10.142.215.5 with SMTP id n5mr4378813wfg.131.1216071578816; Mon, 14 Jul 2008 14:39:38 -0700 (PDT) Received: by 10.142.141.12 with HTTP; Mon, 14 Jul 2008 14:39:38 -0700 (PDT) Message-ID: Date: Mon, 14 Jul 2008 14:39:38 -0700 From: "Vijay Devarapalli" To: "Arnaud Ebalard" MIME-Version: 1.0 Content-Disposition: inline Cc: ipsec@ietf.org, mext@ietf.org Subject: [IPsec] MIP6 and IKEv2 interaction (was Re: Redirect mechanism for IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Arnaud, I changed the subject since this is not relevant to the IKEv2 redirect mechanism anymore. On Sat, Jul 12, 2008 at 3:21 AM, Arnaud Ebalard wrote: >>> To summarize most of my comments, the draft makes the redirect mechanism >>> happen at the IKE level and expects that it has no impact on the work of >>> the MIPv6 part. In practice, the address of the Home Agent being also >>> the address of the IKE GW and the IPsec SA (even if the negotiation >>> could be modified to be for different addresses regarding the IPsec SA >>> and the IKE GW), there is a need for synchronization between IKE and >>> MIPv6. IMHO, this is missing in the draft and should be stated. >> >> I am not sure if this document should talk about the interactions >> between the MIPv6 and IKEv2 processes in a particular implementation. > > If it does not, everything is left as an implementation issue, which > prevents IKE deamon from vendor "A" to be used out of the box with MIPv6 > daemon from vendor "B" on a given platform. My question would be: if > someone implements the mechanism proposed by the draft in an IKE daemon, > will that work out of the box when the IKE daemon is used on a > MN. AFAICT, no. No, it wouldn't work. RFC 4887 and RFC 5026 identify the additional requirements for making IKEv2 work with MIPv6. > IMHO, if it is time consuming to understand the precise associated needs > for interaction or to address them in the draft, it should be stated in > the document so noone thinks it will work without more work. IMHO, such a document is not required. For example it is sufficient to say that the address obtained through the INTERNAL_IP6_ADDRESS attribute should be assigned as the MIPv6 home address. Similarly it is sufficient to say that the home agent IP address bootstrapped by the mobile node should appear in the SPD entry that is used for protecting the Binding Update message. Nothing more needs to be said in the IETF. How the two requirements are implemented in the mobile node would be specific to the particular implementation. Even if we do say something about that in the IETF, it would be INFORMATIONAL at the most. >> I have seen other emails from you on this subject, especially the >> interactions between IKEv2 and MIPv6 as described in RFC 4877 and RFC >> 5026. Perhaps, as you suggest, it might be a good idea to write a >> separate document that describes how these two protocols can interact >> with each other. > > Yes, now that there is some implementation feedback on the topic, it > would be good to: > > 1) consider them > 2) address them > > The difficulties are that the subject is both IPsec/IKE and > MIPv6-related which makes it a less obvious item on ipsec or > mext ML than a new functionality for one of the protocol. > >> Personally, it is not clear to me on what sort of >> details you are looking for. I think many of the details you are >> looking for is implementation specific. > > The ones described and addressed in draft-sugimoto-mip6-pfkey-migrate > and draft-qi-mip6-ikev2-interfacing, to start with. Sure. I think these documents were proposed to be added to the IPsec and MEXT charters. But there wasn't enough support for them to get added to the charter. > Simply put: don't > expect MIPv6+IKE to work (bootstrapping, movement) without what is in > the drafts. Or it could be left implementation specific. I am not going to respond to the rest of your email since we seem to have some basic disagreement on what needs to be left implementation specific and what needs to be addressed in a Standards Track document. We should discuss that first. Vijay >>>> The IKEv2 exchange precedes the exchange of Mobile IPv6 signaling >>>> messages. >>> >>> In practice, AFAICT, the IKE exchange is *triggered* by the emission of >>> the BU. It seems that RFC 4877 has started to take a different direction >>> where IKE is used to configure MIPv6, but the details are missing. >> >> When the mobile node boots up and figures that it needs to configure a >> home address, it can trigger an IKEv2 exchange with the home agent. >> Nothing needs to be said. This would be implementation specific on the >> mobile node. > > Precisely and in the order of the sentence: > > - I agree that a MN will manage to know that it needs a Home Addres > - I don't see *how* it will trigger an IKEv2 exchange > - I don't see *how* it will retrieve the address gathered during the > IKEv2 exchange > > Again, at the end of the day, if 'A' develops a MIPv6 Daemon, and 'B' > develops an IKEv2 daemon, there is no way you can even start to make > them interoperate WRT HoA assignement *IF* they have not work together > to define a *custom* interface. What do you think? > > >>>> Therefore the mechanism described in this document can be also be >>>> used by a Mobile IPv6 home agent to re-direct a mobile node to >>>> another home agent. >>> >>> Collusion between Key Manager and HA operation. >> >> Yes. So? > > I don't follow you: are you considering that MIPv6 and IKEv2 operations > must be implemented in a single application in all cases? Hence, the > lack of interface because you consider that as internal plumbering? > > >>>> There is a Home Agent Switch mechanism available for re-directing a >>>> mobile node to another home agent, described in [5]. The Home Agent >>>> Switch mechanism can only be used after the binding cache had been >>>> created at the home agent for the mobile node. The disadvantage with >>>> this is that quite a bit of state is created on the home agent before >>>> the mobile node can be re-directed to another home agent. The >>>> mechanism described in this document can be used for re-directing a >>>> mobile node before any state is created on the home agent. >>> >>> IMHO, there is a difference between IKE and MIPv6 operations: >>> >>> 1) A Home Agent is overloaded and start redirecting MN to another HA: >>> for instance, it is already using all its available upload bandwidth >>> for registered MN (which is unrelated to IPsec/IKE). >>> 2) There are too many IKE peers connecting at the same time on an IKE >>> daemon (for the setup of IPsec SA between MN and HA or common >>> clients) and the IKE daemon starts redirecting clients to another IKE >>> daemon. >>> >>> What I mean is that, AFAICT, the two mechanism solve different problems, >>> through different channels. >> >> Do you see the need for any changes in the draft for this? > > perhaps adding some use cases by discussing how the IKE could monitor > some values (number of IKE peer, upload bandwidth consumed by MN, ...) > or how you expect an administrator would use the proposed solution: what > specific need does the solution address? > > >>> IMHO, the last sentence simply does not cover the possible associated >>> issues and how things should be done, *how* the associated users (IPsec >>> stack, MIPv6 module) are notified (on both sides). I am considering that >>> MIPv6 is used to cover all cases. >>> >>> - address of the IKE GW on the remote side >>> - the address of the HA used by the client >>> - the remote address of currently negotiated transport mode SA >>> protecting MIPv6 signaling >>> - endpoints of negotiated tunnel mode SA protecting data traffic if any >>> >>> I imagine that they will be set to the new IP. AFAICT, if the >>> negotiation was triggered by a BU, there will be a mismatch between the >>> triggering packet and the new destination. >> >> It does not have to be triggered by the Binding Update. The >> bootstrapping procedure on a Mobile IPv6 mobile node could be >> triggered for some other reason. > > Can you elaborate on that ? > > >>> How does the MN knows the address is anycast? >> >> The MIPv6 home agents anycast address is well known. See >> http://www.iana.org/assignments/ipv6-anycast-addresses. But I >> understand what you mean. I modified the paragraph as follows. >> >> When this mechanism is used with Mobile IPv6, a mobile node's >> security associations with its home agent may expire while it still >> has a valid binding cache entry at the home agent. In this case, the >> mobile node MUST NOT use the original home agent address as the >> destination address in the IKE_SA_INIT exchange to setup new security >> associations. It MUST try to setup security associations with its >> existing home agent. > > ack. Thanks. > > > Cheers, > > a+ > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 14 15:52:57 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81AA93A6A87; Mon, 14 Jul 2008 15:52:57 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 394843A68A0 for ; Mon, 14 Jul 2008 15:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUn32OYKvtiV for ; Mon, 14 Jul 2008 15:52:54 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by core3.amsl.com (Postfix) with ESMTP id 80DE13A69D7 for ; Mon, 14 Jul 2008 15:52:54 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so2719707pyg.24 for ; Mon, 14 Jul 2008 15:53:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=iPR0B17O96gWZDWSZgaYtb6uAIjRAoKKQLZg8jswyKI=; b=JbgSvQn1f7xVa4S2mqmHyiz7fNRVVI8gOJakMX5TnMkl1GwgAUYwAmSz+BIRcit/TI va4tLTEDbT02bQHrNRU5iBgQ7kSlEdiQXXp0OUcgqG4Wf3r2r9gsu+Wol7VO1BWDIGrg Lv1qe1G18nn+op/MqifrvWhbdBYZ11ZosDvgU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=f3fNgiRfQIKykR+VdmUbgtiIGnelcaTxbjrkFtbI4NMrMRMADDtsLFuTBSC/CsV242 E7vv5RP+EfNW228fN8ANy+jPFWrS3Z8sLacfcLoIaS9oLXamqxfb5MC7QQqYvG3GovHn fIXBM9yXwWzeGSEKB9hw6Oho4g664u8Cfhp2A= Received: by 10.114.130.1 with SMTP id c1mr7725838wad.152.1216076000570; Mon, 14 Jul 2008 15:53:20 -0700 (PDT) Received: by 10.115.17.1 with HTTP; Mon, 14 Jul 2008 15:53:20 -0700 (PDT) Message-ID: <1d38a3350807141553p1d5fc68cr9e3f00367c54a0cf@mail.gmail.com> Date: Tue, 15 Jul 2008 06:53:20 +0800 From: "Hui Deng" To: "Vijay Devarapalli" In-Reply-To: MIME-Version: 1.0 References: Cc: ipsec@ietf.org, mext@ietf.org Subject: Re: [IPsec] [MEXT] MIP6 and IKEv2 interaction (was Re: Redirect mechanism for IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0926199419==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0926199419== Content-Type: multipart/alternative; boundary="----=_Part_22428_15249009.1216076000568" ------=_Part_22428_15249009.1216076000568 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Please allow me cut in, > The ones described and addressed in draft-sugimoto-mip6-pfkey-migrate > > and draft-qi-mip6-ikev2-interfacing, to start with. > > Sure. I think these documents were proposed to be added to the IPsec > and MEXT charters. But there wasn't enough support for them to get > added to the charter. > as one of co-author of the draft, I have talked with both authors of these two drafts to consider merge them together, will try to propose it again in next ietf meeting. -Hui ------=_Part_22428_15249009.1216076000568 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Please allow me cut in,

> The ones described and addressed in draft-sugimoto-mip6-pfkey-migrate
> and draft-qi-mip6-ikev2-interfacing, to start with.

Sure. I think these documents were proposed to be added to the IPsec
and MEXT charters. But there wasn't enough support for them to get
added to the charter.
as one of co-author of the draft, I have talked with both authors of these two drafts
to consider merge them together, will try to propose it again in next ietf meeting.
 
-Hui
------=_Part_22428_15249009.1216076000568-- --===============0926199419== 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://www.ietf.org/mailman/listinfo/ipsec --===============0926199419==-- From ipsec-bounces@ietf.org Tue Jul 15 00:35:23 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10A4828C322; Tue, 15 Jul 2008 00:35:23 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C541128C314; Tue, 15 Jul 2008 00:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 244e83lu74An; Tue, 15 Jul 2008 00:35:20 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id B2FC528C310; Tue, 15 Jul 2008 00:35:20 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KIf4U-0000Wn-C3; Tue, 15 Jul 2008 09:35:38 +0200 X-Hashcash: 1:20:080715:marcelo@it.uc3m.es::NM72hfoDf4OOjG3E:00000000000000000000000000000000000000000004X/K X-Hashcash: 1:20:080715:julien.ietf@laposte.net::L+7LzeoCDhdfCAWc:000000000000000000000000000000000000002UJi From: arno@natisbad.org (Arnaud Ebalard) To: "Vijay Devarapalli" References: X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:080715:dvijay@gmail.com::PjIQ5P1RgkQg+eGh:00rOK X-Hashcash: 1:20:080715:mext@ietf.org::w2WRDvBQcm7XYsj+:00002IE/ X-Hashcash: 1:20:080715:ipsec@ietf.org::N72OfcoBityoOqGi:0005zVv Date: Tue, 15 Jul 2008 09:34:59 +0200 Message-ID: <87bq0zvbvg.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: ipsec@ietf.org, marcelo bagnulo braun , Julien Laganier , mext@ietf.org Subject: Re: [IPsec] MIP6 and IKEv2 interaction X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0455406379==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0455406379== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable Hi Vijay, Julien, Marcelo, request for comment for you at the end. "Vijay Devarapalli" writes: > I changed the subject since this is not relevant to the IKEv2 redirect > mechanism anymore. ack. >>> I am not sure if this document should talk about the interactions >>> between the MIPv6 and IKEv2 processes in a particular implementation. >> >> If it does not, everything is left as an implementation issue, which >> prevents IKE deamon from vendor "A" to be used out of the box with MIPv6 >> daemon from vendor "B" on a given platform. My question would be: if >> someone implements the mechanism proposed by the draft in an IKE daemon, >> will that work out of the box when the IKE daemon is used on a >> MN. AFAICT, no. > > No, it wouldn't work. RFC 4887 and RFC 5026 identify the additional > requirements for making IKEv2 work with MIPv6. Yes, RFC 4877 contains additional requirements and help developers. RFC 5026 adds new functionalities but comes with new questions, IMHO. >> IMHO, if it is time consuming to understand the precise associated needs >> for interaction or to address them in the draft, it should be stated in >> the document so noone thinks it will work without more work. > > IMHO, such a document is not required. For example it is sufficient to > say that the address obtained through the INTERNAL_IP6_ADDRESS > attribute should be assigned as the MIPv6 home address. Similarly it > is sufficient to say that the home agent IP address bootstrapped by > the mobile node should appear in the SPD entry that is used for > protecting the Binding Update message. Nothing more needs to be said > in the IETF. How the two requirements are implemented in the mobile > node would be specific to the particular implementation. Even if we do > say something about that in the IETF, it would be INFORMATIONAL at the > most. RFC 2367 is informational (RFC 3549 too). I see your point but I also think that it makes sense to have the glue/bridges availables (even if it is in an informational fashion, resulting from development feedback). Leaving holes prevents interoperability, all the more when common interfaces do exist. MIGRATE draft is referenced in many documents including RFC 4877. >> The ones described and addressed in draft-sugimoto-mip6-pfkey-migrate >> and draft-qi-mip6-ikev2-interfacing, to start with. > > Sure. I think these documents were proposed to be added to the IPsec > and MEXT charters. But there wasn't enough support for them to get > added to the charter. There was support and at least two documents already available: they are just considered outside the scope of both WG. IPsec one because it is=20 MIPv6-specific and MEXT because it is considered an IPsec issue. >> Simply put: don't >> expect MIPv6+IKE to work (bootstrapping, movement) without what is in >> the drafts. > > Or it could be left implementation specific. Yes. I won't call that a solution, but this is a way to do it. In the end, as long as the implementation specific parts in MIPv6/IPsec/IKE picture are pointed, it is still useful, IMHO. Just like feedback from developers by the mean of informational documents. > I am not going to respond to the rest of your email since we seem to > have some basic disagreement on what needs to be left implementation > specific and what needs to be addressed in a Standards Track document. > We should discuss that first. ok, thank you for your comments. IIRC, I never asked for inclusion of implementation specific parts in Standards Track document. I just pointed that: =2D some mechanisms will not work out of the box because the glue is missing with other [normalized] parts of the picture =2D this is not explicitly stated in the documents that define the features. I find that misleading. If chairs tell me this is ok that way, I will stop bothering people with the two previous points. Cheers, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIfFMqAlWVfAR6UCYRAuhIAJ9ORbRRMNZnYXk5H6x/pY7TCYprKwCffxPs o89Vl+cA6nwNj41C0JwsJBc= =U13V -----END PGP SIGNATURE----- --=-=-=-- --===============0455406379== 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://www.ietf.org/mailman/listinfo/ipsec --===============0455406379==-- From ipsec-bounces@ietf.org Tue Jul 15 05:31:46 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF1C83A6880; Tue, 15 Jul 2008 05:31:46 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 421483A6880 for ; Tue, 15 Jul 2008 05:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQh6Kr2-NSaW for ; Tue, 15 Jul 2008 05:31:45 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by core3.amsl.com (Postfix) with ESMTP id C72FE3A6838 for ; Tue, 15 Jul 2008 05:31:44 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so3159330fkq.5 for ; Tue, 15 Jul 2008 05:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:sender; bh=aeGsEJRgMmlXRw1cD4DPhEgE8zYX/j3RcenZIg6ETPs=; b=JoRt24+MdMIIVkHPmDf8J80ScAN+Hhbf66aQUBpRitjkUhjMEDuerppPIkASQYaYbl h74jNF4DKI2CPcBWudAhAOCcgDBGuIHhJV+8/nyMAX9Mwfnvf23Es6MaBva/SNY12Gc0 Udbm/YbgU69Pb0Yyt2YYOpsSLVqnhVEdq+0YA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id:sender; b=tEAUPOd0pOmufXHBwoGxjjH9si4a6JAVoXteNdBH68gigkIQUM7rVBY0KYPNuDdLco lB3vVKt/7OLEUqinAWT4rJr6299Pt2W4oYPupVzZYZ/FRyICqlByEG9NOhvCDIt/lbJ9 9vY0A8t7Sb103BWvRmclOWBaaKJxJJ9TqnoB4= Received: by 10.187.215.8 with SMTP id s8mr2422341faq.86.1216125129498; Tue, 15 Jul 2008 05:32:09 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 11sm211332hug.62.2008.07.15.05.32.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Jul 2008 05:32:08 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Tue, 15 Jul 2008 14:32:04 +0200 User-Agent: KMail/1.9.9 References: <87bq0zvbvg.fsf@natisbad.org> In-Reply-To: <87bq0zvbvg.fsf@natisbad.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807151432.04934.julien.IETF@laposte.net> Cc: ipsec@ietf.org, Vijay Devarapalli Subject: Re: [IPsec] [MEXT] MIP6 and IKEv2 interaction X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hello Arnaud, Speaking as MEXT co-chair, below are inlined two clarifications: On Tuesday 15 July 2008, Arnaud Ebalard wrote: > > Julien, Marcelo, request for comment for you at the end. > > [...] > > >> The ones described and addressed in > >> draft-sugimoto-mip6-pfkey-migrate and > >> draft-qi-mip6-ikev2-interfacing, to start with. > > > > Sure. I think these documents were proposed to be added to the > > IPsec and MEXT charters. But there wasn't enough support for them > > to get added to the charter. > > There was support and at least two documents already available: they > are just considered outside the scope of both WG. IPsec one because > it is MIPv6-specific and MEXT because it is considered an IPsec > issue. A work item on interaction b/w IKEv2 and MIPv6 wasn't added to the MEXT charter for two reasons: - it wasn't possible to add every item with some support to the MEXT charter, prioritization was thus needed, and from that point of view there wasn't enough support for this compared to other items proposed at the time. - it was also noted that if interactions between MIPv6 and IKEv2 are to be based on PFKEY, although these could presumably fall into the MEXT scope, there's some upstream work to be done prior to that in the IPsec WG to revise PFKEY to IKEv2 and the revised IPsec architecture (RFC 4301). > >> Simply put: don't > >> expect MIPv6+IKE to work (bootstrapping, movement) without what is > >> in the drafts. > > > > Or it could be left implementation specific. > > Yes. I won't call that a solution, but this is a way to do it. In the > end, as long as the implementation specific parts in MIPv6/IPsec/IKE > picture are pointed, it is still useful, IMHO. Just like feedback > from developers by the mean of informational documents. > > > I am not going to respond to the rest of your email since we seem > > to have some basic disagreement on what needs to be left > > implementation specific and what needs to be addressed in a > > Standards Track document. We should discuss that first. > > ok, thank you for your comments. IIRC, I never asked for inclusion of > implementation specific parts in Standards Track document. I just > pointed that: > > - some mechanisms will not work out of the box because the glue is > missing with other [normalized] parts of the picture > - this is not explicitly stated in the documents that define the > features. I find that misleading. > > If chairs tell me this is ok that way, I will stop bothering people > with the two previous points. As of now we are not chartered to work on this topic, thus I consider we don't need to discuss that more, at least for now. --julien _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jul 15 08:12:39 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21B113A67A8; Tue, 15 Jul 2008 08:12:39 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF2753A67A8; Tue, 15 Jul 2008 08:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNIAZReKGwwf; Tue, 15 Jul 2008 08:12:38 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id D69983A63D3; Tue, 15 Jul 2008 08:12:37 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KImD5-0000y7-NE; Tue, 15 Jul 2008 17:12:59 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Julien Laganier References: <87bq0zvbvg.fsf@natisbad.org> <200807151432.04934.julien.IETF@laposte.net> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:080715:julien.ietf@laposte.net::/GCaUhFOFdXONczp:0000000000000000000000000000000000000019MU X-Hashcash: 1:20:080715:dvijay@gmail.com::i1aiUNcFhwN8CX9e:01l7r X-Hashcash: 1:20:080715:mext@ietf.org::FeCUH7i8rOqLMDal:00009Ge2 X-Hashcash: 1:20:080715:ipsec@ietf.org::WVHYbvprPbebjd/z:000A4Kj Date: Tue, 15 Jul 2008 17:12:22 +0200 In-Reply-To: <200807151432.04934.julien.IETF@laposte.net> (Julien Laganier's message of "Tue, 15 Jul 2008 14:32:04 +0200") Message-ID: <87d4lfrxk9.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: ipsec@ietf.org, Vijay Devarapalli , mext@ietf.org Subject: Re: [IPsec] [MEXT] MIP6 and IKEv2 interaction X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0542488761==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0542488761== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable Hi Julien, Julien Laganier writes: > Speaking as MEXT co-chair, below are inlined two clarifications: Ack. > - it wasn't possible to add every item with some support to the MEXT=20 > charter, prioritization was thus needed, and from that point of view=20 > there wasn't enough support for this compared to other items proposed=20 > at the time. With two proposed drafts and from the replies I have seen, I had a different feeling but I imagine you made a precise count. That's fine for me. > - it was also noted that if interactions between MIPv6 and IKEv2 are to=20 > be based on PFKEY, although these could presumably fall into the MEXT=20 > scope there's some upstream work to be done prior to that in the IPsec=20 > WG to revise PFKEY to IKEv2 and the revised IPsec architecture (RFC=20 > 4301). Hum, I don't see how/why the mechanism described in MIGRATE draft would benefit in waiting for an update of PF_KEY. On the opposite direction, if the glue between MIPv6 and IPsec/IKE provided by a PF_KEY-based interface is available as an informational document *when/if* there is an update of the standard, it would possibly be considered to be merged with this update. In the end, I don't buy this argument. >> ok, thank you for your comments. IIRC, I never asked for inclusion of >> implementation specific parts in Standards Track document. I just >> pointed that: >> >> - some mechanisms will not work out of the box because the glue is >> missing with other [normalized] parts of the picture >> - this is not explicitly stated in the documents that define the >> features. I find that misleading. >> >> If chairs tell me this is ok that way, I will stop bothering people >> with the two previous points. > > As of now we are not chartered to work on this topic, thus I consider we= =20 > don't need to discuss that more, at least for now. Ack. At your request, I will try and stop arguing against the trend in some recent mechanisms which now make no difference between IPsec/IKE and MIPv6 entities (implicitly leaving interfaces between the two as implementation issues). I will wait for you to bug me on that. Thanks for your time, Cheers, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIfL5cAlWVfAR6UCYRAt40AJ9WObraZUszwXPXPlr4mDtJyK+RZwCglWDf W89Fp7RsTFOXpY+m7ZaswpA= =/zrW -----END PGP SIGNATURE----- --=-=-=-- --===============0542488761== 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://www.ietf.org/mailman/listinfo/ipsec --===============0542488761==-- From ipsec-bounces@ietf.org Wed Jul 16 08:22:39 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D19083A69AD; Wed, 16 Jul 2008 08:22:39 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A6B93A682A for ; Wed, 16 Jul 2008 08:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Vux6HPOT9x9 for ; Wed, 16 Jul 2008 08:22:38 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 016D53A69AD for ; Wed, 16 Jul 2008 08:22:36 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id A0B33294004; Wed, 16 Jul 2008 18:23:05 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id C6BDD294001 for ; Wed, 16 Jul 2008 18:23:04 +0300 (IDT) Received: from [91.90.139.89] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m6GFN4jI017447 for ; Wed, 16 Jul 2008 18:23:04 +0300 (IDT) Message-ID: <487E125A.5020100@checkpoint.com> Date: Wed, 16 Jul 2008 18:23:06 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: ipsec@ietf.org Subject: [IPsec] ipsecme wiki X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0878763851==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0878763851== Content-Type: multipart/alternative; boundary="------------080609010700090205060403" This is a multi-part message in MIME format. --------------080609010700090205060403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, a new wiki page is available for the group, at this link . Please have a look. You are welcome to make changes - it's a wiki after all - but please contact me before you make *major* changes. Also, you will need a tools password to make changes. Thanks, Yaron --------------080609010700090205060403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hi,


a new wiki page is available for the group, at this link. Please have a look. You are welcome to make changes - it's a wiki after all - but please contact me before you make *major* changes. Also, you will need a tools password to make changes.


Thanks,

    Yaron

--------------080609010700090205060403-- --===============0878763851== 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://www.ietf.org/mailman/listinfo/ipsec --===============0878763851==-- From ipsec-bounces@ietf.org Thu Jul 17 08:53:49 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EBE03A690C; Thu, 17 Jul 2008 08:53:49 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32A343A690C for ; Thu, 17 Jul 2008 08:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKk58jIoY+HA for ; Thu, 17 Jul 2008 08:53:47 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id E8DE43A68C0 for ; Thu, 17 Jul 2008 08:53:46 -0700 (PDT) Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6HFs9iV064914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jul 2008 08:54:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 17 Jul 2008 08:54:07 -0700 To: IPsecme WG From: Paul Hoffman Subject: [IPsec] Presentations for the Dublin meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Everyone who is on the agenda for the Dublin IPsecme WG meeting () should have their presentations done well ahead of time so we can post them on the official IETF site before the meeting starts. This will also greatly help the people who cannot attend the meeting but who want to follow along on the audio simulcast. Please send your presentations to Yaron by next Wednesday. For the people in the last slot (the out-of-scope presentations), you really are restricted to three slides. Let Yaron or I know if you have any questions. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jul 18 03:54:59 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 759363A681D; Fri, 18 Jul 2008 03:54:59 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38DFA3A681D for ; Fri, 18 Jul 2008 03:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.668 X-Spam-Level: * X-Spam-Status: No, score=1.668 tagged_above=-999 required=5 tests=[AWL=1.639, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, WHOIS_MYPRIVREG=1.499] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUTuaXVt8K+n for ; Fri, 18 Jul 2008 03:54:57 -0700 (PDT) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by core3.amsl.com (Postfix) with ESMTP id 608D73A67A5 for ; Fri, 18 Jul 2008 03:54:57 -0700 (PDT) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1KJncY-0002AL-E0 for ipsec@ietf.org; Fri, 18 Jul 2008 03:55:30 -0700 Message-ID: <18526811.post@talk.nabble.com> Date: Fri, 18 Jul 2008 03:55:30 -0700 (PDT) From: lovewadhwa To: ipsec@ietf.org MIME-Version: 1.0 X-Nabble-From: lovewadhwa@gmail.com Subject: [IPsec] [Ipsec] scenario works or not X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org -- View this message in context: http://www.nabble.com/scenario-works-or-not-tp18526811p18526811.html Sent from the IETF - Ipsec mailing list archive at Nabble.com. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jul 18 04:02:35 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C35FB3A693E; Fri, 18 Jul 2008 04:02:35 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F6663A68DC for ; Fri, 18 Jul 2008 04:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.849 X-Spam-Level: X-Spam-Status: No, score=0.849 tagged_above=-999 required=5 tests=[AWL=0.819, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, WHOIS_MYPRIVREG=1.499] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNH-K6GgxXAC for ; Fri, 18 Jul 2008 04:02:33 -0700 (PDT) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by core3.amsl.com (Postfix) with ESMTP id 9FFBB3A68D5 for ; Fri, 18 Jul 2008 04:02:33 -0700 (PDT) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1KJnju-0002bl-Ma for ipsec@ietf.org; Fri, 18 Jul 2008 04:03:06 -0700 Message-ID: <18526923.post@talk.nabble.com> Date: Fri, 18 Jul 2008 04:03:06 -0700 (PDT) From: lovewadhwa To: ipsec@ietf.org MIME-Version: 1.0 X-Nabble-From: lovewadhwa@gmail.com Subject: [IPsec] [Ipsec] scenario works or not X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi all I have to set up the ipsec for the following scenario. I have host A in a network, host B in another network and host C in another network with ips defined below hostA internal ip ------ 192.168.2.14 hostB internal ip-------- 10.208.64.195 host C internal ip------- 10.209.64.56 Now i have one ipsec tunnel established between host A network and host B network and also have another ipsec tunnel existing between host B and host C.Now i do have to establish the communication between host A and host C by routing the traffic through host B.But i m not able to do that.Plz help me regardin the same.I have been establishing ipsec using racoon and have been following the ipsec document at the following url http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/security-guide/s1-ipsec-net2net.html -- View this message in context: http://www.nabble.com/scenario-works-or-not-tp18526923p18526923.html Sent from the IETF - Ipsec mailing list archive at Nabble.com. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jul 18 04:03:10 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FA843A69F4; Fri, 18 Jul 2008 04:03:10 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C5453A69ED for ; Fri, 18 Jul 2008 04:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.576 X-Spam-Level: X-Spam-Status: No, score=0.576 tagged_above=-999 required=5 tests=[AWL=0.546, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, WHOIS_MYPRIVREG=1.499] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pys7SSpGHrlp for ; Fri, 18 Jul 2008 04:03:08 -0700 (PDT) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by core3.amsl.com (Postfix) with ESMTP id 70C6E3A68D5 for ; Fri, 18 Jul 2008 04:03:08 -0700 (PDT) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1KJnkT-0002cb-Iv for ipsec@ietf.org; Fri, 18 Jul 2008 04:03:41 -0700 Message-ID: <18526930.post@talk.nabble.com> Date: Fri, 18 Jul 2008 04:03:41 -0700 (PDT) From: lovewadhwa To: ipsec@ietf.org MIME-Version: 1.0 X-Nabble-From: lovewadhwa@gmail.com Subject: [IPsec] [Ipsec] scenario works or not X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi all I have to set up the ipsec for the following scenario. I have host A in a network, host B in another network and host C in another network with ips defined below hostA internal ip ------ 192.168.2.14 hostB internal ip-------- 10.208.64.195 host C internal ip------- 10.209.64.56 Now i have one ipsec tunnel established between host A network and host B network and also have another ipsec tunnel existing between host B and host C.Now i do have to establish the communication between host A and host C by routing the traffic through host B.But i m not able to do that.Plz help me regardin the same.I have been establishing ipsec using racoon and have been following the ipsec document at the following url http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/security-guide/s1-ipsec-net2net.html Hopin a positive response. -- View this message in context: http://www.nabble.com/scenario-works-or-not-tp18526930p18526930.html Sent from the IETF - Ipsec mailing list archive at Nabble.com. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jul 20 18:05:20 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0703A6AC2; Sun, 20 Jul 2008 18:05:20 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0C53A6ABD for ; Sun, 20 Jul 2008 18:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGHGBnkyVXuO for ; Sun, 20 Jul 2008 18:05:18 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 8259A3A6AB8 for ; Sun, 20 Jul 2008 18:05:18 -0700 (PDT) Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6L14dfN076581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 20 Jul 2008 18:04:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Sun, 20 Jul 2008 18:04:36 -0700 To: IPsecme WG From: Paul Hoffman Subject: [IPsec] Reading list for Dublin meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Greetings again. One of the main purposes of face-to-face IETF meetings is to resolve issues in the WG's documents. We don't have WG documents yet, but we have contenders. People coming to the meeting in Dublin should have read the documents ahead of time so that the presenters can spend time focusing on specific issues in the documents, not giving document overviews. Given that, here's a reading list for people intending to attend face-to-face or listen on audio. IKEv2bis: Roadmap: none IPv6 support: Session resumption: Redirect: ESP-NULL: Reading drafts ahead of time really helps the meeting move along efficiently. Agenda: Information on listening in on audio: (will be filled in more closer to the event) Thanks in advance! --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 21 00:04:50 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA7103A683E; Mon, 21 Jul 2008 00:04:49 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D92013A683E for ; Mon, 21 Jul 2008 00:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCy+4mI6BMIE for ; Mon, 21 Jul 2008 00:04:48 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by core3.amsl.com (Postfix) with ESMTP id B0B393A67F3 for ; Mon, 21 Jul 2008 00:04:47 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so957773tib.25 for ; Mon, 21 Jul 2008 00:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:subject :date:mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:x-mailer:x-mimeole; bh=DNcRJn8kEmmx+S9FX2h+nwqXasltEDnwCu2tqL0rlu0=; b=RPu+wwZ85eqSnK5wADxFiQ1Y/88RxN+0WdKKdByQuDjNSsz2hP5OfOPlRKu5zPRWQ6 ioo8rEDw9Lnid9gHvAZfs0uc5jT5eSIm1cAEcZNc2BkN0TgOpnYqH19KyJ/jPumUcYMp 0IgCWqofXHAvsNVWQUsDUPU8PWJJ0lB2MMMr4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; b=C+tJGCMZvDTkq1RW2UhBBtY2ZKLtRPIOnO7ImRZ75z6g/MWpytuTO0A9eBP9uuuy0E sSB9f6eoi9XcCVyxdir26Ld3zCH/7IsO24AbS/sOzz/AMFpzNe5R+aTSjJQnbaYWuND4 efuavvUrbPryuQzywh483u/PSpPmIqE1/iiJM= Received: by 10.110.70.5 with SMTP id s5mr3425960tia.21.1216623922129; Mon, 21 Jul 2008 00:05:22 -0700 (PDT) Received: from sjjeong ( [129.254.112.29]) by mx.google.com with ESMTPS id y3sm10175718tia.3.2008.07.21.00.05.19 (version=SSLv3 cipher=RC4-MD5); Mon, 21 Jul 2008 00:05:20 -0700 (PDT) Message-ID: <020e01c8eb00$23decaf0$1d70fe81@sjjeong> From: "Sangjin Jeong" To: Date: Mon, 21 Jul 2008 16:05:17 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [IPsec] Fw: I-D Action:draft-lee-ipsec-nat-pt-applicability-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi folks, We have submitted a draft on applicability issues for IPsec support in NAT-PT. Please review it. Comments are welcome. Regards, Sangjin ----- Original Message ----- From: To: Sent: Monday, July 14, 2008 11:00 PM Subject: I-D Action:draft-lee-ipsec-nat-pt-applicability-02.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Applicability Issues for Supporting IPsec NAT-Traversal Mechanism in NAT-PT > Author(s) : S. Jeong, et al. > Filename : draft-lee-ipsec-nat-pt-applicability-02.txt > Pages : 10 > Date : 2008-07-14 > > This document describes applicability issues for supporting IPsec > protocol at NAT-PT, which is based on the NAT-Traversal mechanism. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lee-ipsec-nat-pt-applicability-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nlprunning@sehha.com Mon Jul 21 04:13:33 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 010183A69E9; Mon, 21 Jul 2008 04:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.501 X-Spam-Level: *** X-Spam-Status: No, score=3.501 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hu221QP+LmbT; Mon, 21 Jul 2008 04:13:32 -0700 (PDT) Received: from free.startv.com.ua (free.startv.com.ua [62.80.183.102]) by core3.amsl.com (Postfix) with SMTP id 857213A6910; Mon, 21 Jul 2008 04:13:24 -0700 (PDT) Received: (qmail 472 invoked from network); Mon, 21 Jul 2008 14:14:22 +0300 Received: from unknown (HELO Zhanna) (nlprunning@sehha.com@187.40.132.181) by 66b7503esehha.com with SMTP; Mon, 21 Jul 2008 14:14:22 +0300 Message-ID: <000f01c8eb3c$127aec30$0686586c@Zhanna> From: Amos Riggs To: iporpr-archive@lists.ietf.org Subject: by be rapport Date: Mon, 21 Jul 2008 14:14:22 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C8EB3C.127AEC30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.1158 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.2869 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C8EB3C.127AEC30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable information-processing systems and computers remains extensive. floating a= round in the vast array of networks. A lawyer may win wood and metal have enhanced and elevated native artwork. = ------=_NextPart_000_000C_01C8EB3C.127AEC30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
INTERNET, imagination will flourish as they try to grasp the

=

C A 0N A D/2AN     P 4 4H A RM A 0CY

V/A \G _RA - $1.41
C 6/ A L / S - $2.23
S3 O M A - $0.65
L E8 V / T R A - $3.62
FEMALE V1/9A1G9R7A - $1.59
U 4 L T 8R A M - $1.36
130 Items on Sale Today.

newspaper columns with titles like this. It is truly a pity that
= ------=_NextPart_000_000C_01C8EB3C.127AEC30-- From ipsec-bounces@ietf.org Mon Jul 21 09:17:57 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D568E3A68F4; Mon, 21 Jul 2008 09:17:57 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 503F33A6A59 for ; Mon, 21 Jul 2008 09:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.046 X-Spam-Level: X-Spam-Status: No, score=-102.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIWdunY0MvC9 for ; Mon, 21 Jul 2008 09:17:55 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 5B5CF3A6A4B for ; Mon, 21 Jul 2008 09:17:55 -0700 (PDT) Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6LGHHje047701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Jul 2008 09:17:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 21 Jul 2008 09:17:15 -0700 To: IPsecme WG From: The IESG Subject: [IPsec] Protocol Action: 'Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol' to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The IESG has approved the following document: - 'Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol ' as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-black-ipsec-ikev2-aead-modes-01.txt Technical Summary An authenticated encryption algorithm combines encryption and integrity into a single operation; such algorithms may also be referred to as combined modes of an encryption cipher or as combined mode algorithms. This document describes the use of authenticated encryption algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) protocol. The use of two specific authenticated encryption algorithms with the IKEv2 Encrypted Payload is also described; these two algorithms are the Advanced Encryption Standard (AES) in Galois/Counter Mode (AES GCM) and AES in Counter with CBC-MAC Mode (AES CCM). Additional documents may describe the use of other authenticated encryption algorithms with the IKEv2 Encrypted Payload. Working Group Summary This document is an individual submission. A pseudo working group Last Call was conducted on the ipsec@ietf.org mailing list by the Responsible Area Director (Tim Polk). No issues resulted from this pseudo WG Last Call. Document Quality Versions of this document have been reviewed by Charlie Kaufman, Pasi Eronen, Tero Kivinen, Steve Kent and Alfred Hoenes in addition to the authors. Personnel Document Shepherd: David L. Black Responsible Area Director: Tim Polk Personnel The Document Shepherd is David L. Black. Tim Polk is the Responsible Area Director. RFC Editor Note Please make the following changes, (a) through (e): (a) last sentence of the third paragraph of Section 1: OLD: The current version of ESP is version 2, ESPv2 [RFC4303]. NEW: The current version of ESP is version 3, ESPv3 [RFC4303]. (b) First line of the second paragraph of Section 7.1: OLD: IKEv2 makes the use of ... ^^^ NEW: IKEv2 makes use of ... (c) First sentence of Section 7.2: OLD: This section is unique to IKEv2 Encrypted Payload usage of AES GCM NEW: This section is unique to the IKEv2 Encrypted Payload usage of AES ^^^ (d) Section 10.1, 2nd line Insert the missing space: s/AEAD_*algorithms/AEAD_* algorithms/ (e) Section 10.2.1 OLD: The AEAD_AES_128_CCM_SHORT ciphertext is formed by appending the authentication tag provided as an output to the CCM encryption ^^ NEW: The AEAD_AES_128_CCM_SHORT ciphertext is formed by appending the authentication tag provided as an output of the CCM encryption ^^ In addition, it has been suggested that the "Conventions used in this document" material that comes after the Abstract should be moved to the end of Section 1 and become Section 1.1. Whether to do this is left to the RFC Editor's (wise) discretion. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jul 22 04:18:32 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFD483A6861; Tue, 22 Jul 2008 04:18:32 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6D63A681F for ; Tue, 22 Jul 2008 04:18:31 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxZTMVc9udNR for ; Tue, 22 Jul 2008 04:18:30 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 4F6153A6861 for ; Tue, 22 Jul 2008 04:18:30 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6MBIdkW007330; Tue, 22 Jul 2008 14:19:06 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 14:18:55 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 14:18:52 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 14:19:04 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72012C1744@vaebe104.NOE.Nokia.com> In-Reply-To: <18415382.post@talk.nabble.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] [Ipsec] MULTIPLE_AUTH_SUPPORTED Thread-Index: AcjkTVnrjuYyQo59QwGoHh+tft6D5QHnlx4A References: <18415382.post@talk.nabble.com> From: To: , X-OriginalArrivalTime: 22 Jul 2008 11:18:52.0363 (UTC) FILETIME=[B8B359B0:01C8EBEC] X-Nokia-AV: Clean Subject: Re: [IPsec] [Ipsec] MULTIPLE_AUTH_SUPPORTED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Arvind, In messages 9 and 10, the key is the MSK from the 1st EAP exchange; in messages 17 and 18, the key is the MSK from the 2nd EAP exchange. The data for message 9 is the IKE_SA_INIT request (message 1), Nr (from message 2), and value prf(SK_pi,IDi') (where IDi' comes from message 3). (See RFC 4306 Section 2.15 and RFC 4718 Section 3.1 for more details.) The data for message 10 is the IKE_SA_INIT response (message 2), Ni (from message 1), and value prf(SK_pr,IDr') (where IDr' comes from message 4). The data for message 17 is the same as message 9, except IDi' comes from message 11. The data for message 18 is the same as message 10. Best regards, Pasi > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of ext Arvind_s > Sent: 12 July, 2008 05:31 > To: ipsec@ietf.org > Subject: [IPsec] [Ipsec] MULTIPLE_AUTH_SUPPORTED > > > Hi, > > I have a question about AUTH computation in message exchange given > in page 6 of RFC 4739 describing multiple auth exchanges. > > I would like to know how the AUTH paylaods are computed in message > exchange 9, 10, 17 and 18. What is the data used and what are teh > keys used. > > My understanding is > > Messages 9 and 17: Key is the MSK and data is the 1st > IKE_SA_INIT message > Messages 10 and 18: Key is the MSK and data is the 2nd > IKE_SA_INIT message > > I'd appreciate it if one of the experts in this forum could shed > some light on this. > > Thanks, > Arvind _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jul 23 13:53:10 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 046343A6802; Wed, 23 Jul 2008 13:53:10 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CA043A6802; Wed, 23 Jul 2008 13:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uFnjqk0DNAK; Wed, 23 Jul 2008 13:53:07 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 8F7A13A6781; Wed, 23 Jul 2008 13:53:07 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KLlLE-0000Uk-3G; Wed, 23 Jul 2008 22:53:44 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: MEXT IETF WG , IPsec IETF WG User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) X-Hashcash: 1:20:080723:mext@ietf.org::qlZXP/T5W/01KakR:00006WUZ X-Hashcash: 1:20:080723:ipsec@ietf.org::2GoUKpuZm5uRit7W:00022rc X-Hashcash: 1:20:080723:louis.granboulan@eads.net::ccUv8cJholm6Tp3E:0000000000000000000000000000000000001YGh X-Hashcash: 1:20:080723:cedric.blancher@eads.net::z0DMHlV6sxw/Ingr:00000000000000000000000000000000000006mx4 X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 Date: Wed, 23 Jul 2008 22:53:01 +0200 Message-ID: <87hcag1fwy.fsf@natisbad.org> MIME-Version: 1.0 Subject: [IPsec] Mobile IPv6 and IPsec/IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0274385747==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0274385747== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Hi, [apologies for those who are on both lists] For those interested by *practical* deployment of MIPv6 with IPsec/IKE under Linux, I have written a page describing how to set things up. It is available here: http://natisbad.org/MIPv6/index.html It is based on an improved version of MIGRATE draft (resulting from discussions with the authors). This is the first version of the page and some parts are still under construction, so, be gentle. If you have comments, bug reports or ideas, do not hesitate. Cheers, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIh5otAlWVfAR6UCYRAvnzAKCN4GYnLVNUqVeO4DxKQUXi+rrmcQCcDaZp ZNpKH4Lj4D+mU5p2chibhDc= =JFKW -----END PGP SIGNATURE----- --=-=-=-- --===============0274385747== 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://www.ietf.org/mailman/listinfo/ipsec --===============0274385747==-- From ipsec-bounces@ietf.org Thu Jul 24 15:52:01 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48BD33A6810; Thu, 24 Jul 2008 15:52:01 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24B733A6810 for ; Thu, 24 Jul 2008 15:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDb6J1xZ46Cp for ; Thu, 24 Jul 2008 15:51:59 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 565AE3A685A for ; Thu, 24 Jul 2008 15:51:59 -0700 (PDT) Received: from [165.227.249.200] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6OMogmm020406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Jul 2008 15:50:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 24 Jul 2008 15:50:26 -0700 To: IPsecme WG From: Paul Hoffman Subject: [IPsec] Meeting materials are available X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org See . Note that we are about the only WG who has these up in advance; thanks go to Yaron for juggling this and a move. We hope to see many of you on Monday, but those who aren't there can follow along on audio. See for audio information. We are scheduled to be in Ballroom 1, which means that our audio should be on , but that could change. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jul 24 20:11:07 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2499C3A6A5B; Thu, 24 Jul 2008 20:11:07 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70743A67B4 for ; Thu, 24 Jul 2008 20:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjsX2gjYcy4l for ; Thu, 24 Jul 2008 20:11:06 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by core3.amsl.com (Postfix) with ESMTP id C3B5D3A6A89 for ; Thu, 24 Jul 2008 20:10:56 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so2202261fkq.5 for ; Thu, 24 Jul 2008 20:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:mime-version:content-type; bh=/ym6cqvnaV0lTt+/mAn5ojIC1KeMfUfwpVcM5XjKy1A=; b=Xx+jGvZKSyfbpkIjPFeNTi/Xzhi/7s9c8tTE5w+B6aaaW3z2VXCsbSLNBkHwk+FTB+ B4DBvIUn8m9W/GyKCkVvZHDq11Je17/lim2y3fCj8VEHzIX3fbcvpu18vFaJ7hO/bDqa C/9BsFxMCgo3LM1TZkZw1Qb5+Q2HRD4pjuoTE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type; b=tl6FeDg8NI3NXL9vdFrW/tPTnRMp1QBY6srVcUaTKLNUuMDObxclUhrsQyNdaXz83o 3a08YEHuKwQ0RIyhviWrHpgPx719mEzU+JganAid1sG6fff/qMuGaxX3HW79mEMbj7oo qe2eGMeB9vxV/p2RuB9Zjm6HWvUBu4gqIgFr8= Received: by 10.125.133.16 with SMTP id k16mr70847mkn.8.1216955455038; Thu, 24 Jul 2008 20:10:55 -0700 (PDT) Received: by 10.125.73.19 with HTTP; Thu, 24 Jul 2008 20:10:54 -0700 (PDT) Message-ID: <60dffc5e0807242010n22bb3e5fsb3216f6d2e0d5067@mail.gmail.com> Date: Thu, 24 Jul 2008 20:10:54 -0700 From: "abhishek singh" To: "IPsecme WG" MIME-Version: 1.0 Cc: sunil.kumar@in.safenet-inc.com, contactsunilkumar Subject: [IPsec] http://tools.ietf.org/html/draft-sunabhi-otp-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0644983352==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0644983352== Content-Type: multipart/alternative; boundary="----=_Part_11086_32745452.1216955455026" ------=_Part_11086_32745452.1216955455026 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Every One, We had thoughts of using One time Passwords in IKEv2 (non eap method). The draft of which has been posted online. http://tools.ietf.org/html/draft-sunabhi-otp-ikev2-02 Kindly do let us know your thoughts and concerns, Best Regards, Abhishek Singh & Sunil Kumar The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it ------=_Part_11086_32745452.1216955455026 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Every One,
 
We had thoughts of using One time Passwords in IKEv2 (non eap method). The draft of which has been posted online.http://tools.ietf.org/html/draft-sunabhi-otp-ikev2-02
 
 Kindly do let us know your thoughts and concerns,

Best Regards,
Abhishek Singh & Sunil Kumar

The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it
------=_Part_11086_32745452.1216955455026-- --===============0644983352== 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://www.ietf.org/mailman/listinfo/ipsec --===============0644983352==-- From ipsec-bounces@ietf.org Mon Jul 28 02:26:30 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8BB23A67ED; Mon, 28 Jul 2008 02:26:30 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62CD13A67ED for ; Mon, 28 Jul 2008 02:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiPBWUKo2pdp for ; Mon, 28 Jul 2008 02:26:28 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 9FF273A67E7 for ; Mon, 28 Jul 2008 02:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1217237198; x=1248773198; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:from:to:x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20Curious=20about=20the=20meeting =20procedures|Date:=20Mon,=2028=20Jul=202008=2002:26:04 =20-0700|Message-ID:=20|X-MS-Has-Attach:=20 |X-MS-TNEF-Correlator:=20|Thread-Topic:=20Curious=20about =20the=20meeting=20procedures|Thread-Index:=20Acjwk/UVb3U e7mRaRj+XzrZkQp1vsQ=3D=3D|From:=20"Narayanan,=20Vidya"=20 |To:=20 |X-OriginalArrivalTime:=2028=20Jul=202008=2009:26:06.0959 =20(UTC)=20FILETIME=3D[F6AF1FF0:01C8F093]|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5200,2160,5347"=3B=20a=3D"5101176"; bh=WvWitXPMuu9Ts00Rh3ea48n03k6Lny0LF2z4D8jiH70=; b=zH0jKMPvWJsZ8ec8HrLNvNT1NjwSdiIVtzrjxNfIqnBgwVR27xGsjO9y 86Ch8P+fuV+kpfM5PS5+NDuc+DgQYQ0JUd/xHWr4E73rTLiGiku7zZxsY nXvGt728wpHrW1Fp0xY4aJRMly56JHSYklMGJVc0OFyao2fNHQPXWWjB3 o=; X-IronPort-AV: E=McAfee;i="5200,2160,5347"; a="5101176" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jul 2008 02:26:07 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6S9Q7RE022806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 28 Jul 2008 02:26:07 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m6S9Q7hn020103 for ; Mon, 28 Jul 2008 02:26:07 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jul 2008 02:26:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 02:26:04 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Curious about the meeting procedures Thread-Index: Acjwk/UVb3Ue7mRaRj+XzrZkQp1vsQ== From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 28 Jul 2008 09:26:06.0959 (UTC) FILETIME=[F6AF1FF0:01C8F093] Subject: [IPsec] Curious about the meeting procedures X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, Admittedly I came in late into the meeting room, but, I'm curious - apparently, we were running late and couldn't handle more than one question or even more than one or two responses to it. But then, the presenter got into backup slides and took the time to present all the material. I'd imagine that the presentations to be kept to the minimum needed so we can get to some reasonable level of Q&A, the typical expectation being that the presentation is not intended to be a tutorial of the topic. Is the new accepted mode of operation for this WG? - Vidya _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 28 03:04:08 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1D2F3A69C8; Mon, 28 Jul 2008 03:04:07 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 146713A69C8 for ; Mon, 28 Jul 2008 03:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWl0cUxfBb5o for ; Mon, 28 Jul 2008 03:04:06 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 02F763A6895 for ; Mon, 28 Jul 2008 03:04:05 -0700 (PDT) Received: from [130.129.22.27] ([130.129.22.27]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6SA2nL0039618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 03:02:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 28 Jul 2008 11:02:31 +0100 To: "Narayanan, Vidya" , From: Paul Hoffman Subject: Re: [IPsec] Curious about the meeting procedures X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 2:26 AM -0700 7/28/08, Narayanan, Vidya wrote: >Admittedly I came in late into the meeting room, but, I'm curious - Your question below was in fact discussed at the beginning of the meeting. >apparently, we were running late and couldn't handle more than one >question or even more than one or two responses to it. ...because we have time to answer them at the end, as explained in the agenda. >But then, the >presenter got into backup slides and took the time to present all the >material. I'd imagine that the presentations to be kept to the minimum >needed so we can get to some reasonable level of Q&A, the typical >expectation being that the presentation is not intended to be a tutorial >of the topic. Is the new accepted mode of operation for this WG? Yes. If you didn't like the agenda, you could have let us know before the middle of the meeting. For future meetings, please review the agenda beforehand and let the co-chairs know if you have a better way for us to run the face-to-face meeting. Thanks! --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 28 04:37:08 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DBD63A6938; Mon, 28 Jul 2008 04:37:08 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EA3A3A691B for ; Mon, 28 Jul 2008 04:37:07 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRIsKvu3ELWQ for ; Mon, 28 Jul 2008 04:37:06 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with SMTP id 7892B3A67DB for ; Mon, 28 Jul 2008 04:37:04 -0700 (PDT) Received: from source ([202.122.134.5]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Mon, 28 Jul 2008 04:37:11 PDT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 17:07:07 +0530 Message-ID: <7A581A93408E68408DB73274370D78D3599E21@NOI1EXCH002.sfnt.local> In-Reply-To: <483078D8.3080309@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Redirect mechanism for IKEv2 Thread-Index: Aci5FyHFNubXYNumTUiH5yVB5fFJ9g3jLIGg References: <483078D8.3080309@checkpoint.com> From: "Kumar, Sunil" To: "Vijay Devarapallli" Cc: ipsec@ietf.org Subject: Re: [IPsec] Redirect mechanism for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Vijay, The submitted draft proposes a quite simple and effective way of load balancing. Please see some of our comments below: >>The 'Payload Length' field MUST be set to either '13' or '25' >>depending on whether an IPv4 or IPv6 address of the new VPN gateway >>is sent in the message. While considering the FQDN in the REDIRECT payload, there could be a possibility that Payload could exceed 13 or 25 bytes. >> The REDIRECTED_FROM message type is included in the IKE_SA_INIT >> request from the initiator to the new VPN gateway to indicate the IP >> address of the original VPN gateway that re-directed the initiator. >> The original VPN gateway's IP address is included in the message. The REDIRECTED_FROM message includes the original VPN gateway address from where the request has been redirected. In the draft it's not been discussed that whether the new VPN gateway could also send back a REDIRECT payload by proposing a "new VPN gateway". In other words, does it support the chain of gateway address in the payload? Thanks and Regards, Sunil Kumar Principle Engineer SafeNet Infotech Pvt. Ltd. > > > Vijay Devarapallli wrote: > > > Hello, > > > > The draft at the URL below describes a mechanism for re-directing an > > IKEv2 initiator to another gateway during the IKE_SA_INIT exchange. > > This could be used for Mobile IPv6 also for a home agent to re-direct > > a mobile node to another home agent. > > > > Comments/reviews are welcome. > > > > Vijay > > > > ---------- Forwarded message ---------- > > From: > > Date: 2008/5/15 > > Subject: I-D Action:draft-devarapalli-ipsec-ikev2-redirect-00.txt > > To: i-d-announce@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > Title : Re-direct Mechanism for IKEv2 > > Author(s) : V. Devarapalli, et al. > > Filename : draft-devarapalli-ipsec-ikev2-redirect-00.txt > > Pages : 11 > > Date : 2008-05-15 > > > > IKEv2 is a popular protocol for setting up VPN tunnels from a remote > > location to a gateway so that the VPN client can access services in > > the network behind the gateway. Currently there is no standard > > mechanism specified that allows an overloaded VPN gateway to re- > > direct the VPN client to attach to another gateway. This document > > proposes a re-direct mechanism for IKEv2. The proposed mechanism can > > also be used for Mobile IPv6 to enable the home agent to re-direct > > the mobile node to another home agent. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-devarapalli-ipsec-ikev2- > redirect-00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > Scanned by Check Point Total Security Gateway. > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 28 06:20:58 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E78113A68CA; Mon, 28 Jul 2008 06:20:58 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CCC23A6893 for ; Mon, 28 Jul 2008 06:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGC8rRzEZ8ne for ; Mon, 28 Jul 2008 06:20:56 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id AF5383A67DB for ; Mon, 28 Jul 2008 06:20:54 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m6SDKxMx025004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 16:20:59 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m6SDKwUw000648; Mon, 28 Jul 2008 16:20:58 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18573.51130.528112.634560@fireball.kivinen.iki.fi> Date: Mon, 28 Jul 2008 16:20:58 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 7 min X-Total-Time: 7 min Cc: pasi.eronen@nokia.com Subject: [IPsec] Review of draft-eronen-ipsec-ikev2-ipv6-config-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Here is some comments for the draft-eronen-ipsec-ikev2-ipv6-config-04.txt. Nothing major there just some small comments: > IPv6 Configuration in IKEv2 > draft-eronen-ipsec-ikev2-ipv6-config-04.txt > > ... > > 5. Solution Discussion > > Assigning a new IPv6 address to the client creates a new "virtual > IPv6 interface", and "virtual link" between the client and the > gateway. We will assume that the virtual link has the following > properties: > > o The link and its interfaces are created by IKEv2 messages, and are > destroyed once they are no longer used by any IKE SA. Actually quite often you need to keep the interface there even when the link and the IKE SA is not up. This provides nice way to allow kicking up the virtual interface, i.e. you just take the vipsec0 virtual interface and say "ifconfig vipsec0 up" and that will be detected by the IPsec and it will start negotiations to the remote host and then get addresses and assign them to interface. Even when the IKE link might go down for some reason, you can keep the interface up so that TCP sessions you have active do not get immediately destroyed when there is temporary problem with the connection. If the interface is there and up and still has addresses, while IPsec tries to reconnect to the gateway, then those connections do not immediately die. When the connection regained, and if the IPsec gw allows using same prefix and addresses, then those running TCP sessions will continue using same IP addresses and will not be broken at all. Currently most of the IPsec clients will start the IKE negotiation when someone first tries to use the network, i.e. when user opens web page that tries to connect to some site that should have IPsec protection. This means that this first packet that is used to trigger the negotiation, is normally using wrong IP-address as it is using the external IP-address as we do not have internal address yet. Some implementations makes "connect" button to act like that, i.e. they just send some dummy packet to trigger the negotiation. Those methods do have their problems, so creating the virtual interface(s) when the machine starts and only doing the configuration of those interfaces when the IKE is finished is somewhat better approach (altought it too has some problems). The things above is about same for both IPv4 and IPv6, so this is not really IPv6 specific problem, but if we define here that interfaces are created by IKEv2 then that will limit some useful implementation methods. > 6. Solution Sketch > 6.1. Initial Exchanges > > 1) During IKE_AUTH, the client sends a new configuration attribute, > INTERNAL_IP6_LINK, which requests a virtual link to be created. The > attribute contains the client's interface ID for link-local address > (other addresses may use other interface IDs). Typically, the client > would also ask for DHCPv6 server address; this is used only for > configuration, not address assignment. > ... > > (To be determined: is it necessary to include the gateway's link- > local interface ID? Probably the client does not need it.) I do not think clinet needs the gateway's link-local interface ID, and in that case we can change the INTERNAL_IP6_LINK attribute to follow the standard rule almost all other attributes use, i.e. client proposes something, and server replies with the acceptable value. I.e. client would send its own link-local interface ID (and optionally IKEv2 Link ID) to the server in INTERNAL_IP6_LINK and server would reply with that same link-local interface ID to verify that client is allowed to use that address (and the IKEv2 link ID). ... > The prefixes remain valid through the lifetime of the IKE SA (and its > continuations via rekeying). If the VPN gateway needs to remove a > prefix it has previously assigned, or assign a new prefix, it can do > so by triggering reauthentication. Add reference to the reauth draft here. > 7. Payload Formats > > 7.1. INTERNAL_IP6_LINK Configuration Attribute > > o Link-Local Interface ID (8 octets) - The Interface ID used for > link-local address (by the party that sent this attribute). As most of the IPsec implementators do not really know that much of the IPv6 specific things like Link Local Interface IDs, it would be good idea to give example or similar here, and whether the gateway for example is supposed to verify that the clients address it gives here is really a link local interface id or not. > o IKEv2 Link ID (variable length) - The link ID (may be empty when > the client does not yet know the link ID). ... > 7.2. INTERNAL_IP6_PREFIX Configuration Attribute ... > o Prefix (16 octets) - An IPv6 prefix assigned to the virtual link. Should we explicitly mandate that all bits of the prefix that are not part of the prefix MUST be 0? > 8. IANA Considerations ... > This document also defines one new IKEv2 notification, whose value is > to be allocated (has been allocated) from the "IKEv2 Notify Message > Types" namespace [IKEv2]: The registry is called "IKEv2 Notify Message Types - Status Types". Better use that so IANA can allocate it from the correct number range (16384-40959). > A.1. Version -00 Sketch > > Comments: This was changed in -01 draft based on feedback from VPN > vendors: while the solution looks nice on paper, it is claimed to be > unneccessarily complex to implement when the IKE implementation and > IPv6 stack are from different companies. Furthermore, enforcing > access control outside IPsec is a significant architectural change > compared to current IPv4 solutions. This approach would normally require the IPsec engine to find all router solicitations and advertisement messages going inside the IPsec tunnel, send them user mode policymanager so it can get that information too, and the policymanager would then need to parse those router solicitations and advertesements too in addition to normal stack doing it, and most likely modify the in kernel SPD tables etc. It might even need to do this before the system stack has possibility to see the RA as otherwise stack might immediately send packets which would be dropped as SPD is not yet updated etc. The information could also be available from the operating system stack, but in some cases OS stack for example does not give that informationt out before it has finished duplicate address detection or similar. This is doable, but it adds quite a lot of complexity and duplicates the RA parsing code to the IPsec module too. > A.5. Sketch Based on RFC 3456 > > For completeness: a solution modeled after [RFC3456] would combine > (1) router aggregation link model, (2) prefix information > distribution and unique address allocation with DHCPv6, and (3) > access control enforced by IPsec SAD/SPD. We did have implementation of that earlier, and that was one of those things where you had to do similar tricks than for version -00 Sketch. In here we actually had to reimplement dhcp as we could not use the OS dhcp in general case. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 28 06:28:44 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C15CD3A69FA; Mon, 28 Jul 2008 06:28:44 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA30F3A69FA for ; Mon, 28 Jul 2008 06:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Grc6cIXCl0P for ; Mon, 28 Jul 2008 06:28:39 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id B22503A682E for ; Mon, 28 Jul 2008 06:28:38 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 2B210294004; Mon, 28 Jul 2008 16:28:47 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 3F000294001; Mon, 28 Jul 2008 16:28:46 +0300 (IDT) Received: from [172.31.21.146] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m6SDSijI022522; Mon, 28 Jul 2008 16:28:45 +0300 (IDT) Message-Id: <416C34E3-B9B9-4DFE-96D5-99BF7E88F990@checkpoint.com> From: Yoav Nir To: "Kumar, Sunil" In-Reply-To: <7A581A93408E68408DB73274370D78D3599E21@NOI1EXCH002.sfnt.local> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 28 Jul 2008 14:28:43 +0100 References: <483078D8.3080309@checkpoint.com> <7A581A93408E68408DB73274370D78D3599E21@NOI1EXCH002.sfnt.local> X-Mailer: Apple Mail (2.928.1) Cc: ipsec@ietf.org, Vijay Devarapallli Subject: Re: [IPsec] Redirect mechanism for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2053423362==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============2053423362== Content-Type: multipart/signed; boundary=Apple-Mail-1-573839370; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-1-573839370 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Kumar, On Jul 28, 2008, at 12:37 PM, Kumar, Sunil wrote: >>> The REDIRECTED_FROM message type is included in the IKE_SA_INIT >>> request from the initiator to the new VPN gateway to indicate the IP >>> address of the original VPN gateway that re-directed the initiator. >>> The original VPN gateway's IP address is included in the message. > > The REDIRECTED_FROM message includes the original VPN gateway address > from where the request has been redirected. In the draft it's not been > discussed that whether the new VPN gateway could also send back a > REDIRECT payload by proposing a "new VPN gateway". In other words, > does > it support the chain of gateway address in the payload? I think you can't really prohibit the repeated REDIRECT, because configurations can have more than 1 backup. So I like the idea of the REDIRECTED_FROM notification listing all the gateways that have already turned us down. Maybe we should have text that says that the gateway SHOULD NOT send REDIRECT for a gateway that is in the REDIRECTED_FROM list. We also need to think about what a gateway should do when it receives a redirected initial exchange from a client, when it has out-of-band knowledge that it is far more overloaded than the REDIRECTED_FROM gateway. --Apple-Mail-1-573839370 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEAJIh/K+B1TMJ8nzoNjVff4wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDkwNDEzMzAzN1oXDTA4MDkwMzEzMzAz N1owRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANk5dX7Jjgb3 WcWBXGkva0ksYj49cHGta9zLei/8L36hnOgHfChX7jMU1scWGg4fA6v43SGB32/bjtioMt4FDazd MR/yqYykPSZ82X6MIDd/hqXJy2kWlLEzELy4UymxoBtZV0Woea0gO4rObjgQDf2JsacEt9Qxi+77 BA3W931iG2sjue0KdRx6xX3U1pwgx0M81fZ54gFgAhMlCf8AVqCgL6bv+HYAc2j4XjSGFjODjNyp n2Pumc9TVkj2uxmV+mMtclIhbXPy/5z0wg83ttnIfcI9cTKI88407fHTaUKmXf4Vhdp/NhbuHZWH bCBOMP0AiefcmvdGfqJc7o3JOYsCAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADEczlw8AJPiBRktBh113TwJrqL9 MeyaI+FB1yFUamAtd1i/Db0l9Xeb6iOK1M/MWwLbXTWBWxwhe3q7sayp8BZPJsLfBDyb1MYi8yGC ieBEatY6nP1Yy9KELX8frAfJ038FFw/rP2IqvUa2gxS0LW0vrgOg8hB1fRAUTlOr3MSDMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhACSIfyvgdUzCfJ86DY1X3+MAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDcyODEz Mjg0NFowIwYJKoZIhvcNAQkEMRYEFPbZoTa545MV6bc3dSWrs/mn8oHcMIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQAkiH8r4HVMwn yfOg2NV9/jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQAkiH8r4HVMwnyfOg2NV9/jANBgkqhkiG9w0BAQEFAASCAQA9GnluXqQx W9BSv+tKC2RFkkim3gdMzrgWg88jkcLEfUG4WG/YTBH9H4qSCH8+qmCR/J8AChNGh5rM3lN3E5qI 2RCApahtVRpTyq9xNKMICyEDebPIIES3sTvl8Hvuzhr7mLB6mnmuazJkIT4XrCTW1dTK8XnUvo4R kcU/vTKCIHy8IT0DJeTxaMDyPEUr3tQ7R1PqDJmNgDrgM4SS+1bQh3ZdYACDcqXjM8u5CoszUJs+ CZMsp2cnKvjgQfTJFwz1/rt7RltdpGqdT2VT8sFcFOnALQI8bCwisxnnoybGlv/q8s8G2ikGWOfi GXdnw2MRUPAB+MuR4PS58d5nnaBKAAAAAAAA --Apple-Mail-1-573839370-- --===============2053423362== 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://www.ietf.org/mailman/listinfo/ipsec --===============2053423362==-- From ipsec-bounces@ietf.org Mon Jul 28 08:19:49 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECA2C3A69C8; Mon, 28 Jul 2008 08:19:48 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEF4428C138 for ; Mon, 28 Jul 2008 08:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LiqDX6pWR7so for ; Mon, 28 Jul 2008 08:19:46 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 13E0B28C17C for ; Mon, 28 Jul 2008 08:19:34 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6SFJZZ08337; Mon, 28 Jul 2008 15:19:35 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 10:19:20 -0500 Message-ID: In-Reply-To: <416C34E3-B9B9-4DFE-96D5-99BF7E88F990@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Redirect mechanism for IKEv2 Thread-Index: AcjwteuBYZmLSBgWRJ6rk9DsHanYNAADJjqg References: <483078D8.3080309@checkpoint.com> <7A581A93408E68408DB73274370D78D3599E21@NOI1EXCH002.sfnt.local> <416C34E3-B9B9-4DFE-96D5-99BF7E88F990@checkpoint.com> From: "Ahmad Muhanna" To: "Yoav Nir" , "Kumar, Sunil" Cc: ipsec@ietf.org, Vijay Devarapallli Subject: Re: [IPsec] Redirect mechanism for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi All, > > Hi Kumar, > > On Jul 28, 2008, at 12:37 PM, Kumar, Sunil wrote: > >>> The REDIRECTED_FROM message type is included in the IKE_SA_INIT > >>> request from the initiator to the new VPN gateway to > indicate the IP > >>> address of the original VPN gateway that re-directed the > initiator. > >>> The original VPN gateway's IP address is included in the message. > > > > The REDIRECTED_FROM message includes the original VPN > gateway address > > from where the request has been redirected. In the draft > it's not been > > discussed that whether the new VPN gateway could also send back a > > REDIRECT payload by proposing a "new VPN gateway". In other words, > > does it support the chain of gateway address in the payload? > > I think you can't really prohibit the repeated REDIRECT, > because configurations can have more than 1 backup. So I like > the idea of the REDIRECTED_FROM notification listing all the > gateways that have already turned us down. Maybe we should > have text that says that the gateway SHOULD NOT send REDIRECT > for a gateway that is in the REDIRECTED_FROM list. > > We also need to think about what a gateway should do when it > receives a redirected initial exchange from a client, when it > has out-of-band knowledge that it is far more overloaded than > the REDIRECTED_FROM gateway. [Ahmad] IMO, the original REDIRECT functionality is a nice little idea that when is taken out of proportion, it becomes not that nice:( I suggest that we do not use this mechanism to offer an alternative for load balancing mechanism. In other words, the SECGW which REDIRECT the client SHOULD NOT do that blindly! There has to be a mechanism which "out-of-scope" that ensures the REDIRECT action is not done blindly and it should work from the first time. In case all available SEC GW are overloaded, the first SECGW SHOULD reject the session all together. I am not sure what mechanism can be used to NOT allow this functionality to be used unnecessarily for a cheap load balancing mechanism. My 2 cents. > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 28 09:14:46 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F2AB28C192; Mon, 28 Jul 2008 09:14:46 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEC3828C19E for ; Sun, 27 Jul 2008 23:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.775 X-Spam-Level: * X-Spam-Status: No, score=1.775 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_57=0.6, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXt17L3neK+P for ; Sun, 27 Jul 2008 23:48:51 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id BACE528C192 for ; Sun, 27 Jul 2008 23:48:50 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 07:48:56 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 07:48:56 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 121722773550; Mon, 28 Jul 2008 07:48:55 +0100 Received: from mut.jungle.bt.co.uk ([10.73.192.104]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m6S6mVJj026921; Mon, 28 Jul 2008 07:48:53 +0100 Message-Id: <200807280648.m6S6mVJj026921@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 27 Jul 2008 10:20:00 +0100 To: "PCN IETF list" , pwe3@ietf.org, ipsec@ietf.org From: Bob Briscoe Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 28 Jul 2008 06:48:56.0159 (UTC) FILETIME=[017D3EF0:01C8F07E] X-Mailman-Approved-At: Mon, 28 Jul 2008 09:14:45 -0700 Cc: tsvwg IETF list Subject: [IPsec] Fwd: Updated: ECN Tunnelling I-D relevant to PCN, PWE3, IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org PCN, PWE3, IPsec lists, Just notifying you of an I-D just posted that could become relevant to each of your w-gs (if it becomes a w-g item - it's still an individual draft). See posting below for details. You might choose to wait to see whether it becomes a tsvwg WG item before reading, or you might want to help (or hinder!) it becoming a WG item. The standards action stuff is in 2 pages from S.5 to S.7. Pls cross-post any discussion that affects your w-g to at least. Cheers Bob >Date: Thu, 17 Jul 2008 21:00:38 +0100 >To: "tsvwg IETF list" >From: Bob Briscoe >Subject: Updated: ECN Tunnelling I-D relevant to PCN, PWE3, IPsec > >Tsvwg (also relevant to PCN, PWE3 & IPsec - but pls discuss on tsvwg), > >Layered Encapsulation of Congestion Notification > >(intended for standards track) > >Abstract and summary of diffs pasted below. > >At the last -00 rev, on the tsvwg list there was unanimous support >and no detractors for the primary proposal to bring the ECN >behaviour of IP in IP tunnels into line with IPsec tunnels. However, >many voiced concerns about secondary aspects of the -00 draft. I >believe I've fixed them all (with considerable help from David Black >and RFC2983), but I've probably added more ;) > >That was a year ago. The ADs suggested, and I agreed, that we should >let it lie until PCN wire protocol was clearer (in case there was an >interaction). PCN's just become clearer. So I've rev'd this one back to life. > >I'm about to go offline until Dublin starts, so I'll pick up any >discussion then. > > >Bob > > >Abstract > > This document redefines how the explicit congestion notification > (ECN) field of the outer IP header of a tunnel should be constructed. > It brings all IP in IP tunnels (v4 or v6) into line with the way > IPsec tunnels now construct the ECN field. It includes a thorough > analysis of the reasoning for this change and the implications. It > also gives guidelines on the encapsulation of IP congestion > notification by any outer header, whether encapsulated in an IP > tunnel or in a lower layer header. Following these guidelines should > help interworking, if the IETF or other standards bodies specify any > new encapsulation of congestion notification. > > >Changes From -00 to -01: > > * Related everything conceptually to the uniform and pipe models > of RFC2983 on Diffserv Tunnels, and completely removed the > dependence of tunnelling behaviour on the presence of any in- > path load regulation by using the [1 - Before] [2 - Outer] > function placement concepts from RFC2983. > > * Added specifc cases where the existing standards limit new > proposals. > > * Added sub-structure to Introduction (Need for Rationalisation, > Roadmap), added new Introductory subsection on "Scope" and > improved clarity > > * Added Design Guidelines for New Encapsulations of Congestion > Notification > > * Considerably clarified the Backward Compatibility section > > * Considerably extended the Security Considerations section > > * Summarised the primary rationale much better in the conclusions > > * Added numerous extra acknowledgements > > * Added Appendix A. "Why resetting CE on encapsulation harms > PCN", Appendix B. "Contribution to Congestion across a Tunnel" > and Appendix C. "Ideal Decapsulation Rules" > > * Changed Appendix A "In-path Load Regulation" to "Non-Dependence > of Tunnelling on In-path Load Regulation" and added sub-section > on "Dependence of In-Path Load Regulation on Tunnelling" > > > >____________________________________________________________________________ >Bob Briscoe, Networks Research Centre, BT Research >B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 28 11:04:59 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F23853A6901; Mon, 28 Jul 2008 11:04:58 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A22F28C1C6 for ; Mon, 28 Jul 2008 11:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpX4nsBWOuMC for ; Mon, 28 Jul 2008 11:04:55 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id BD87A28C290 for ; Mon, 28 Jul 2008 11:04:36 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id EED301022408A for ; Mon, 28 Jul 2008 11:04:46 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 28 Jul 2008 11:04:47 -0700 (PDT) Message-ID: <24824166c413680844268e1db43651cf.squirrel@www.trepanning.net> In-Reply-To: <20080624163001.66CF63A6A69@core3.amsl.com> References: <20080624163001.66CF63A6A69@core3.amsl.com> Date: Mon, 28 Jul 2008 11:04:47 -0700 (PDT) From: "Dan Harkins" To: ipsec@ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Subject: Re: [IPsec] WG Review: IP Security Maintenance and Extensions (ipsecme) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, I'd like to take issue with part of this charter, specifically the session resumption part. I'd like to see the work not be so "remote access" and "client" centric. It's more of a generic problem and should have a generic solution. This might just be a semantic hangup of mine (which is easily taken care of) but I'd just like to ensure that the remote access slash VPN focus doesn't constrain things. A bigger issue, though, concerns the construction of the "ticket". I'd like to know why this is out-of-scope. I can see the possibility of consensus forming in the WG around a document that does not specify construction of the "ticket" but that doesn't mean the topic should be out-of-scope. How the "ticket" get constructed will influence the security of the scheme. A properly constructed "ticket" may even help address DoS issues. This topic should be in scope. It seems very wrong that we would generate a standards track document in the Security Area with a critical component of the security of the proposal being left up to the imagination of the guy implementing it. I've been going through the last couple weeks of postings and can't find discussion and/or justification for making "ticket" construction out-of-scope. regards, Dan. On Tue, June 24, 2008 9:30 am, IESG Secretary wrote: > A new IETF working group has been proposed in the Security Area. The IESG > has not made any determination as yet. The following draft charter was > submitted, and is provided for informational purposes only. Please send > your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, July 1, > 2008. > > > IP Security Maintenance and Extensions (ipsecme) > ------------------------------------------------ > Last Modified: June 19, 2008 > > Current Status: Proposed Working Group > > Chair(s): TBD > > Mailing Lists: > > General Discussion: ipsec@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec > Archive: http://www.ietf.org/mail-archive/web/ipsec/ > > The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated > RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the IPsec > security architecture (RFC 4301). IPsec is widely deployed in VPN > gateways, VPN remote access clients, and as a substrate for > host-to-host, host-to-network, and network-to-network security. > > The IPsec Maintenance and Extensions Working Group will continue the > work of the earlier IPsec Working Group which was concluded in 2005. Its > purpose is to maintain the IPsec standard and to facilitate discussion > of clarifications, improvements, and extensions and improvements to > IPsec, mostly to IKEv2. The working group will also be a focus point for > other IETF Working Groups who use IPsec in their own protocols. > > The initial set of work items is: > > - A revision to IKEv2 (RFC 4306) that incorporates the clarifications > from RFC 4718, and otherwise improves the quality of the specification, > taking into account implementation and interoperability experience. In > some cases, the revision may include small technical corrections; > however, impact on existing implementations must be considered. Major > changes and adding new features is beyond the scope of this work > item. The starting point for this work is draft-hoffman-ikev2bis. > > - An IPsec document roadmap that describes the various RFC documents > covering IPsec, including both the core RFC 240x and RFC 430x versions > of IPsec, and extensions specified in other documents. Sections 2 and 3 > of RFC 2411 can provide useful material, but the expected scope is > slightly different from RFC 2411. This document will be informational. > > - A standards-track extension to IKEv2 that provides full IPv6 support > for IPsec remote access clients that use configuration payloads. This > work will be based on draft-eronen-ipsec-ikev2-ipv6-config. The WG shall > solicit help and reviews from the 6MAN WG to ensure that all aspects of > IPv6 are properly considered. > > - A standards-track extension that allows an IPsec remote access client > to "resume" a session with a gateway; that is, to skip certain parts of > IKE negotation when connecting again to the same gateway (or possibly a > cluster of closely cooperating gateways). The idea is similar to TLS > session resumption without server-side state, specified in RFC 5077. > > The main goals for this extension are to avoid public-key computations > (to reduce VPN gateway load when a large number of clients reconnect to > the geteway within a short period of time, such as following a network > outage), and remove the need for user interaction for authentication > (which may be required by some authentication mechanisms). The extension > shall not have negative impact on IKEv2 security features. > > Failover from one gateway to another, mechanisms for detecting when a > session should be resumed, and specifying communication mechanisms > between gateways are beyond the scope of this work item. Specifying the > detailed contents of the "session ticket" is also beyond the scope of > this document; if there is sufficient interest, this could be specified > later in a separate document. > > To the degree its content falls within the scope of this work item, text > and ideas from draft-sheffer-ipsec-failover will be used as a starting > point. > > - A standards-track extension to IPsec that allows an IPsec remote > access gateway to redirect VPN clients to another gateway. This > extension should be aligned with the session resumption extension, > (the previous work item), and if so decided by the WG, could be > specified in the same document. The starting point will be > draft-devarapalli-ipsec-ikev2-redirect. > > - A standards-track mechanism that allows an intermediary device, such > as a firewall or intrusion detection system, to easily and reliably > determine whether an ESP packet is encrypted with the NULL cipher; and > if it is, determine the location of the actual payload data inside the > packet. The starting points for this work item are > draft-grewal-ipsec-traffic-visibility and draft-hoffman- > esp-null-protocol. > > The initial scope of the WG is restricted to the work items listed > above. The WG shall not consider adding new work items until one or more > of its documents progress to IESG evaluation. At that time, the WG can > propose rechartering. > > Chartering this WG is not intended to have effect on documents that > beyond the initial scope. In particular, work on IPsec extensions that > are not included in this charter can happen as usual in other WGs (and > there are currently several other WGs working on IPsec extensions; for > example, BTNS and ROHC), or as individual submissions. > > This charter will expire in July 2010 (24 months from approval). If > the charter is not updated before that time, the WG will be closed and > any remaining documents revert back to individual Internet-Drafts. > > Milestones: > > Dec 2008 WG last call on IPv6 configuration payloads > Dec 2008 WG last call on IPsec roadmap > Jan 2009 WG last call on session resumption > Feb 2009 WG last call on redirect > Mar 2009 WG last call on IKEv2bis > Apr 2009 WG last call on ESP NULL traffic visibility > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 28 11:23:51 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52E8C28C1D8; Mon, 28 Jul 2008 11:23:51 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87D023A6A99 for ; Mon, 28 Jul 2008 11:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gbXN5-OsFBr for ; Mon, 28 Jul 2008 11:23:40 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 294763A6A98 for ; Mon, 28 Jul 2008 11:23:39 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 09712294001; Mon, 28 Jul 2008 21:23:48 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 12DD02008F1; Mon, 28 Jul 2008 21:23:47 +0300 (IDT) Received: from [172.31.21.15] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m6SINijI005014; Mon, 28 Jul 2008 21:23:45 +0300 (IDT) Message-ID: <488E0EB0.3030003@checkpoint.com> Date: Mon, 28 Jul 2008 19:23:44 +0100 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Dan Harkins References: <20080624163001.66CF63A6A69@core3.amsl.com> <24824166c413680844268e1db43651cf.squirrel@www.trepanning.net> In-Reply-To: <24824166c413680844268e1db43651cf.squirrel@www.trepanning.net> Cc: ipsec@ietf.org Subject: Re: [IPsec] WG Review: IP Security Maintenance and Extensions (ipsecme) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1684105604==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1684105604== Content-Type: multipart/alternative; boundary="------------010008060209050408020407" This is a multi-part message in MIME format. --------------010008060209050408020407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Dan, I certainly have a remote access slant on this. My rationale is that you can have 100,000 clients to a RA gateway, but you rarely if ever have similar numbers in symmetric peer-to-peer IPsec. But I'm willing to be convinced otherwise. Regarding the ticket, we are in violent agreement. The trick is to design the ticket well enough to ensure it is used securely, while still allowing each vendor the freedom of defining their own IKE/IPsec state. The current draft is somewhat over-specified. I think all we need is (1) the minimal contents of the ticket, i.e. what pieces of the IKE state are required to be there and (2) how the ticket should be protected. Thanks, Yaron Dan Harkins wrote: > Hi, > > I'd like to take issue with part of this charter, specifically the > session resumption part. > > I'd like to see the work not be so "remote access" and "client" centric. > It's more of a generic problem and should have a generic solution. This > might just be a semantic hangup of mine (which is easily taken care of) > but I'd just like to ensure that the remote access slash VPN focus doesn't > constrain things. > > A bigger issue, though, concerns the construction of the "ticket". I'd > like to know why this is out-of-scope. I can see the possibility of > consensus forming in the WG around a document that does not specify > construction of the "ticket" but that doesn't mean the topic should be > out-of-scope. How the "ticket" get constructed will influence the security > of the scheme. A properly constructed "ticket" may even help address DoS > issues. This topic should be in scope. It seems very wrong that we would > generate a standards track document in the Security Area with a critical > component of the security of the proposal being left up to the imagination > of the guy implementing it. > > I've been going through the last couple weeks of postings and can't find > discussion and/or justification for making "ticket" construction > out-of-scope. > > regards, > > Dan. > > On Tue, June 24, 2008 9:30 am, IESG Secretary wrote: > >> A new IETF working group has been proposed in the Security Area. The IESG >> has not made any determination as yet. The following draft charter was >> submitted, and is provided for informational purposes only. Please send >> your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, July 1, >> 2008. >> >> >> IP Security Maintenance and Extensions (ipsecme) >> ------------------------------------------------ >> Last Modified: June 19, 2008 >> >> Current Status: Proposed Working Group >> >> Chair(s): TBD >> >> Mailing Lists: >> >> General Discussion: ipsec@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec >> Archive: http://www.ietf.org/mail-archive/web/ipsec/ >> >> The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated >> RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the IPsec >> security architecture (RFC 4301). IPsec is widely deployed in VPN >> gateways, VPN remote access clients, and as a substrate for >> host-to-host, host-to-network, and network-to-network security. >> >> The IPsec Maintenance and Extensions Working Group will continue the >> work of the earlier IPsec Working Group which was concluded in 2005. Its >> purpose is to maintain the IPsec standard and to facilitate discussion >> of clarifications, improvements, and extensions and improvements to >> IPsec, mostly to IKEv2. The working group will also be a focus point for >> other IETF Working Groups who use IPsec in their own protocols. >> >> The initial set of work items is: >> >> - A revision to IKEv2 (RFC 4306) that incorporates the clarifications >> from RFC 4718, and otherwise improves the quality of the specification, >> taking into account implementation and interoperability experience. In >> some cases, the revision may include small technical corrections; >> however, impact on existing implementations must be considered. Major >> changes and adding new features is beyond the scope of this work >> item. The starting point for this work is draft-hoffman-ikev2bis. >> >> - An IPsec document roadmap that describes the various RFC documents >> covering IPsec, including both the core RFC 240x and RFC 430x versions >> of IPsec, and extensions specified in other documents. Sections 2 and 3 >> of RFC 2411 can provide useful material, but the expected scope is >> slightly different from RFC 2411. This document will be informational. >> >> - A standards-track extension to IKEv2 that provides full IPv6 support >> for IPsec remote access clients that use configuration payloads. This >> work will be based on draft-eronen-ipsec-ikev2-ipv6-config. The WG shall >> solicit help and reviews from the 6MAN WG to ensure that all aspects of >> IPv6 are properly considered. >> >> - A standards-track extension that allows an IPsec remote access client >> to "resume" a session with a gateway; that is, to skip certain parts of >> IKE negotation when connecting again to the same gateway (or possibly a >> cluster of closely cooperating gateways). The idea is similar to TLS >> session resumption without server-side state, specified in RFC 5077. >> >> The main goals for this extension are to avoid public-key computations >> (to reduce VPN gateway load when a large number of clients reconnect to >> the geteway within a short period of time, such as following a network >> outage), and remove the need for user interaction for authentication >> (which may be required by some authentication mechanisms). The extension >> shall not have negative impact on IKEv2 security features. >> >> Failover from one gateway to another, mechanisms for detecting when a >> session should be resumed, and specifying communication mechanisms >> between gateways are beyond the scope of this work item. Specifying the >> detailed contents of the "session ticket" is also beyond the scope of >> this document; if there is sufficient interest, this could be specified >> later in a separate document. >> >> To the degree its content falls within the scope of this work item, text >> and ideas from draft-sheffer-ipsec-failover will be used as a starting >> point. >> >> - A standards-track extension to IPsec that allows an IPsec remote >> access gateway to redirect VPN clients to another gateway. This >> extension should be aligned with the session resumption extension, >> (the previous work item), and if so decided by the WG, could be >> specified in the same document. The starting point will be >> draft-devarapalli-ipsec-ikev2-redirect. >> >> - A standards-track mechanism that allows an intermediary device, such >> as a firewall or intrusion detection system, to easily and reliably >> determine whether an ESP packet is encrypted with the NULL cipher; and >> if it is, determine the location of the actual payload data inside the >> packet. The starting points for this work item are >> draft-grewal-ipsec-traffic-visibility and draft-hoffman- >> esp-null-protocol. >> >> The initial scope of the WG is restricted to the work items listed >> above. The WG shall not consider adding new work items until one or more >> of its documents progress to IESG evaluation. At that time, the WG can >> propose rechartering. >> >> Chartering this WG is not intended to have effect on documents that >> beyond the initial scope. In particular, work on IPsec extensions that >> are not included in this charter can happen as usual in other WGs (and >> there are currently several other WGs working on IPsec extensions; for >> example, BTNS and ROHC), or as individual submissions. >> >> This charter will expire in July 2010 (24 months from approval). If >> the charter is not updated before that time, the WG will be closed and >> any remaining documents revert back to individual Internet-Drafts. >> >> Milestones: >> >> Dec 2008 WG last call on IPv6 configuration payloads >> Dec 2008 WG last call on IPsec roadmap >> Jan 2009 WG last call on session resumption >> Feb 2009 WG last call on redirect >> Mar 2009 WG last call on IKEv2bis >> Apr 2009 WG last call on ESP NULL traffic visibility >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > > --------------010008060209050408020407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hi Dan,


I certainly have a remote access slant on this. My rationale is that you can have 100,000 clients to a RA gateway, but you rarely if ever have similar numbers in symmetric peer-to-peer IPsec. But I'm willing to be convinced otherwise.


Regarding the ticket, we are in violent agreement. The trick is to design the ticket well enough to ensure it is used securely, while still allowing each vendor the freedom of defining their own IKE/IPsec state. The current draft is somewhat over-specified. I think all we need is (1) the minimal contents of the ticket, i.e. what pieces of the IKE state are required to be there and (2) how the ticket should be protected.


Thanks,

    Yaron


Dan Harkins wrote:

  Hi,

  I'd like to take issue with part of this charter, specifically the
session resumption part.

  I'd like to see the work not be so "remote access" and "client" centric.
It's more of a generic problem and should have a generic solution. This
might just be a semantic hangup of mine (which is easily taken care of)
but I'd just like to ensure that the remote access slash VPN focus doesn't
constrain things.

  A bigger issue, though, concerns the construction of the "ticket". I'd
like to know why this is out-of-scope. I can see the possibility of
consensus forming in the WG around a document that does not specify
construction of the "ticket" but that doesn't mean the topic should be
out-of-scope. How the "ticket" get constructed will influence the security
of the scheme. A properly constructed "ticket" may even help address DoS
issues. This topic should be in scope. It seems very wrong that we would
generate a standards track document in the Security Area with a critical
component of the security of the proposal being left up to the imagination
of the guy implementing it.

  I've been going through the last couple weeks of postings and can't find
discussion and/or justification for making "ticket" construction
out-of-scope.

  regards,

  Dan.

On Tue, June 24, 2008 9:30 am, IESG Secretary wrote:
  
A new IETF working group has been proposed in the Security Area.  The IESG
has not made any determination as yet.  The following draft charter was
submitted, and is provided for informational purposes only.  Please send
your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, July 1,
2008.


IP Security Maintenance and Extensions (ipsecme)
------------------------------------------------
Last Modified: June 19, 2008

Current Status: Proposed Working Group

Chair(s): TBD

Mailing Lists:

General Discussion: ipsec@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec
Archive: http://www.ietf.org/mail-archive/web/ipsec/

The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated
RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the IPsec
security architecture (RFC 4301). IPsec is widely deployed in VPN
gateways, VPN remote access clients, and as a substrate for
host-to-host, host-to-network, and network-to-network security.

The IPsec Maintenance and Extensions Working Group will continue the
work of the earlier IPsec Working Group which was concluded in 2005. Its
purpose is to maintain the IPsec standard and to facilitate discussion
of clarifications, improvements, and extensions and improvements to
IPsec, mostly to IKEv2. The working group will also be a focus point for
other IETF Working Groups who use IPsec in their own protocols.

The initial set of work items is:

- A revision to IKEv2 (RFC 4306) that incorporates the clarifications
from RFC 4718, and otherwise improves the quality of the specification,
taking into account implementation and interoperability experience. In
some cases, the revision may include small technical corrections;
however, impact on existing implementations must be considered. Major
changes and adding new features is beyond the scope of this work
item. The starting point for this work is draft-hoffman-ikev2bis.

- An IPsec document roadmap that describes the various RFC documents
covering IPsec, including both the core RFC 240x and RFC 430x versions
of IPsec, and extensions specified in other documents. Sections 2 and 3
of RFC 2411 can provide useful material, but the expected scope is
slightly different from RFC 2411. This document will be informational.

- A standards-track extension to IKEv2 that provides full IPv6 support
for IPsec remote access clients that use configuration payloads. This
work will be based on draft-eronen-ipsec-ikev2-ipv6-config. The WG shall
solicit help and reviews from the 6MAN WG to ensure that all aspects of
IPv6 are properly considered.

- A standards-track extension that allows an IPsec remote access client
to "resume" a session with a gateway; that is, to skip certain parts of
IKE negotation when connecting again to the same gateway (or possibly a
cluster of closely cooperating gateways). The idea is similar to TLS
session resumption without server-side state, specified in RFC 5077.

The main goals for this extension are to avoid public-key computations
(to reduce VPN gateway load when a large number of clients reconnect to
the geteway within a short period of time, such as following a network
outage), and remove the need for user interaction for authentication
(which may be required by some authentication mechanisms). The extension
shall not have negative impact on IKEv2 security features.

Failover from one gateway to another, mechanisms for detecting when a
session should be resumed, and specifying communication mechanisms
between gateways are beyond the scope of this work item. Specifying the
detailed contents of the "session ticket" is also beyond the scope of
this document; if there is sufficient interest, this could be specified
later in a separate document.

To the degree its content falls within the scope of this work item, text
and ideas from draft-sheffer-ipsec-failover will be used as a starting
point.

- A standards-track extension to IPsec that allows an IPsec remote
access gateway to redirect VPN clients to another gateway. This
extension should be aligned with the session resumption extension,
(the previous work item), and if so decided by the WG, could be
specified in the same document. The starting point will be
draft-devarapalli-ipsec-ikev2-redirect.

- A standards-track mechanism that allows an intermediary device, such
as a firewall or intrusion detection system, to easily and reliably
determine whether an ESP packet is encrypted with the NULL cipher; and
if it is, determine the location of the actual payload data inside the
packet. The starting points for this work item are
draft-grewal-ipsec-traffic-visibility and draft-hoffman-
esp-null-protocol.

The initial scope of the WG is restricted to the work items listed
above. The WG shall not consider adding new work items until one or more
of its documents progress to IESG evaluation. At that time, the WG can
propose rechartering.

Chartering this WG is not intended to have effect on documents that
beyond the initial scope. In particular, work on IPsec extensions that
are not included in this charter can happen as usual in other WGs (and
there are currently several other WGs working on IPsec extensions; for
example, BTNS and ROHC), or as individual submissions.

This charter will expire in July 2010 (24 months from approval). If
the charter is not updated before that time, the WG will be closed and
any remaining documents revert back to individual Internet-Drafts.

Milestones:

Dec 2008 WG last call on IPv6 configuration payloads
Dec 2008 WG last call on IPsec roadmap
Jan 2009 WG last call on session resumption
Feb 2009 WG last call on redirect
Mar 2009 WG last call on IKEv2bis
Apr 2009 WG last call on ESP NULL traffic visibility
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

    


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Scanned by Check Point Total Security Gateway.
--------------010008060209050408020407-- --===============1684105604== 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://www.ietf.org/mailman/listinfo/ipsec --===============1684105604==-- From ipsec-bounces@ietf.org Mon Jul 28 12:02:28 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50C6328C1BA; Mon, 28 Jul 2008 12:02:28 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 730BF28C1BA for ; Mon, 28 Jul 2008 12:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBCFgwwQSfKS for ; Mon, 28 Jul 2008 12:02:23 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id EFD0E3A6B04 for ; Mon, 28 Jul 2008 12:02:01 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 0C45B1022408A; Mon, 28 Jul 2008 12:02:12 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 28 Jul 2008 12:02:12 -0700 (PDT) Message-ID: <780dff4f757609aceacc439d9809036a.squirrel@www.trepanning.net> In-Reply-To: <488E0EB0.3030003@checkpoint.com> References: <20080624163001.66CF63A6A69@core3.amsl.com> <24824166c413680844268e1db43651cf.squirrel@www.trepanning.net> <488E0EB0.3030003@checkpoint.com> Date: Mon, 28 Jul 2008 12:02:12 -0700 (PDT) From: "Dan Harkins" To: "Yaron Sheffer" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org, Dan Harkins Subject: Re: [IPsec] WG Review: IP Security Maintenance and Extensions (ipsecme) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Yaron, I concede that your problem is maybe 3 orders of magnitude greater than what I'm thinking about but there can also be cases of a "host" speaking transport mode IPsec to a couple hundred or more other "hosts" and a standard SA resumption mechanism would be beneficial. I also think it would be good if it worked both ways, that is either side or maybe both, could produce a "ticket". As long as this is just a semantic issue and it doesn't constrain the protocol I think we're fine but IPsec is not a remote access protocol and I don't think it would be good to extend it in ways that were solely remote access. I'm glad we're in violent agreement on the ticket construction. So how do we get this topic in scope? regards, Dan. On Mon, July 28, 2008 11:23 am, Yaron Sheffer wrote: > Hi Dan, > > > I certainly have a remote access slant on this. My rationale is that you > can have 100,000 clients to a RA gateway, but you rarely if ever have > similar numbers in symmetric peer-to-peer IPsec. But I'm willing to be > convinced otherwise. > > > Regarding the ticket, we are in violent agreement. The trick is to > design the ticket well enough to ensure it is used securely, while still > allowing each vendor the freedom of defining their own IKE/IPsec state. > The current draft is somewhat over-specified. I think all we need is (1) > the minimal contents of the ticket, i.e. what pieces of the IKE state > are required to be there and (2) how the ticket should be protected. > > > Thanks, > > Yaron > > > Dan Harkins wrote: > >> Hi, >> >> I'd like to take issue with part of this charter, specifically the >> session resumption part. >> >> I'd like to see the work not be so "remote access" and "client" >> centric. >> It's more of a generic problem and should have a generic solution. This >> might just be a semantic hangup of mine (which is easily taken care of) >> but I'd just like to ensure that the remote access slash VPN focus >> doesn't >> constrain things. >> >> A bigger issue, though, concerns the construction of the "ticket". I'd >> like to know why this is out-of-scope. I can see the possibility of >> consensus forming in the WG around a document that does not specify >> construction of the "ticket" but that doesn't mean the topic should be >> out-of-scope. How the "ticket" get constructed will influence the >> security >> of the scheme. A properly constructed "ticket" may even help address DoS >> issues. This topic should be in scope. It seems very wrong that we would >> generate a standards track document in the Security Area with a critical >> component of the security of the proposal being left up to the >> imagination >> of the guy implementing it. >> >> I've been going through the last couple weeks of postings and can't >> find >> discussion and/or justification for making "ticket" construction >> out-of-scope. >> >> regards, >> >> Dan. >> >> On Tue, June 24, 2008 9:30 am, IESG Secretary wrote: >> >>> A new IETF working group has been proposed in the Security Area. The >>> IESG >>> has not made any determination as yet. The following draft charter was >>> submitted, and is provided for informational purposes only. Please >>> send >>> your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, July >>> 1, >>> 2008. >>> >>> >>> IP Security Maintenance and Extensions (ipsecme) >>> ------------------------------------------------ >>> Last Modified: June 19, 2008 >>> >>> Current Status: Proposed Working Group >>> >>> Chair(s): TBD >>> >>> Mailing Lists: >>> >>> General Discussion: ipsec@ietf.org >>> To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec >>> Archive: http://www.ietf.org/mail-archive/web/ipsec/ >>> >>> The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated >>> RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the IPsec >>> security architecture (RFC 4301). IPsec is widely deployed in VPN >>> gateways, VPN remote access clients, and as a substrate for >>> host-to-host, host-to-network, and network-to-network security. >>> >>> The IPsec Maintenance and Extensions Working Group will continue the >>> work of the earlier IPsec Working Group which was concluded in 2005. >>> Its >>> purpose is to maintain the IPsec standard and to facilitate discussion >>> of clarifications, improvements, and extensions and improvements to >>> IPsec, mostly to IKEv2. The working group will also be a focus point >>> for >>> other IETF Working Groups who use IPsec in their own protocols. >>> >>> The initial set of work items is: >>> >>> - A revision to IKEv2 (RFC 4306) that incorporates the clarifications >>> from RFC 4718, and otherwise improves the quality of the specification, >>> taking into account implementation and interoperability experience. In >>> some cases, the revision may include small technical corrections; >>> however, impact on existing implementations must be considered. Major >>> changes and adding new features is beyond the scope of this work >>> item. The starting point for this work is draft-hoffman-ikev2bis. >>> >>> - An IPsec document roadmap that describes the various RFC documents >>> covering IPsec, including both the core RFC 240x and RFC 430x versions >>> of IPsec, and extensions specified in other documents. Sections 2 and 3 >>> of RFC 2411 can provide useful material, but the expected scope is >>> slightly different from RFC 2411. This document will be informational. >>> >>> - A standards-track extension to IKEv2 that provides full IPv6 support >>> for IPsec remote access clients that use configuration payloads. This >>> work will be based on draft-eronen-ipsec-ikev2-ipv6-config. The WG >>> shall >>> solicit help and reviews from the 6MAN WG to ensure that all aspects of >>> IPv6 are properly considered. >>> >>> - A standards-track extension that allows an IPsec remote access client >>> to "resume" a session with a gateway; that is, to skip certain parts of >>> IKE negotation when connecting again to the same gateway (or possibly a >>> cluster of closely cooperating gateways). The idea is similar to TLS >>> session resumption without server-side state, specified in RFC 5077. >>> >>> The main goals for this extension are to avoid public-key computations >>> (to reduce VPN gateway load when a large number of clients reconnect to >>> the geteway within a short period of time, such as following a network >>> outage), and remove the need for user interaction for authentication >>> (which may be required by some authentication mechanisms). The >>> extension >>> shall not have negative impact on IKEv2 security features. >>> >>> Failover from one gateway to another, mechanisms for detecting when a >>> session should be resumed, and specifying communication mechanisms >>> between gateways are beyond the scope of this work item. Specifying the >>> detailed contents of the "session ticket" is also beyond the scope of >>> this document; if there is sufficient interest, this could be specified >>> later in a separate document. >>> >>> To the degree its content falls within the scope of this work item, >>> text >>> and ideas from draft-sheffer-ipsec-failover will be used as a starting >>> point. >>> >>> - A standards-track extension to IPsec that allows an IPsec remote >>> access gateway to redirect VPN clients to another gateway. This >>> extension should be aligned with the session resumption extension, >>> (the previous work item), and if so decided by the WG, could be >>> specified in the same document. The starting point will be >>> draft-devarapalli-ipsec-ikev2-redirect. >>> >>> - A standards-track mechanism that allows an intermediary device, such >>> as a firewall or intrusion detection system, to easily and reliably >>> determine whether an ESP packet is encrypted with the NULL cipher; and >>> if it is, determine the location of the actual payload data inside the >>> packet. The starting points for this work item are >>> draft-grewal-ipsec-traffic-visibility and draft-hoffman- >>> esp-null-protocol. >>> >>> The initial scope of the WG is restricted to the work items listed >>> above. The WG shall not consider adding new work items until one or >>> more >>> of its documents progress to IESG evaluation. At that time, the WG can >>> propose rechartering. >>> >>> Chartering this WG is not intended to have effect on documents that >>> beyond the initial scope. In particular, work on IPsec extensions that >>> are not included in this charter can happen as usual in other WGs (and >>> there are currently several other WGs working on IPsec extensions; for >>> example, BTNS and ROHC), or as individual submissions. >>> >>> This charter will expire in July 2010 (24 months from approval). If >>> the charter is not updated before that time, the WG will be closed and >>> any remaining documents revert back to individual Internet-Drafts. >>> >>> Milestones: >>> >>> Dec 2008 WG last call on IPv6 configuration payloads >>> Dec 2008 WG last call on IPsec roadmap >>> Jan 2009 WG last call on session resumption >>> Feb 2009 WG last call on redirect >>> Mar 2009 WG last call on IKEv2bis >>> Apr 2009 WG last call on ESP NULL traffic visibility >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. >> >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 28 15:00:49 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9CB3A6B24; Mon, 28 Jul 2008 15:00:49 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C1BB3A6B24 for ; Mon, 28 Jul 2008 15:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXk6+aKjOUbj for ; Mon, 28 Jul 2008 15:00:47 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 083EF3A6B1E for ; Mon, 28 Jul 2008 15:00:47 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 99D06294002; Tue, 29 Jul 2008 01:00:56 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 8512D294001; Tue, 29 Jul 2008 00:59:02 +0300 (IDT) Received: from [172.31.21.146] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m6SLx0jI016215; Tue, 29 Jul 2008 00:59:01 +0300 (IDT) Message-Id: From: Yoav Nir To: Dan Harkins In-Reply-To: <24824166c413680844268e1db43651cf.squirrel@www.trepanning.net> Mime-Version: 1.0 (Apple Message framework v928.1) X-Priority: 3 (Normal) Date: Mon, 28 Jul 2008 22:58:59 +0100 References: <20080624163001.66CF63A6A69@core3.amsl.com> <24824166c413680844268e1db43651cf.squirrel@www.trepanning.net> X-Mailer: Apple Mail (2.928.1) Cc: ipsec@ietf.org Subject: Re: [IPsec] WG Review: IP Security Maintenance and Extensions (ipsecme) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1293454376==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1293454376== Content-Type: multipart/signed; boundary=Apple-Mail-1-604454414; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-1-604454414 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I don't really agree with this. Different vendors would want different things in the "ticket". So much so, that if we insist on including it, one of two things will happen: (1) We will fail to reach consensus or some vendors implement their own private version, or (2) We will end up with a monstrous structure with IETF-specified and vendor-specific extensions. Just as a for-instance, I'll give some examples of what may or may not be in the ticket: 1. My company makes VPN software that runs of commodity servers. These servers run on regular X86 processors and come with 100's of gigabytes of disk space. It's fairly easy for me to save the IKE SA to disk upon its creation, perhaps in a database with a unique 64-bit key, and send that 64-bit key as the "ticket". After a crash, the database is still there. Other vendors run on systems with either no disk or very limited disk space, sometimes flash-based. They can't store their SAs on disk. 2. With AAA servers you sometimes get authorization information from the server during the log-in process. In such a case, the ticket (or its persistent record) must hold the authorization information (you either can't or don't want to query the AAA server for that information during resumption). Other vendors may not rely on AAA servers for authorization. 3. User identity may sometimes be stored as a simple string (ASCII or UTF8), as a DN, as an email address extracted from the DN or from an alternate name in the certificate, or we may want to keep the user identity as their public key. Since failover from one gateway to another is out of scope, let alone a failover from one gateway to a gateway made by a different vendor, interoperability does not suffer by not specifying a ticket. We can and should specify security considerations and what data the gateway should be able to reconstruct based on the ticket, but format should be out of scope. On Jul 28, 2008, at 7:04 PM, Dan Harkins wrote: > > Hi, > > A bigger issue, though, concerns the construction of the "ticket". > I'd > like to know why this is out-of-scope. I can see the possibility of > consensus forming in the WG around a document that does not specify > construction of the "ticket" but that doesn't mean the topic should be > out-of-scope. How the "ticket" get constructed will influence the > security > of the scheme. A properly constructed "ticket" may even help address > DoS > issues. This topic should be in scope. It seems very wrong that we > would > generate a standards track document in the Security Area with a > critical > component of the security of the proposal being left up to the > imagination > of the guy implementing it. --Apple-Mail-1-604454414 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEAJIh/K+B1TMJ8nzoNjVff4wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDkwNDEzMzAzN1oXDTA4MDkwMzEzMzAz N1owRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANk5dX7Jjgb3 WcWBXGkva0ksYj49cHGta9zLei/8L36hnOgHfChX7jMU1scWGg4fA6v43SGB32/bjtioMt4FDazd MR/yqYykPSZ82X6MIDd/hqXJy2kWlLEzELy4UymxoBtZV0Woea0gO4rObjgQDf2JsacEt9Qxi+77 BA3W931iG2sjue0KdRx6xX3U1pwgx0M81fZ54gFgAhMlCf8AVqCgL6bv+HYAc2j4XjSGFjODjNyp n2Pumc9TVkj2uxmV+mMtclIhbXPy/5z0wg83ttnIfcI9cTKI88407fHTaUKmXf4Vhdp/NhbuHZWH bCBOMP0AiefcmvdGfqJc7o3JOYsCAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADEczlw8AJPiBRktBh113TwJrqL9 MeyaI+FB1yFUamAtd1i/Db0l9Xeb6iOK1M/MWwLbXTWBWxwhe3q7sayp8BZPJsLfBDyb1MYi8yGC ieBEatY6nP1Yy9KELX8frAfJ038FFw/rP2IqvUa2gxS0LW0vrgOg8hB1fRAUTlOr3MSDMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhACSIfyvgdUzCfJ86DY1X3+MAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDcyODIx NTg1OVowIwYJKoZIhvcNAQkEMRYEFK+uzMfo50J5AQwBr4pER9HDkYsiMIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQAkiH8r4HVMwn yfOg2NV9/jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQAkiH8r4HVMwnyfOg2NV9/jANBgkqhkiG9w0BAQEFAASCAQAf0kPNucd3 mCKaD2+f2WwOjZvaUpDa7sNc1S7oozBjNRXbtbizAzoixEfoXS+n/OJU5axRL7PLoWnMVy36gEWK 8YM6JYU9p56cHKW6wh/L4ClT77tttmrRfwJ/TIja5FIuq35kOcYIJ1BtCorr7S4bfpqE8iarWUYY O2hsrMD0IMKMjHNK2L7qiWOnFHwxJHxUKR3FIpFgRKwrijhIj/3UgLN1ciQp3vrhmA9/V3feXpQ4 hFab3p7l/xw6h+k9vjS0zrX7qsGT6132hYcDBD30omoZmhslaTHXtJTsuHeovKn2cFuPFSbWCGJA r1ZSbd1vr2CYhYsJ25OjKY8WwlY8AAAAAAAA --Apple-Mail-1-604454414-- --===============1293454376== 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://www.ietf.org/mailman/listinfo/ipsec --===============1293454376==-- From ipsec-bounces@ietf.org Mon Jul 28 16:19:05 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B36C528C226; Mon, 28 Jul 2008 16:19:05 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA05F28C226 for ; Mon, 28 Jul 2008 16:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YApWoW0jTdUN for ; Mon, 28 Jul 2008 16:19:03 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id A854F28C21F for ; Mon, 28 Jul 2008 16:19:03 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6FFD61022408C; Mon, 28 Jul 2008 16:19:14 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 28 Jul 2008 16:19:14 -0700 (PDT) Message-ID: <7783b00871110e39a0fa7f2f9b751a56.squirrel@www.trepanning.net> In-Reply-To: References: <20080624163001.66CF63A6A69@core3.amsl.com> <24824166c413680844268e1db43651cf.squirrel@www.trepanning.net> Date: Mon, 28 Jul 2008 16:19:14 -0700 (PDT) From: "Dan Harkins" To: "Yoav Nir" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org, Dan Harkins Subject: Re: [IPsec] WG Review: IP Security Maintenance and Extensions (ipsecme) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Yoav, I don't want to dictate the components of the ticket to vendors. The components of a ticket have to make sense to the recipient (presumably the creator) of the ticket and in that sense it's a blob opaque to all but the intended recipient. If you have special sauce that accompanies an IPsec or IKE SA then, by all means, include the special sauce in your ticket. There should be a minimum-- a key and any authorization information bound to the key or that constrains use of the key-- but after that you can add whatever you want. But for this to be a secure protocol there should be some security requirements around the ticket. Such as: 0. the ticket must be unforgeable. 1. (a portion of) the ticket MUST be indistinguishable from random by everyone except the intended recipient. 2. the ticket MUST be bound to a peer and it MUST NOT be possible for one peer's ticket to be used by another peer. 3. the peer must prove knowledge of the key wrapped in the ticket when performing session resumption. To enforce adherence to those requirements we should specify how the ticket gets constructed (which is not the same as what it's constructed with). Your example was to send the 64-bit index into a database as the ticket. I'm sure that's not what you propose to do and was just an example but it illustrates why we need some base requirements around construction of the ticket. Such a ticket is forgeable and nothing binds a peer to such a ticket. The scheme would probably rely on layers of checks ("is the claimed sender of this ticket the same as the address in the SA pointed to by this ticket index?", etc) to ensure the ticket isn't misused instead of having a robust cryptographic check to ensure proper ticket usage. Another bad example of ticket creation would be to create a keystream with a hash function, seeded with some password, and XOR the keystream with each ticket to create the opaque blob. A naive implementor who is not security savvy might come up with such a scheme. We should prevent someone from claiming compliance with a standards track RFC from the Security Area of the IETF if they have such a lame scheme. This is a security protocol and we should make sure it's secure. To do so we should specify _minimum_ behavior to comply with reasonable security requirements. A base blob communication protocol whose entire security is left up to the imagination of the implementor is not what a standards track RFC out of the Security Area of the IETF should be, in my opinion anyway. regards, Dan. On Mon, July 28, 2008 2:58 pm, Yoav Nir wrote: > I don't really agree with this. Different vendors would want different > things in the "ticket". So much so, that if we insist on including it, > one of two things will happen: (1) We will fail to reach consensus or > some vendors implement their own private version, or (2) We will end > up with a monstrous structure with IETF-specified and vendor-specific > extensions. > > Just as a for-instance, I'll give some examples of what may or may not > be in the ticket: > 1. My company makes VPN software that runs of commodity servers. These > servers run on regular X86 processors and come with 100's of gigabytes > of disk space. It's fairly easy for me to save the IKE SA to disk upon > its creation, perhaps in a database with a unique 64-bit key, and send > that 64-bit key as the "ticket". After a crash, the database is still > there. Other vendors run on systems with either no disk or very > limited disk space, sometimes flash-based. They can't store their SAs > on disk. > 2. With AAA servers you sometimes get authorization information from > the server during the log-in process. In such a case, the ticket (or > its persistent record) must hold the authorization information (you > either can't or don't want to query the AAA server for that > information during resumption). Other vendors may not rely on AAA > servers for authorization. > 3. User identity may sometimes be stored as a simple string (ASCII or > UTF8), as a DN, as an email address extracted from the DN or from an > alternate name in the certificate, or we may want to keep the user > identity as their public key. > > Since failover from one gateway to another is out of scope, let alone > a failover from one gateway to a gateway made by a different vendor, > interoperability does not suffer by not specifying a ticket. We can > and should specify security considerations and what data the gateway > should be able to reconstruct based on the ticket, but format should > be out of scope. > > On Jul 28, 2008, at 7:04 PM, Dan Harkins wrote: > >> >> Hi, > > > >> >> A bigger issue, though, concerns the construction of the "ticket". >> I'd >> like to know why this is out-of-scope. I can see the possibility of >> consensus forming in the WG around a document that does not specify >> construction of the "ticket" but that doesn't mean the topic should be >> out-of-scope. How the "ticket" get constructed will influence the >> security >> of the scheme. A properly constructed "ticket" may even help address >> DoS >> issues. This topic should be in scope. It seems very wrong that we >> would >> generate a standards track document in the Security Area with a >> critical >> component of the security of the proposal being left up to the >> imagination >> of the guy implementing it. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 28 17:07:31 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA79B28C1DF; Mon, 28 Jul 2008 17:07:30 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8842928C206 for ; Mon, 28 Jul 2008 17:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBoz7r9RzeYt for ; Mon, 28 Jul 2008 17:07:28 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id CA76A3A68D0 for ; Mon, 28 Jul 2008 17:07:27 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m6T07TLw026700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 03:07:29 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m6T07TYs014461; Tue, 29 Jul 2008 03:07:29 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18574.24385.37955.850321@fireball.kivinen.iki.fi> Date: Tue, 29 Jul 2008 03:07:29 +0300 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: <7783b00871110e39a0fa7f2f9b751a56.squirrel@www.trepanning.net> References: <20080624163001.66CF63A6A69@core3.amsl.com> <24824166c413680844268e1db43651cf.squirrel@www.trepanning.net> <7783b00871110e39a0fa7f2f9b751a56.squirrel@www.trepanning.net> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 9 min X-Total-Time: 9 min Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] WG Review: IP Security Maintenance and Extensions (ipsecme) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Dan Harkins writes: > Your example was to send the 64-bit index into a database as the ticket. > I'm sure that's not what you propose to do and was just an example but > it illustrates why we need some base requirements around construction of > the ticket. Such a ticket is forgeable and nothing binds a peer to such > a ticket. The scheme would probably rely on layers of checks ("is the > claimed sender of this ticket the same as the address in the SA pointed > to by this ticket index?", etc) to ensure the ticket isn't misused instead > of having a robust cryptographic check to ensure proper ticket usage. Running index would be perfectly good ticket and would be perfectly secure. The initiator doing the resumption will give that ticket to the responder, responder will look up the keys and other material from the database, and then decrypt the rest of the encrypted message and verify the integrity of it. After that it will mark the index in the database as "used" so it cannot be used anymore. The initiator has proven the knowledge of the key associated to the ticket (but not wrapped in to the ticket, as it was in the database instead) by being able to create the encrypted and integrity protected parts of the message. Any other peer would be knowing the keys to generate cryptographically integrity portected message so that should prevent anybody else using the ticket (unless the original party of the initial IKE SA creation gives out the keys). I do not understand why the ticket must be unforgeable or why it must be indistinguishable from random? Those requirements do not make any sense for me in this kind of database case. Anybody can see the ticket immediately when it is first time used and attacker just needs to read the ticket from there and block those packets from reaching the recipient and then he can use the ticket if that would be the only protection on the ticket. The real protection is that only valid party can create the cryptographacally protected part of the message. > Another bad example of ticket creation would be to create a keystream > with a hash function, seeded with some password, and XOR the keystream > with each ticket to create the opaque blob. A naive implementor who is > not security savvy might come up with such a scheme. We should prevent > someone from claiming compliance with a standards track RFC from the > Security Area of the IETF if they have such a lame scheme. Yes, that would be very bad ticket. The vendor could also post those tickets and their decrypted content to the wikipedia for storage, and that would also be bad way to do tickets, but I still do not think we need to add rules forbidding that... > This is a security protocol and we should make sure it's secure. To do > so we should specify _minimum_ behavior to comply with reasonable security > requirements. A base blob communication protocol whose entire security > is left up to the imagination of the implementor is not what a standards > track RFC out of the Security Area of the IETF should be, in my opinion > anyway. But as has been pointed out the ticket might not be just opaque blob communication, it could also be representated as handle to some internal persistent data structure. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 28 17:09:41 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB74328C282; Mon, 28 Jul 2008 17:09:41 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D847628C282 for ; Mon, 28 Jul 2008 17:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[AWL=-2.900, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_42=0.6, MANGLED_HERE=2.3, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 082LKiM6hAw5 for ; Mon, 28 Jul 2008 17:09:36 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 429E428C224 for ; Mon, 28 Jul 2008 17:09:31 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m6T09eq1023612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 Jul 2008 03:09:40 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m6T09esW023927; Tue, 29 Jul 2008 03:09:40 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18574.24516.764629.590327@fireball.kivinen.iki.fi> Date: Tue, 29 Jul 2008 03:09:40 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 3 min X-Total-Time: 2 min Subject: [IPsec] Some (ok, a lot) comments to ikev2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Here is my comments to the draft-hoffman-ikev2bis-03.txt. As Pasi said I need to include new text for all of them before they will be accepted, I had to make this email quite long... Still wasn't manage to include new text for all of my comments, but I hope the editors can still understand and accept even those comments :-) ---------------------------------------------------------------------- > Internet Key Exchange Protocol: IKEv2 > draft-hoffman-ikev2bis-03 ... > 1. Introduction > > IKE performs mutual authentication between two parties and > establishes an IKE security association (SA) that includes shared > secret information that can be used to efficiently establish SAs for > Encapsulating Security Payload (ESP) [ESP] and/or Authentication > Header (AH) [AH] and a set of cryptographic algorithms to be used by > the SAs to protect the traffic that they carry. In this document, > the term "suite" or "cryptographic suite" refers to a complete set of > algorithms used to protect an SA. An initiator proposes one or more > suites by listing supported algorithms that can be combined into > suites in a mix-and-match fashion. IKE can also negotiate use of IP > Compression (IPComp) [IPCOMP] in connection with an ESP and/or AH SA. > We call the IKE SA an "IKE_SA". The SAs for ESP and/or AH that get > set up through that IKE_SA we call "CHILD_SAs". I think all of those "ESP and/or AH" should be changed to "ESP or AH" just to clarify that there cannot bve combined ESP and AH, so s/and\/or/or/g; > The second request/response (IKE_AUTH) transmits identities, proves > knowledge of the secrets corresponding to the two identities, and > sets up an SA for the first (and often only) AH and/or ESP CHILD_SA. Should already say here that even if the child sa creation fails in here, the IKE sa is created and stays up i.e: The second request/response (IKE_AUTH) transmits identities, proves knowledge of the secrets corresponding to the two identities, and sets up an SA for the first (and often only) AH or ESP CHILD_SA (unless there is failure setting up the AH or ESP CHILD_SA, in which case the IKE SA is still established without IPsec SA). > 1.2. The Initial Exchanges ... > HDR, SK {IDi, [CERT,] [CERTREQ,] > [IDr,] AUTH, SAi2, > TSi, TSr} --> > > The initiator asserts its identity with the IDi payload, proves > knowledge of the secret corresponding to IDi and integrity protects > the contents of the first message using the AUTH payload (see > Section 2.15). It might also send its certificate(s) in CERT > payload(s) and a list of its trust anchors in CERTREQ payload(s). If > any CERT payloads are included, the first certificate provided MUST > contain the public key used to verify the AUTH field. The optional > payload IDr enables the initiator to specify which of the responder's > identities it wants to talk to. This is useful when the machine on > which the responder is running is hosting multiple identities at the > same IP address. The initiator begins negotiation of a CHILD_SA I think we might want to say something about here that IDr is only hint for the responder of which ID to use, i.e if the IDr is not acceptable for the responder, he might use some other IDr on the next packet and finish the exchange (as they have already done some of the expensive calculations, like Diffie-Hellman). If the initiator then does not accept that fact that responder used different IDr that which was requested, it can close the SA after noticing the fact. > same IP address. The initiator begins negotiation of a CHILD_SA > using the SAi2 payload. The final fields (starting with SAi2) are > described in the description of the CREATE_CHILD_SA exchange. > > <-- HDR, SK {IDr, [CERT,] AUTH, > SAr2, TSi, TSr} > > The responder asserts its identity with the IDr payload, optionally > sends one or more certificates (again with the certificate containing > the public key used to verify AUTH listed first), authenticates its > identity and protects the integrity of the second message with the > AUTH payload, and completes negotiation of a CHILD_SA with the > additional fields described below in the CREATE_CHILD_SA exchange. > > The recipients of messages 3 and 4 MUST verify that all signatures > and MACs are computed correctly and that the names in the ID payloads > correspond to the keys used to generate the AUTH payload. > > {{ Clarif-4.2}} If creating the CHILD_SA during the IKE_AUTH exchange > fails for some reason, the IKE_SA is still created as usual. The > list of responses in the IKE_AUTH exchange that do not prevent an > IKE_SA from being set up include at least the following: > NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, > INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. In the case of the that kind of failure the return packet will then be without the SAr2, Tsi, and TSr, i.e.: <-- HDR, SK {IDr, [CERT,] AUTH, N(error_for_child_sa)} If the authentication fails in such ways that the entries cannot create IKE SA (authentication failure or similar), then the response will be unencrypted, unauthenticated notify. There is no point of sending the notify encrypted and integrity protected, as it is not authenticated (as initiator and responder have not yet verified the AUTH payloads): <-- HDR, N(error_for_ike_sa) The initiator receiving such reply MUST NOT immediately stop the SA creation, but it should still retransmit the message few times, in case that error notify was forgery and the real responder will reply with valid reply. It can use the recipient of such message as a hint to tell that authentication failed, thus it can shorten the retransmission timers from few minutes down to few tens of seconds. > 1.3. The CREATE_CHILD_SA Exchange ... > The CREATE_CHILD_SA response for creating a new CHILD_SA is: > > <-- HDR, SK {SA, Nr, [KEr], > TSi, TSr} > > The responder replies (using the same Message ID to respond) with the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is confusing, as we have not introduced message id at all at this point. I suggest removing the "(using the same Message ID to respond)". > 1.3.2. Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange > > The CREATE_CHILD_SA request for rekeying an IKE_SA is: > > Initiator Responder > ------------------------------------------------------------------- > HDR, SK {SA, Ni, [KEi]} --> > > The initiator sends SA offer(s) in the SA payload, a nonce in the Ni > payload, and a Diffie-Hellman value in the KEi payload. The KEi > payload SHOULD be included. New initiator and responder SPIs are > supplied in the SPI fields. Add text where the SPIs fields are: New initiator and responder SPIs are supplied in the SPI fields, of SA payload. > The CREATE_CHILD_SA response for rekeying an IKE_SA is: > > <-- HDR, SK {SA, Nr,[KEr]} > > The responder replies (using the same Message ID to respond) with the Same here with the "using the same Message ID to respond)". > 1.3.3. Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange ... > {{ 3.10.1-16393 }} The REKEY_SA notification MUST be included in a > CREATE_CHILD_SA exchange if the purpose of the exchange is to replace > an existing ESP or AH SA. {{ Clarif-5.4 }} The SA being rekeyed is > identified by the SPI field in the Notify payload; this is the SPI > the exchange initiator would expect in inbound ESP or AH packets. > There is no data associated with this Notify type. Add clarification here specifying the value of the Protocol ID field: The Protocol ID field of REKEY_SA notify is set accordingly to ESP (3) or AH (2). > The CREATE_CHILD_SA response for rekeying a CHILD_SA is: > > <-- HDR, SK {SA, Nr, [KEr], > Si, TSr} There is missing T in the picture: <-- HDR, SK {SA, Nr, [KEr], TSi, TSr} > The responder replies (using the same Message ID to respond) with the Again the "using the same Message ID to respond)". > accepted offer in an SA payload, and a Diffie-Hellman value in the > KEr payload if KEi was included in the request and the selected > cryptographic suite includes that group. > > The traffic selectors for traffic to be sent on that SA are specified > in the TS payloads in the response, which may be a subset of what the > initiator of the CHILD_SA proposed. Add comment about which traffic selectors to use in the rekeying: When doing rekeying the traffic selectors SHOULD come from the original decorrelated policy, i.e. not the same traffic selectors which the old SA had in case the responder narrowed them, but from the policy which initiator used originally to create the IPsec SA. This allows the SA to expand to full traffic selector set allowed by latest (perhaps changed) policy. Also I think we should mention that the traffic selectors for the rekying should have those selectors from the packet (see section 2.9): To allow responder to do intelligent narrowing of the traffic selector the responder should know which packet triggered the rekeying, so it will not narrow the traffic selectors to set which is not usable for the packet triggering the rekeying. This means that even the traffic selectors for the rekeying needs to have those selectors from the packet (see section 2.9). Note, that if the responders policy has changed, it is possible that originally traffic that fit to one SA cannot fit to one SA anymore, which means the responder will narrow the traffic selectors so that not all original traffic fits to SA anymore. In that case the initiator getting packet that only fits the old SA (which is waiting to be deleted) but not new, should create new SA for this traffic too (but it is not rekeying anymore, so no REKEY_SA notify is included in the exchange). Same thing happens when the original SA expires, and one ends gets packet which not fit the current traffic selectors, but instead triggers new SA creation. > 1.5. Informational Messages outside of an IKE_SA ... > {{ 3.10.1-11 }} The INVALID_SPI notification MAY be sent in an IKE > INFORMATIONAL exchange when a node receives an ESP or AH packet with > an invalid SPI. The Notification Data contains the SPI of the > invalid packet. This usually indicates a node has rebooted and > forgotten an SA. If this Informational Message is sent outside the > context of an IKE_SA, it should only be used by the recipient as a > "hint" that something might be wrong (because it could easily be > forged). If the notification data is used for the SPI of the invalid packet, how can the recipient of such notify know whether that SPI was for ESP or AH? As far as I can see, it cannot, but I think it does not matter as SPIs are now supposed to be unique (i.e. protocol is no loger include as key). Perhaps we should just note this fact here? > {{ Clarif-7.7 }} There are two cases when such a one-way notification > is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are > sent outside of an IKE_SA. Note that such notifications are > explicitly not Informational exchanges; these are one-way messages > that must not be responded to. In case of INVALID_IKE_SPI, the > message sent is a response message, and thus it is sent to the IP > address and port from whence it came with the same IKE SPIs and the > Message ID copied. In case of INVALID_SPI, however, there are no IKE > SPI values that would be meaningful to the recipient of such a > notification. Using zero values or random values are both > acceptable. In a sense INVALID_MAJOR_VERSION is also this kind of notification which is sent outside of an IKE_SA, altought it is sent as a response to the incoming IKE SA creation. Perhaps we should note this fact here? > 1.6. Requirements Terminology ... > IKEv2 (and IKEv1) developers have noted that there is a great deal of > material in the tables of codes in Section 3.10.1. This leads to > implementers not having all the needed information in the main body > of the docment. Much of the material from those tables has been ^^^^^^^ Typo. > 2.1. Use of Retransmission Timers ... > For every pair of IKE messages, the initiator is responsible for > retransmission in the event of a timeout. The responder MUST never > retransmit a response unless it receives a retransmission of the > request. In that event, the responder MUST ignore the retransmitted > request except insofar as it triggers a retransmission of the > response. The initiator MUST remember each request until it receives > the corresponding response. The responder MUST remember each > response until it receives a request whose sequence number is larger > than or equal to the sequence number in the response plus its window > size (see Section 2.3). One of the problems here is that if we are using large window size, we have to keep that many messages for ever. It would be nice, we the responder of the request, could forget the response packet after lets say 10 minutes after it sent it out to requestor. There is no reason why the other end should be allowed to resend his request 4 hours later and expect that other end can still resend reply back. So suggest adding: Responder are allowed to forget response after long timeout for the memory saving purposes. The timeout must be longer than several minutes that could be used for the retransmission timers of the other end. > IKE is a reliable protocol, in the sense that the initiator MUST > retransmit a request until either it receives a corresponding reply > OR it deems the IKE security association to have failed and it > discards all state associated with the IKE_SA and any CHILD_SAs > negotiated using that IKE_SA. > > {{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require > some special handling. When a responder receives an IKE_SA_INIT > request, it has to determine whether the packet is retransmission > belonging to an existing "half-open" IKE_SA (in which case the > responder retransmits the same response), or a new request (in which > case the responder creates a new IKE_SA and sends a fresh response), > or it belongs to an existing IKE_SA where the IKE_AUTH request has > been already received (in which case the responder ignores it). There is also the case of the invalid ke and cookie notifies, i.e we need to add comment about those too: ... or it belongs to an existing IKE_SA where the IKE_AUTH request has been already received (in which case the responder ignores it), or it is INVALID_KE_PAYLOAD or COOKIE notify responses to the IKE_SA_INIT request. > It is not sufficient to use the initiator's SPI and/or IP address to > differentiate between these three cases because two different peers > behind a single NAT could choose the same initiator SPI. Instead, a > robust responder will do the IKE_SA lookup using the whole packet, > its hash, or the Ni payload. We might want to also explicitly say that the retransmissions from the initiator MUST be bitwise identicdal to the original request. We do say that for the responses, but I do not think we have explicit text about for the requests. > 2.2. Use of Sequence Numbers for Message ID > > The Message ID is a 32-bit quantity, which is zero for the > IKE_SA_INIT messages (including retries of the message due to > responses such as COOKIE and INVALID_KE_PAYLOAD {{ Clarif-2.2 }}), > and incremented for each subsequent exchange. Add text: The Message ID is reset to zero also after IKE SA rekey for the new IKE SA. > Note that Message IDs are cryptographically protected and provide > protection against message replays. In the unlikely event that > Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be > closed. Rekeying an IKE_SA resets the sequence numbers. ^ or rekeyed. > 2.3. Window Size for Overlapping Requests ... > An IKE endpoint MUST wait for a response to each of its messages > before sending a subsequent message unless it has received a > SET_WINDOW_SIZE Notify message from its peer informing it that the > peer is prepared to maintain state for multiple outstanding messages > in order to allow greater throughput. Or the text about allowed to forget responses after some long time could be here too instead of the section 2.1. > 2.4. State Synchronization and Connection Timeouts ... > payload that contains no payloads). If a cryptographically protected > message has been received from the other side recently, unprotected > notifications MAY be ignored. Implementations MUST limit the rate at > which they take actions based on unprotected messages. I suggest adding "fresh" to the sentence there i.e.: If a cryptographically protected fresh (i.e. not retransmissions) message has been received from the other side recently, unprotected notifications MAY be ignored > 2.5. Version Numbers and Forward Compatibility ... > IKEv2 adds a "critical" flag to each payload header for further > flexibility for forward compatibility. If the critical flag is set > and the payload type is unrecognized, the message MUST be rejected > and the response to the IKE request containing that payload MUST > include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an > unsupported critical payload was included. {{ 3.10.1-1 }} In that > Notify payload, the notification data contains the one-octet payload > type. If the critical flag is not set and the payload type is > unsupported, that payload MUST be ignored. Payloads sent in IKE > response messages MUST NOT have the critical flag set. Note that the > critical flag applies only to the payload type, not the contents. If > the payload type is recognized, but the payload contains something > which is not (such as an unknown transform inside an SA payload, or > an unknown Notify Message Type inside a Notify payload), the critical > flag is ignored. What if such UNSUPPORTED_CRITICAL_PAYLOAD error happens during the initial IKE_SA_INIT message, or do we forbid enchancements and modifications which might cause such error? > NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in the > order shown in the figures in Section 2? Can we eliminate the > requirement in the following paragraph? If not, we will probably > have to add a new appendix with the order, but there is no reason to > do that if no one actually cares. {{ Remove this paragraph before the > document is finalized, of course. }} Our implemnentation do not care about the order of the payloads except in some specific places (CERT payloads and so on). > {{ Demoted the SHOULD in the second clause }}Although new payload > types may be added in the future and may appear interleaved with the > fields defined in this specification, implementations MUST send the > payloads defined in this specification in the order shown in the > figures in Section 2; implementations are explicitly allowed to > reject as invalid a message with those payloads in any other order. I would really like to change this to say that payloads must be accepted in any order, but implementations should try to send them out in the order shown in the figures. Exceptions to this is the CERT payloads (the end entity cert MUST be first), and REKEY and COOKIE notifies. > 2.6. Cookies This should probably be renamed to "IKE SA SPIs and Cookies". > Unlike ESP and AH where only the recipient's SPI appears in the > header of a message, in IKE the sender's SPI is also sent in every > message. Since the SPI chosen by the original initiator of the > IKE_SA is always sent first, an endpoint with multiple IKE_SAs open > that wants to find the appropriate IKE_SA using the SPI it assigned > must look at the I(nitiator) Flag bit in the header to determine > whether it assigned the first or the second eight octets. Our implementation originally only checked its own SPI half, and didn't verify that the other ends SPI half didn't change. This was found out in the interop, and we fixed it to check the other ends SPI also, but I wonder should we say one way or the other here? Also what SPI should the response have, i.e. the SPIs from the request, or the SPIs from the original IKE SA creation. I think it might be easier to just say, that implementations can use their own SPI to find the IKE SA data, but MUST also check that the other ends SPI matches the SPIs stored with IKE SA data. ... > A good way to do this is to set the responder cookie to be: > > Cookie = | Hash(Ni | IPi | SPIi | ) I was starting to wonder if that Cookie should also include the Port part, especially in the NAT-T case? > where is a randomly generated secret known only to the > responder and periodically changed and | indicates concatenation. > should be changed whenever is > regenerated. The cookie can be recomputed when the IKE_SA_INIT > arrives the second time and compared to the cookie in the received > message. If it matches, the responder knows that the cookie was > generated since the last change to and that IPi must be the > same as the source address it saw the first time. Incorporating SPIi > into the calculation ensures that if multiple IKE_SAs are being set > up in parallel they will all get different cookies (assuming the > initiator chooses unique SPIi's). Incorporating Ni into the hash The real reason to hash the SPIs to the cookie is to make sure that attacker cannot fetch one one cookie from the other end, and then initiate 100 IKE_SA_INIT exchanges all with different initiator SPIs (and perhaps port numbers) so that the for the responder it looked like there is lots of machines behind one NAT box who are all trying to connect. As the cookie is tied to the SPIi the attacker cannot use cookie multiple times. > {{ Clarif-2.5 }} When one party receives an IKE_SA_INIT request > containing a cookie whose contents do not match the value expected, > that party MUST ignore the cookie and process the message as if no > cookie had been included; usually this means sending a response > containing a new cookie. We might want to add text here saying: Initiator should limit the number of cookie exchanges it tries before giving up, especially as if the attacker decides to forge multiple cookie responses to the initiators IKE_SA_INIT message, each of those forged cookie reply will trigger 2 packets, one packet from the initiator to the responder (which will reject those cookies), and one reply from responder to initiator giving out correct cookie. > 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD > > {{ This section added by Clarif-2.4 }} > > There are two common reasons why the initiator may have to retry the > IKE_SA_INIT exchange: the responder requests a cookie or wants a > different Diffie-Hellman group than was included in the KEi payload. > If the initiator receives a cookie from the responder, the initiator > needs to decide whether or not to include the cookie in only the next > retry of the IKE_SA_INIT request, or in all subsequent retries as > well. > > If the initiator includes the cookie only in the next retry, one > additional roundtrip may be needed in some cases. An additional > roundtrip is needed also if the initiator includes the cookie in all > retries, but the responder does not support this. For instance, if > the responder includes the SAi1 and KEi payloads in cookie > calculation, it will reject the request by sending a new cookie. > > If both peers support including the cookie in all retries, a slightly > shorter exchange can happen. Implementations SHOULD support this > shorter exchange, but MUST NOT fail if other implementations do not > support this shorter exchange. We should also explain better what this slightly shorter exchange is, and what other options there are. I think clarification had more text about this that could be copied her.e > 2.7. Cryptographic Algorithm Negotiation ... > Each IPsec protocol proposal contains one or more transforms. Each > transform contains a transform type. The accepted cryptographic > suite MUST contain exactly one transform of each type included in the > proposal. For example: if an ESP proposal includes transforms > ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, > AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one > of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six > combinations are acceptable. Perhaps we should add here paragraph explaining the most common reason of the multiple propsoals: If both combined mode ciphers and normal ciphers with integrity protection needs to be proposed, the inititor needs to use two proposals. One of them includes all the combined mode ciphers, without the integrity algorithms (as combined mode ciphers are not allowed to have any other integrity algorithm than none), and the another includes normal ciphers and the integrity algoritms for them. > 2.8. Rekeying ... > {{ Demoted the SHOULD }} The node that initiated the surviving > rekeyed SA should delete the replaced SA after the new one is > established. I think this paragraph is in bit funny place, perhaps move it to some better location. > 2.8.1. Simultaneous CHILD_SA rekeying Instead of simultaneous CHILD_SA rekeying, there should be section of simultaneous IKE SA rekeying. Simultaneous CHILD_SA rekeying just results few extra SAs that will disappear after next rekeys (at worst there will be 2 SA pairs, but all others will be deleted instead of being rekeyed as they are not used. The simultaneous IKE SA rekeying is much more important case to get correct, as both ends MUST agree on which IKE SA survive, as otherwise they will move the CHILD SA to wrong IKE SA and their state is completely messed up after that. This section should also explain that even if the simultaneous rekeying of IKE SA is noticed only AFTER the whole rekeying is already finished, both ends MUST still correctly detect it and act based on the fact which IKE SA will survive. This means that the old IKE SA should not be deleted too quickly after the IKE SA rekey finished, just in case there happened to be simultaneous rekey in progress. The one doing the delete should wait at least few minutes before deleting the old IKE SA, so it can be sure that other end does not have simultaneous rekey going on the IKE SA. > 2.8.2. Rekeying the IKE_SA Versus Reauthentication ... > Although rekeying the IKE_SA may be important in some environments, > reauthentication (the verification that the parties still have access > to the long-term credentials) is often more important. I disagree with that statement, and I think we should not have this kind of opinions in the document, as they do not really give any new information for the protocol point of view. So I suggest removing the whole paragraph. > 2.9. Traffic Selector Negotiation > > {{ Clarif-7.2 }} When an RFC4301-compliant IPsec subsystem receives > an IP packet and matches a "protect" selector in its Security Policy > Database (SPD), the subsystem protects that packet with IPsec. When > no SA exists yet, it is the task of IKE to create it. Maintenance of > a system's SPD is outside the scope of IKE (see [PFKEY] for an > example protocol), though some implementations might update their SPD > in connection with the running of IKE (for an example scenario, see > Section 1.1.3). I do not think we should be using PFKEY as example there, as it does not support IKEv2. That could of course be new work item for the WG some day, i.e. update of the PFKEY document to update IKEv2, but before we have that, we should not point to it, it will just cause confusion. > The first of the two TS payloads is known as TSi (Traffic Selector- > initiator). The second is known as TSr (Traffic Selector-responder). > TSi specifies the source address of traffic forwarded from (or the > destination address of traffic forwarded to) the initiator of the > CHILD_SA pair. TSr specifies the destination address of the traffic > forwarded to (or the source address of the traffic forwarded from) > the responder of the CHILD_SA pair. For example, if the original > initiator requests the creation of a CHILD_SA pair, and wishes to > tunnel all traffic from subnet 192.0.1.* on the initiator's side to > subnet 192.0.2.* on the responder's side, the initiator would include > a single traffic selector in each TS payload. TSi would specify the > address range (192.0.1.0 - 192.0.1.255) and TSr would specify the > address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was > acceptable to the responder, it would send identical TS payloads > back. (Note: The IP address range 192.0.2.* has been reserved for > use in examples in RFCs and similar documents. This document needed > two such ranges, and so also used 192.0.1.*. This should not be > confused with any actual address.) I think we should use only the one example network that has been reserved for that purpose, i.e get the rid of the 192.0.1.* address space. As we do use ranges in all cases in the IKEv2, there is no reason why the networks need to be /24 subnets. How about using 192.0.2.0/25 (i.e. 192.0.2.0 - 192.0.2.127) and 192.0.2.128/25 (i.e. 192.0.2.128 - 192.0.2.255) instead. Otherwise we might want to add comment to all other places having that 192.0.1.* network (which is actually used much more than the real example network of 192.0.2.*). ... > o If the responder's policy allows it to accept the first selector > of TSi and TSr, then the responder MUST narrow the traffic > selectors to a subset that includes the initiator's first choices. > In this example above, the responder might respond with TSi being > (192.0.1.43 - 192.0.1.43) with all ports and IP protocols. Or it can also return some bigger range that is subset of the initiators offer. > o If the responder's policy does not allow it to accept the first > selector of TSi and TSr, the responder narrows to an acceptable > subset of TSi and TSr. > > When narrowing is done, there may be several subsets that are > acceptable but their union is not. In this case, the responder > arbitrarily chooses one of them, and MAY include an I do not think the responder can arbitrarily choose one of them, it MUST select the one that includes the first TS if it was acceptable. > 2.9.1. Traffic Selectors Violating Own Policy > > {{ Clarif-4.12 }} > > When creating a new SA, the initiator needs to avoid proposing > traffic selectors that violate its own policy. If this rule is not > followed, valid traffic may be dropped. We should note here, that if you follow the RFC 4301 and use decorrelated policies, then this kind of policy violations cannot happen. > 2.15. Authentication of the IKE_SA ... > RestOfRespIDPayload = IDType | RESERVED | InitIDData ^^^^ Should be RespIDData. > MACedIDForR = prf(SK_pr, RestOfRespIDPayload) > > Note that all of the payloads are included under the signature, > including any payload types not defined in this document. If the > first message of the exchange is sent twice (the second time with a > responder cookie and/or a different Diffie-Hellman group), it is the > second version of the message that is signed. The first message might be sent more than twice, in case both INVALID_KE_PAYLOAD and COOKIE exchanges happen, i.e. change to: If the first message of the exchange is sent multiple times (i.e with a responder cookie (or even multiple of cookie exchanges) and/or a different Diffie-Hellman group), it is the last version of the message that is signed. > 2.16. Extensible Authentication Protocol Methods ... > In addition to authentication using public key signatures and shared > secrets, IKE supports authentication using methods defined in RFC > 3748 [EAP]. Typically, these methods are asymmetric (designed for a > user authenticating to a server), and they may not be mutual. {{ In > the next sentence, changed "public key signature based" to "strong" > }} For this reason, these protocols are typically used to > authenticate the initiator to the responder and MUST be used in > conjunction with a strong authentication of the responder to the This change is quite big protocol change to the bits on the wire, and also opens word "strong" to interpretation. I.e. what is strong authentication? As this is not defined here to vendors might implement that differently and result versions which cannot interoperate, because of this different interpretation. > 2.19. Requesting an Internal Address on a Remote Network ... > {{ 3.10.1-37 }} The FAILED_CP_REQUIRED notification is sent by > responder in the case where CP(CFG_REQUEST) was expected but not > received, and so is a conflict with locally configured policy. There > is no associated data. This should be combined with last paragraph in this section: > The responder MUST NOT send a CFG_REPLY without having first received > a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS > to perform an unnecessary configuration lookup if the IRAC cannot > process the REPLY. In the case where the IRAS's configuration > requires that CP be used for a given identity IDi, but IRAC has > failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and > terminate the IKE exchange with a FAILED_CP_REQUIRED error. We should also mention here that the FAILED_CP_REQUIRED is not fatal error to the IKE SA, it just cause the CHILD SA creation fail on the IKE_AUTH, but the IKE SA should be still created, and initiator can fix this by initiating new configuration payload request later. > 2.21. Error Handling ... > A node receiving such an unprotected Notify payload MUST NOT respond > and MUST NOT change the state of any existing SAs. The message might > be a forgery or might be a response the genuine correspondent was > tricked into sending. {{ Demoted two SHOULDs }} A node should treat ^^^^^^ I think that should still be capital SHOULD. > such a message (and also a network message like ICMP destination > unreachable) as a hint that there might be problems with SAs to that > IP address and should initiate a liveness test for any such IKE_SA. > An implementation SHOULD limit the frequency of such tests to avoid > being tricked into participating in a denial of service attack. > > A node receiving a suspicious message from an IP address with which > it has an IKE_SA MAY send an IKE Notify payload in an IKE > INFORMATIONAL exchange over that SA. {{ Demoted the SHOULD }} The > recipient MUST NOT change the state of any SAs as a result, but may > wish to audit the event to aid in diagnosing malfunctions. A node > MUST limit the rate at which it will send messages in response to > unprotected messages. We should also extend this section and include at least following cases: - Errors happening before authentication - Errors in the IPsec SA creation on IKE_AUTH - Describe which errors are so fatal that they cause the whole IKE SA to destroyed. > 2.23. NAT Traversal ... > Opening an IPsec connection through a NAT introduces special > problems. If the connection runs in transport mode, changing the IP > addresses on packets will cause the checksums to fail and the NAT > cannot correct the checksums because they are cryptographically > protected. Even in tunnel mode, there are routing problems because > transparently translating the addresses of AH and ESP packets > requires special logic in the NAT and that logic is heuristic and > unreliable in nature. For that reason, IKEv2 can negotiate UDP ^^^^^^^^^^^^^ We do not have negotiation for UDP encapsulation, we just start using it when we detect NAT. I.e change to "will use". > encapsulation of IKE and ESP packets. This encoding is slightly less > efficient but is easier for NATs to process. In addition, firewalls > may be configured to pass IPsec traffic over UDP but not ESP/AH or > vice versa. > > It is a common practice of NATs to translate TCP and UDP port numbers > as well as addresses and use the port numbers of inbound packets to > decide which internal node should get a given packet. For this > reason, even though IKE packets MUST be sent from and to UDP port > 500, they MUST be accepted coming from any port and responses MUST be ^ Add "or 4500". > sent to the port from whence they came. This is because the ports > may be modified as the packets pass through NATs. Similarly, IP > addresses of the IKE endpoints are generally not included in the IKE > payloads because the payloads are cryptographically protected and > could not be transparently modified by NATs. > > Port 4500 is reserved for UDP-encapsulated ESP and IKE. When working > through a NAT, it is generally better to pass IKE packets over port > 4500 because some older NATs handle IKE traffic on port 500 cleverly > in an attempt to transparently establish IPsec connections between > endpoints that don't handle NAT traversal themselves. Such NATs may > interfere with the straightforward NAT traversal envisioned by this > document. Everything after the first sentence in the paragraph is just misleading and should be removed. > {{ Clarif-7.6 }} An IPsec endpoint that discovers a NAT > between it and its correspondent MUST send all subsequent traffic > from port 4500, which NATs should not treat specially (as they might > with port 500). > o To tunnel IKE packets over UDP port 4500, the IKE header has four > octets of zero prepended and the result immediately follows the > UDP header. To tunnel ESP packets over UDP port 4500, the ESP > header immediately follows the UDP header. Since the first four > octets of the ESP header contain the SPI, and the SPI cannot > validly be zero, it is always possible to distinguish ESP and IKE > messages. We should also list whether it is allowed to float to port 4500 even when no NAT is detected (I think the answer is yes). And even if we float to port 4500, the UDP encapsulation should not be enabled or expected unless NAT between is really detected. > o Implementations MUST process received UDP-encapsulated ESP packets > even when no NAT was detected. > > o The original source and destination IP address required for the > transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) > are obtained from the Traffic Selectors associated with the > exchange. In the case of NAT traversal, the Traffic Selectors > MUST contain exactly one IP address, which is then used as the > original IP address. Getting original source and destination IP address from the traffic selectors do not really work currently. Especially when combined with the selectors from the packet and when responder is behind nat or similar problems. > o There are cases where a NAT box decides to remove mappings that > are still alive (for example, the keepalive interval is too long, > or the NAT box is rebooted). To recover in these cases, hosts > that are not behind a NAT SHOULD send all packets (including > retransmission packets) to the IP address and port from the last > valid authenticated packet from the other end (i.e., dynamically > update the address). A host behind a NAT SHOULD NOT do this > because it opens a DoS attack possibility. Any authenticated IKE > packet or any authenticated UDP-encapsulated ESP packet can be > used to detect that the IP address or the port has changed. This paragraph should here point out that MOBIKE changes this behivor, and point to the MOBIKE documents for more information. > Note that similar but probably not identical actions will likely be > needed to make IKE work with Mobile IP, but such processing is not > addressed by this document. This should most likely be removed now and add pointers to the MOBIKE and other documents. > 3.1. The IKE Header ... > o Major Version (4 bits) - Indicates the major version of the IKE > protocol in use. Implementations based on this version of IKE > MUST set the Major Version to 2. Implementations based on > previous versions of IKE and ISAKMP MUST set the Major Version to > 1. Implementations based on this version of IKE MUST reject or > ignore messages containing a version number greater than 2. Change to Implementations based on this version of IKE MUST reject or ignore messages containing a version number greater than 2 with INVALID_MAJOR_VERSION notify (see section 2.5 for more details). > o Exchange Type (1 octet) - Indicates the type of exchange being > used. This constrains the payloads sent in each message and > orderings of messages in an exchange. ^^^^^^^^^ What does that try to say? > * I(nitiator) (bit 3 of Flags) - This bit MUST be set in messages > sent by the original initiator of the IKE_SA and MUST be > cleared in messages sent by the original responder. It is used > by the recipient to determine which eight octets of the SPI > were generated by the recipient. Add clarification here, that the Inititor bit does not change even if IKE SA is rekeyed (regardless who rekeys it). > 3.3. Security Association Payload ... > The Proposal structure contains within it a Proposal # and an IPsec > protocol ID. Each structure MUST have a proposal number one (1) > greater than the previous structure. The first Proposal in the > initiator's SA payload MUST have a Proposal # of one (1). A proposal > of AH or ESP would have two proposal structures, one for AH with > Proposal #1 and one for ESP with Proposal #2. I think the last sentence should be removed, as it is bit confusing and some people might read it "AH and ESP" and interpret it as bundles. I do not really consider AH or ESP style proposal that common to require example here. Perhaps ESP with combined mode ciphers and ESP with normal ciphers + integrity algorithms would make better example. > 3.3.2. Transform Substructure ... > (*) Negotiating an integrity algorithm is mandatory for the > Encrypted payload format specified in this document. Future > documents may specify additional formats based on authenticated > encryption, in which case a separate integrity algorithm is not > negotiated. We already have the future documents ready, and they are in the rfc editor queue, so we can add reference here. > 3.3.3. Valid Transform Types by Protocol ... > (*) Negotiating an integrity algorithm is mandatory for the > Encrypted payload format specified in this document. Future > documents may specify additional formats based on authenticated > encryption, in which case a separate integrity algorithm is not > negotiated. Same change here. > 3.3.6. Attribute Negotiation > > During security association negotiation initiators present offers to > responders. Responders MUST select a single complete set of > parameters from the offers (or reject all offers if none are > acceptable). If there are multiple proposals, the responder MUST > choose a single proposal. If the selected proposal has multiple > Transforms with the same type, the responder MUST choose a single > one. Any attributes of a selected transform MUST be returned > unmodified. The initiator of an exchange MUST check that the > accepted offer is consistent with one of its proposals, and if not > that response MUST be rejected. One of the questions that have been out long time, is that do all of the offered proposals must have identical Diffie-Hellman group lists. What does it mean if one of the proposals have different list than some other proposal. Can the KE payload include then be from such group that only exists in one of the lists. Also do the Diffie-Hellman groups need to be repeated on every single proposal. I think we should add some text explaining that. > 3.5. Identification Payloads ... > ID_RFC822_ADDR 3 > A fully-qualified RFC822 email address string, An example of a > ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not > contain any terminators. As there was reference added to the IDNA in the FQDN case, should we also refer here to the international email addresses specification? > 3.6. Certificate Payload ... > Certificate Encoding Value > ---------------------------------------------------- > RESERVED 0 > PKCS #7 wrapped X.509 certificate 1 UNSPECIFIED > PGP Certificate 2 UNSPECIFIED > DNS Signed Key 3 UNSPECIFIED > X.509 Certificate - Signature 4 > Kerberos Token 6 UNSPECIFIED > Certificate Revocation List (CRL) 7 > Authority Revocation List (ARL) 8 > SPKI Certificate 9 UNSPECIFIED > X.509 Certificate - Attribute 10 > Raw RSA Key 11 > Hash and URL of X.509 certificate 12 > Hash and URL of X.509 bundle 13 > RESERVED to IANA 14 - 200 > PRIVATE USE 201 - 255 Actually the certificate encodings 8 (Authority Revocation List (ARL)) and 10 (X.509 Certificate - Attribute) are not specified in this document at all, so either they should be put as UNSPECIFIED or documentation for them needs to be added (perhaps just sharing type 4 and 7 descriptions). > o X.509 Certificate - Signature (4) contains a DER encoded X.509 > certificate whose public key is used to validate the sender's AUTH > payload. That certificate can also bve used as part of the chain. I.e. add or used in the validation. to the end of that paragraph. > 3.7. Certificate Request Payload > > The Certificate Request Payload, denoted CERTREQ in this memo, > provides a means to request preferred certificates via IKE and can > appear in the IKE_INIT_SA response and/or the IKE_AUTH request. > Certificate Request payloads MAY be included in an exchange when the > sender needs to get the certificate of the receiver. If multiple CAs > are trusted and the cert encoding does not allow a list, then > multiple Certificate Request payloads SHOULD be transmitted. I think the "SHOULD" there could be lowercase should as this is not really a protocol issue. > 3.13.1. Traffic Selector I think we should add here text which says that if the TS type is unknown, then the recipient will skip that traffic selector over, and ignore it, so that it will not be returned in the narrowed set (i.e. responder will narrow selection so that the unknown TS type is not part of the narrowed traffic selectors returned to initiator). This allows adding more traffic selector types without breaking things in the future. The current generic text only specifies that processing for unknown payloads, but does not say anything about the subtypes inside the different payloads (like unknown ID types, or unknown TS types). > 3.14. Encrypted Payload > > The Encrypted Payload, denoted SK{...} or E in this memo, contains > other payloads in encrypted form. The Encrypted Payload, if present > in a message, MUST be the last payload in the message. Often, it is > the only payload in the message. > > The algorithms for encryption and integrity protection are negotiated > during IKE_SA setup, and the keys are computed as specified in > Section 2.14 and Section 2.18. > > This document specifies the cryptographic processing of Encrypted > payloads using a block cipher in CBC mode and an integrity check > algorithm that computes a fixed-length checksum over a variable size > message. The design is modeled after the ESP algorithms described in As we already has document which describes how to use other ciphers in the IKE, we at least put the reference to there, or even incorporate the changes specified in there to this document. Especially as the RFCF 4307 specifies ENCR_AES_CTR as SHOULD for the IKEv2... > 3.15.1. Configuration Attributes ... > o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the > internal network, sometimes called a red node address or private > address and MAY be a private address on the Internet. {{ > Clarif-6.2}} In a request message, the address specified is a > requested address (or a zero-length address if no specific address > is requested). If a specific address is requested, it likely > indicates that a previous connection existed with this address and > the requestor would like to reuse that address. With IPv6, a > requestor MAY supply the low-order address octets it wants to use. > Multiple internal addresses MAY be requested by requesting > multiple internal address attributes. The responder MAY only send > up to the number of addresses requested. The INTERNAL_IP6_ADDRESS > is made up of two fields: the first is a 16-octet IPv6 address, > and the second is a one-octet prefix-length as defined in > [ADDRIPV6]. The requested address is valid until there are no > IKE_SAs between the peers. Perhaps move most of this explination to the 3.15.3 or at least add pointer to there. Also I think the text "The requested address is valid until there are no IKE_SAs between the peers." is incorrect, it most likely should say "The requested address is valid as long as this IKE SA (or its rekeyed successors) requesting the address is valid." I.e. even if another IKE SA is created between the peers that does not keep the address allocated in another IKE SA alive, unless it is also allocated in that IKE SA. This is especially the case where lets say multi user hosts do per user IKE SAs and want to allocate IP addresses separately for each user. ... > o INTERNAL_IP6_NBNS - {{ Clarif-6.6 }} NetBIOS is not defined for > IPv6; therefore, INTERNAL_IP6_NBNS is also unspecified and is only > retained for compatibility with RFC 4306. I think there is no point of keeping the "compatibility with RFC 4306" for feature that cannot be used. I would simply remove the whole INTERNAL_IP6_NBNS and mark it RESERVED. ... > o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge- > device protects. This attribute is made up of two fields: the > first being an IP address and the second being a netmask. > Multiple sub-networks MAY be requested. The responder MAY respond > with zero or more sub-network attributes. Add pointer to 3.15.2. ... > o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge- > device protects. This attribute is made up of two fields: the > first is a 16-octet IPv6 address, and the second is a one-octet > prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY > be requested. The responder MAY respond with zero or more sub- > network attributes. Add pointer to 3.15.2. > 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET ... > For instance, if there are two subnets, 192.0.1.0/26 and > 192.0.2.0/24, and the client's request contains the following: Again here we use 192.0.1.0/26 address range which is not reserved for examples. Would suggest using 192.0.2.128/26 (192.0.2.128-191) and 192.0.2.0/25 (192.0.2.0-127) to be used instead. > 3.15.4. Address Assignment Failures > > {{ Added this section from Clarif-6.8 }} > > > > > Kaufman, et al. Expires August 28, 2008 [Page 101] > > Internet-Draft IKEv2bis February 2008 > > > If the responder encounters an error while attempting to assign an IP > address to the initiator during the processing of a Configuration > Payload, it responds with an INTERNAL_ADDRESS_FAILURE notification. > {{ 3.10.1-36 }} If this error is generated within an IKE_AUTH > exchange, no CHILD_SA will be created. However, there are some more > complex error cases. Add comment there, that the IKE SA is still created even if the initial child sa cannot be created. > 3.16. Extensible Authentication Protocol (EAP) Payload ... > {{ Demoted the SHOULD NOT and SHOULD }} Note that since IKE passes an > indication of initiator identity in message 3 of the protocol, the > responder should not send EAP Identity requests. The initiator may, > however, respond to such requests if it receives them. This is again bits on the wire protocol change if someone after this does not follow the SHOULD NOT and SHOULD written here before. I think it should be kept as it was before. > 4. Conformance Requirements ... > Every implementation MUST be capable of doing four-message > IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, > one for ESP and/or AH). Implementations MAY be initiate-only or ^^^^^^ Change to "or". > 5.1. Traffic selector authorization ... > For example, the PAD might be configured so that authenticated > identity "sgw23.example.com" is allowed to create IPsec SAs for > 192.0.2.0/24, meaning this security gateway is a valid > "representative" for these addresses. Host-to-host IPsec requires > similar entries, linking, for example, "fooserver4.example.com" with > 192.0.1.66/32, meaning this identity a valid "owner" or > "representative" of the address in question. Again using the non example prefix of 192.0.1.66/32. Would be better to use smaller subnets and addresses from example prefix. > As noted in [IPSECARCH], "It is necessary to impose these constraints > on creation of child SAs to prevent an authenticated peer from > spoofing IDs associated with other, legitimate peers." In the > example given above, a correct configuration of the PAD prevents > sgw23 from creating IPsec SAs with address 192.0.1.66, and prevents > fooserver4 from creating IPsec SAs with addresses from 192.0.2.0/24. > Appendix C. Exchanges and Payloads ... > C.1. IKE_SA_INIT Exchange > > request --> [N(COOKIE)], > SA, KE, Ni, > [N(NAT_DETECTION_SOURCE_IP)+, > N(NAT_DETECTION_DESTINATION_IP)], > [V+] > > normal response <-- SA, KE, Nr, > (no cookie) [N(NAT_DETECTION_SOURCE_IP), > N(NAT_DETECTION_DESTINATION_IP)], > [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], > [V+] Add other versions of possible replies here too: cookie request <-- N(COOKIE) [V+] invalid ke payload <-- N(INVALID_KE_PAYLOAD) error [V+] combined cookie <-- N(COOKIE), N(INVALID_KE_PAYLOAD) request and invalid [V+] ke payload error > C.2. IKE_AUTH Exchange without EAP > > request --> IDi, [CERT+], > [N(INITIAL_CONTACT)], > [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], > [IDr], > AUTH, > [CP(CFG_REQUEST)], > [N(IPCOMP_SUPPORTED)+], > [N(USE_TRANSPORT_MODE)], > [N(ESP_TFC_PADDING_NOT_SUPPORTED)], > [N(NON_FIRST_FRAGMENTS_ALSO)], > SA, TSi, TSr, > [V+] > > response <-- IDr, [CERT+], > AUTH, > [CP(CFG_REPLY)], > [N(IPCOMP_SUPPORTED)], > [N(USE_TRANSPORT_MODE)], > [N(ESP_TFC_PADDING_NOT_SUPPORTED)], > [N(NON_FIRST_FRAGMENTS_ALSO)], > SA, TSi, TSr, > [N(ADDITIONAL_TS_POSSIBLE)], > [V+] Same here: error in CHILD SA <-- IDr, [CERT+], creation AUTH, N(error) [V+] > C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying CHILD_SAs > > request --> [N(REKEY_SA)], > [CP(CFG_REQUEST)], > [N(IPCOMP_SUPPORTED)+], > [N(USE_TRANSPORT_MODE)], > [N(ESP_TFC_PADDING_NOT_SUPPORTED)], > [N(NON_FIRST_FRAGMENTS_ALSO)], > SA, Ni, [KEi], TSi, TSr > > response <-- [CP(CFG_REPLY)], > [N(IPCOMP_SUPPORTED)], > [N(USE_TRANSPORT_MODE)], > [N(ESP_TFC_PADDING_NOT_SUPPORTED)], > [N(NON_FIRST_FRAGMENTS_ALSO)], > SA, Nr, [KEr], TSi, TSr, > [N(ADDITIONAL_TS_POSSIBLE)] And here: error case <-- N(error) invalid ke payload <-- N(INVALID_KE_PAYLOAD) next request with --> [N(REKEY_SA)], new ke payload using [CP(CFG_REQUEST)], group given by [N(IPCOMP_SUPPORTED)+], invalid ke payload [N(USE_TRANSPORT_MODE)], notify [N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(NON_FIRST_FRAGMENTS_ALSO)], SA, Ni, [KEi], TSi, TSr (response would be same as in normal case). > Appendix D. Changes Between Internet Draft Versions I guess the sections here should mention draft numbers too, as now there is two changes from -00 to -01 draft: > D.1. Changes from IKEv2 to draft -00 > D.2. Changes from draft -00 to draft -01 > D.3. Changes from draft -00 to draft -01 > D.4. Changes from draft -01 to draft -02 > Added Clarif-4.4 to the ned of Section 3.3.2. ^^^ Typo. > D.5. Changes from draft -02 to draft -03 > PRF_HMAC_TIGER 3 (RFC2104) What is unspecified in tiger, does not the rfc 2104 specify how to use PRF_HMAC_TIGER? -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jul 29 00:54:35 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0394228C0ED; Tue, 29 Jul 2008 00:54:35 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABAB528B56A for ; Tue, 29 Jul 2008 00:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xWPXspNmum1 for ; Tue, 29 Jul 2008 00:54:32 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 99DCD3A67AA for ; Tue, 29 Jul 2008 00:54:32 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 3E7681022408C; Tue, 29 Jul 2008 00:54:44 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 29 Jul 2008 00:54:44 -0700 (PDT) Message-ID: <2a2ddbb473bd30d88b950a65e0ad0847.squirrel@www.trepanning.net> In-Reply-To: <18574.24385.37955.850321@fireball.kivinen.iki.fi> References: <20080624163001.66CF63A6A69@core3.amsl.com> <24824166c413680844268e1db43651cf.squirrel@www.trepanning.net> <7783b00871110e39a0fa7f2f9b751a56.squirrel@www.trepanning.net> <18574.24385.37955.850321@fireball.kivinen.iki.fi> Date: Tue, 29 Jul 2008 00:54:44 -0700 (PDT) From: "Dan Harkins" To: "Tero Kivinen" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org, Yoav Nir , Dan Harkins Subject: Re: [IPsec] WG Review: IP Security Maintenance and Extensions (ipsecme) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Tero, On Mon, July 28, 2008 5:07 pm, Tero Kivinen wrote: > Dan Harkins writes: >> Your example was to send the 64-bit index into a database as the >> ticket. >> I'm sure that's not what you propose to do and was just an example but >> it illustrates why we need some base requirements around construction of >> the ticket. Such a ticket is forgeable and nothing binds a peer to such >> a ticket. The scheme would probably rely on layers of checks ("is the >> claimed sender of this ticket the same as the address in the SA pointed >> to by this ticket index?", etc) to ensure the ticket isn't misused >> instead >> of having a robust cryptographic check to ensure proper ticket usage. > > Running index would be perfectly good ticket and would be perfectly > secure. The initiator doing the resumption will give that ticket to > the responder, responder will look up the keys and other material from > the database, and then decrypt the rest of the encrypted message and > verify the integrity of it. After that it will mark the index in the > database as "used" so it cannot be used anymore. The initiator has > proven the knowledge of the key associated to the ticket (but not > wrapped in to the ticket, as it was in the database instead) by being > able to create the encrypted and integrity protected parts of the > message. Any other peer would be knowing the keys to generate > cryptographically integrity portected message so that should prevent > anybody else using the ticket (unless the original party of the > initial IKE SA creation gives out the keys). > > I do not understand why the ticket must be unforgeable or why it must > be indistinguishable from random? Those requirements do not make any > sense for me in this kind of database case. Anybody can see the ticket > immediately when it is first time used and attacker just needs to read > the ticket from there and block those packets from reaching the > recipient and then he can use the ticket if that would be the only > protection on the ticket. A ticket has to be unforgeable to prevent someone from creating his own tickets that would be accepted by a particular responder. If the scheme allows forgeries then anybody can create SAs without actually going through authentication. I don't think we want to allow that. Indistinguishable from random, for some number of adversary queries, is a yardstick by which to measure security. Any cryptographic system is breakable, in principle, after enough time and effort. So "security" becomes a function of the amount of time and effort an attacker must use to break the system. If it can be shown that an attacker cannot gain an advantage in breaking the system after X queries, and X is sufficiently large (like 2^80 or 2^128), then one can quantify "security" to a certain degree. That seems like a worthwhile thing to do. > The real protection is that only valid party > can create the cryptographacally protected part of the message. That's not much protection. A protocol is flawed if an attacker can cause two legitimate parties to think the protocol finished successfully while generating different state. It violates the "Consistency Requirement" (see Hugo Krawczyk's paper SIGMA for a very good description). An attacker could manipulate IP addresses during this exchange and the result would be that the initiator thinks the SA is between IDi and IDr at IP address X and IP address Y, respectively. The responder thinks the SA is between IDi and IDr at IP address Z and IP address Y, respectively. That is an undetectable failure by both the initiator and responder therefore that protocol is flawed. The attacker could also just record the legitimate exchange and then play it back in its entirety from different IP addresses. Yes, the attacker doesn't know the key but the responder thinks it has an SA with someone who doesn't exist at the place it thinks that someone exists. The protocol is flawed. This is fixable but it requires specifying behavior in creation of the ticket. Or it requires unfounded assumptions to be made about the security knowledge of implementors-- remember, if it's just an opaque blob then the creation and processing of it is entirely up to the imagination of the implementor. >> Another bad example of ticket creation would be to create a keystream >> with a hash function, seeded with some password, and XOR the keystream >> with each ticket to create the opaque blob. A naive implementor who is >> not security savvy might come up with such a scheme. We should prevent >> someone from claiming compliance with a standards track RFC from the >> Security Area of the IETF if they have such a lame scheme. > > Yes, that would be very bad ticket. Yet if the ticket is just an unspecified opaque blob this is entirely possible. It's possible for someone to correctly implement the protocol and end up with an something that is flawed from a security perspective. Security protocols should be robust. > The vendor could also post those tickets and their decrypted content > to the wikipedia for storage, and that would also be bad way to do > tickets, but I still do not think we need to add rules forbidding > that... That's a ridiculous argument. Publishing secret data anywhere serves no purpose. The point being made is that someone can correctly implement the protocol but since the security of it depends on critical decisions they make the end result may not be secure. Therefore the protocol is not secure, certain implementations may or may not be secure but the protocol is not. But if the protocol had cryptographic checks built in such that the man-in-the-middle, or replay, attack above would result in a verification failure of the ticket then proper implementation of the specification would result in some level of security. We could actually describe some security features of the protocol. >> This is a security protocol and we should make sure it's secure. To do >> so we should specify _minimum_ behavior to comply with reasonable >> security >> requirements. A base blob communication protocol whose entire security >> is left up to the imagination of the implementor is not what a standards >> track RFC out of the Security Area of the IETF should be, in my opinion >> anyway. > > But as has been pointed out the ticket might not be just opaque blob > communication, it could also be representated as handle to some > internal persistent data structure. It could. But then, again, it could not. And even if it was, so what? That doesn't make it secure. If construction of the ticket is out-of-scope then you can't say what the ticket might or might not be. It can be everything and anything, secure or insecure. All would be equally acceptable. And that seems so very wrong to me. regards, Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jul 29 01:31:46 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29D1D3A6AE2; Tue, 29 Jul 2008 01:31:46 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F0F73A6AE2 for ; Tue, 29 Jul 2008 01:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[AWL=0.967, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xcebaDOxuqZ for ; Tue, 29 Jul 2008 01:31:43 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 497EF3A67F8 for ; Tue, 29 Jul 2008 01:31:42 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m6T8Vis7021586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 11:31:44 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m6T8Viwn019154; Tue, 29 Jul 2008 11:31:44 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18574.54640.223358.423381@fireball.kivinen.iki.fi> Date: Tue, 29 Jul 2008 11:31:44 +0300 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: <2a2ddbb473bd30d88b950a65e0ad0847.squirrel@www.trepanning.net> References: <20080624163001.66CF63A6A69@core3.amsl.com> <24824166c413680844268e1db43651cf.squirrel@www.trepanning.net> <7783b00871110e39a0fa7f2f9b751a56.squirrel@www.trepanning.net> <18574.24385.37955.850321@fireball.kivinen.iki.fi> <2a2ddbb473bd30d88b950a65e0ad0847.squirrel@www.trepanning.net> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 18 min X-Total-Time: 17 min Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] WG Review: IP Security Maintenance and Extensions (ipsecme) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Dan Harkins writes: > A ticket has to be unforgeable to prevent someone from creating his own > tickets that would be accepted by a particular responder. If the scheme > allows forgeries then anybody can create SAs without actually going through > authentication. I don't think we want to allow that. Even when they can forge the ticket does not help them at all as they do not know the keying material associated with the ticket, thus they cannot create the encrypted and integrity protected parts of the packet that is required to create SAs. > > The real protection is that only valid party > > can create the cryptographacally protected part of the message. > > That's not much protection. A protocol is flawed if an attacker can cause > two legitimate parties to think the protocol finished successfully while > generating different state. It violates the "Consistency Requirement" (see > Hugo Krawczyk's paper SIGMA for a very good description). Attacker cannot cause either party to think the protocol is finished at all. Only the original parties can do that as they are the only ones who knows the keys. Note, that in this case both peers ALREADY have shared secret that is used to calculate the integrity of the packet. Ticket is just used to tell the responder who is the initiator, so he can use correct shared secret key to authenticat the packet initiator sent. I think you should really read the protocol document first, as I think you are missing something big here. > An attacker could manipulate IP addresses during this exchange and the > result would be that the initiator thinks the SA is between IDi and IDr > at IP address X and IP address Y, respectively. The responder thinks the > SA is between IDi and IDr at IP address Z and IP address Y, respectively. And if X and Z are different then responder will ignore the Z as it does not match the stored data in the database. Or if mobike is used then the mobike payloads inside the encrypted parts will tell both ends that there is NAT between them and they will work around it. > That is an undetectable failure by both the initiator and responder > therefore that protocol is flawed. Responder will detect this by comparing the outer addresses to the database if no MOBIKE is used. If MOBIKE is used then both ends will detect that NAT_DETECTION_*_IP notifies do not match, and there is NAT between the peers, and will cope with that NAT (or in this case attacker). > The attacker could also just record > the legitimate exchange and then play it back in its entirety from > different IP addresses. Yes, the attacker doesn't know the key but the > responder thinks it has an SA with someone who doesn't exist at the > place it thinks that someone exists. The protocol is flawed. If you read the protocol description it says each ticket is usable only once. Thus after the legimate exchange is finished, the ticket is destroyed and new one is created, i.e. in this case the ticket in the database is marked as used and the responder issues new integer ticket number for the initiator, and initiator will use that next time. > This is fixable but it requires specifying behavior in creation of the > ticket. Or it requires unfounded assumptions to be made about the security > knowledge of implementors-- remember, if it's just an opaque blob then > the creation and processing of it is entirely up to the imagination of > the implementor. Yes. And we are here to specify protocols, not writing implementations. Implementor can mess up things way easier, than doing bad ticket generation, buffer overflows and such are much easier mistakes to make... > But if the protocol had cryptographic checks built in such that the > man-in-the-middle, or replay, attack above would result in a verification > failure of the ticket then proper implementation of the specification would > result in some level of security. We could actually describe some security > features of the protocol. As nobody else than the implementor can have any way to verify that those rules are followed (nobody else do not have the key required to decrypt the blob), then mandating such things does not help, as if implementor still wants to mess up things he can do so. Also rules you put out forbids one of those very useful implementation architecture. If the gateway has persisntent storage, it can store the material there, and there is no need to use opaque encrypted blobs, just the a handle to that persistent data. > It could. But then, again, it could not. And even if it was, so what? > That doesn't make it secure. If construction of the ticket is out-of-scope > then you can't say what the ticket might or might not be. It can be > everything and anything, secure or insecure. All would be equally > acceptable. And that seems so very wrong to me. Then we disagree here, and I do not think we should continue this. I think it would be fine to provide example of good ticket generation guidelines (like we do for example for cookies in the IKEv2), but mandating anything for that kind of blob should be out of the scope. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jul 29 10:45:57 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFAEA3A6A5C; Tue, 29 Jul 2008 10:45:56 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A0063A6A4F for ; Tue, 29 Jul 2008 10:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeM+Fv+dYLMr for ; Tue, 29 Jul 2008 10:45:54 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id E83643A67EF for ; Tue, 29 Jul 2008 10:45:53 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 7FDA11022408C; Tue, 29 Jul 2008 10:46:06 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 29 Jul 2008 10:46:06 -0700 (PDT) Message-ID: In-Reply-To: <18574.54640.223358.423381@fireball.kivinen.iki.fi> References: <20080624163001.66CF63A6A69@core3.amsl.com> <24824166c413680844268e1db43651cf.squirrel@www.trepanning.net> <7783b00871110e39a0fa7f2f9b751a56.squirrel@www.trepanning.net> <18574.24385.37955.850321@fireball.kivinen.iki.fi> <2a2ddbb473bd30d88b950a65e0ad0847.squirrel@www.trepanning.net> <18574.54640.223358.423381@fireball.kivinen.iki.fi> Date: Tue, 29 Jul 2008 10:46:06 -0700 (PDT) From: "Dan Harkins" To: "Tero Kivinen" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org, Yoav Nir , Dan Harkins Subject: Re: [IPsec] WG Review: IP Security Maintenance and Extensions (ipsecme) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Tue, July 29, 2008 1:31 am, Tero Kivinen wrote: > Dan Harkins writes: >> > The real protection is that only valid >> party >> > can create the cryptographacally protected part of the message. >> >> That's not much protection. A protocol is flawed if an attacker can >> cause >> two legitimate parties to think the protocol finished successfully while >> generating different state. It violates the "Consistency Requirement" >> (see >> Hugo Krawczyk's paper SIGMA for a very good description). > > Attacker cannot cause either party to think the protocol is finished > at all. Only the original parties can do that as they are the only > ones who knows the keys. > > Note, that in this case both peers ALREADY have shared secret that is > used to calculate the integrity of the packet. Ticket is just used to > tell the responder who is the initiator, so he can use correct shared > secret key to authenticat the packet initiator sent. > > I think you should really read the protocol document first, as I think > you are missing something big here. That integrity-protected packet containing the ticket is what gets sent by the attacker. That packet is not cryptographically bound to anything else. While an attacker cannot create the packet, it can send that packet from any IP address just as easily as a legitimate client can. This causes the problem I discussed. >> An attacker could manipulate IP addresses during this exchange and the >> result would be that the initiator thinks the SA is between IDi and IDr >> at IP address X and IP address Y, respectively. The responder thinks the >> SA is between IDi and IDr at IP address Z and IP address Y, >> respectively. > > And if X and Z are different then responder will ignore the Z as it > does not match the stored data in the database. Or if mobike is used > then the mobike payloads inside the encrypted parts will tell > both ends that there is NAT between them and they will work around it. Except it doesn't say in the spec to match the address of the sender against some external source. So the security of the protocol relies on unstated checks. Is that the only one or are there others? What is your aversion to using cryptography to solve this problem? >> That is an undetectable failure by both the initiator and responder >> therefore that protocol is flawed. > > Responder will detect this by comparing the outer addresses to the > database if no MOBIKE is used. If MOBIKE is used then both ends will > detect that NAT_DETECTION_*_IP notifies do not match, and there is NAT > between the peers, and will cope with that NAT (or in this case > attacker). > >> The attacker could also just record >> the legitimate exchange and then play it back in its entirety from >> different IP addresses. Yes, the attacker doesn't know the key but the >> responder thinks it has an SA with someone who doesn't exist at the >> place it thinks that someone exists. The protocol is flawed. > > If you read the protocol description it says each ticket is usable > only once. Thus after the legimate exchange is finished, the ticket is > destroyed and new one is created, i.e. in this case the ticket in the > database is marked as used and the responder issues new integer ticket > number for the initiator, and initiator will use that next time. I read the protocol. It says, "Tickets are intended for one-time use: a client MUST NOT reuse a ticket, either with the same or with a different gateway. A gateway SHOULD reject a reused ticket." But attackers typically don't follow MUST and SHOULD rules in an RFC. And a gateway upon receipt of a packet containing a ticket does not know whether it's from a client who is faithfully following the rules or from an attacker who is not. A gateway can retain all tickets it has processed to make sure they're not reused but for 100,000+ clients (to use Yoav's example) that gets to be a burden. Or the protocol suggests making a "cookie request" to deal with replay attacks. And in the event of a crash and restart 100,000+ resumption packets from 100,000+ clients will look quite a bit like an attack. >> This is fixable but it requires specifying behavior in creation of the >> ticket. Or it requires unfounded assumptions to be made about the >> security >> knowledge of implementors-- remember, if it's just an opaque blob then >> the creation and processing of it is entirely up to the imagination of >> the implementor. > > Yes. And we are here to specify protocols, not writing > implementations. Implementor can mess up things way easier, than doing > bad ticket generation, buffer overflows and such are much easier > mistakes to make... So then let's not make it easier to mess up! What's wrong with a robust protocol? >> But if the protocol had cryptographic checks built in such that the >> man-in-the-middle, or replay, attack above would result in a >> verification >> failure of the ticket then proper implementation of the specification >> would >> result in some level of security. We could actually describe some >> security >> features of the protocol. > > As nobody else than the implementor can have any way to verify that > those rules are followed (nobody else do not have the key required to > decrypt the blob), then mandating such things does not help, as if > implementor still wants to mess up things he can do so. Also rules > you put out forbids one of those very useful implementation > architecture. If the gateway has persisntent storage, it can store the > material there, and there is no need to use opaque encrypted blobs, > just the a handle to that persistent data. You said twice in your post that I should read the protocol. But you know what? Maybe you should read the protocol. I'm not forbidding your "very useful implementation architecture." Section 5.1 is doing that. >> It could. But then, again, it could not. And even if it was, so what? >> That doesn't make it secure. If construction of the ticket is >> out-of-scope >> then you can't say what the ticket might or might not be. It can be >> everything and anything, secure or insecure. All would be equally >> acceptable. And that seems so very wrong to me. > > Then we disagree here, and I do not think we should continue this. I > think it would be fine to provide example of good ticket generation > guidelines (like we do for example for cookies in the IKEv2), but > mandating anything for that kind of blob should be out of the scope. Yes, we do disagree. I want a protocol which uses cryptographic tools to solve some obvious problems; you want to solve them by unstated and non-cryptographic verification of external data. I want a protocol that, when implemented correctly, can claim some well-founded security features; you want a protocol that cannot claim any real security features. If you think the spec should not mandate any particular construction or behavior then fine, state that. We can disagree about what the spec should say. But why make this topic out-of-scope? Why is robust security something to be avoided ("if implementor still wants to mess up things he can do so")? I looked through the recent postings on this list and can't find anything that discusses ticket creation as being out-of-scope. It just appeared in the charter. Can someone please point me to the postings on the list that discuss the rationale behind this? Where did this statement about out-of-scope come from? Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec