From ipsec-bounces@ietf.org Mon Nov 3 04:26: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 3DB003A6A44; Mon, 3 Nov 2008 04:26:35 -0800 (PST) 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 BA9513A6407 for ; Mon, 3 Nov 2008 04:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.534 X-Spam-Level: X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 a7gzcgpux7mp for ; Mon, 3 Nov 2008 04:26:33 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id C75BC3A6832 for ; Mon, 3 Nov 2008 04:25:41 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mA3CPUv2001963 for ; Mon, 3 Nov 2008 06:25:37 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Nov 2008 14:25:27 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Nov 2008 14:25:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Nov 2008 14:25:27 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB720215E11A@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last-Call: ROHCoIPSec Thread-Index: Ack7aPU8ZWiFDXFAQlaNANY9Ipy6vQCRirdA From: To: X-OriginalArrivalTime: 03 Nov 2008 12:25:27.0750 (UTC) FILETIME=[41190660:01C93DAF] X-Nokia-AV: Clean Subject: [IPsec] FW: WG Last-Call: ROHCoIPSec 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 FYI. > -----Original Message----- > From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org] On > Behalf Of ext Carl Knutsson > Sent: 31 October, 2008 16:57 > To: rohc > Cc: christou_chris@bah.com; Carsten Bormann > Subject: [rohc] WG Last-Call: ROHCoIPSec > > ROHCers, > > The ROHCoIPSEC profiles draft have been stale for some time now and I > think we all agree that is time for a WG last-call. > > Therefore, we are now issuing a WG last-call for: > > draft-ietf-rohc-hcoipsec-09.txt > draft-ietf-rohc-ikev2-extensions-hcoipsec-07.txt > draft-ietf-rohc-ipsec-extensions-hcoipsec-03.txt > > (as Proposed Standard) > > This is a regular ~two-week WG last-call (as suggested in RFC2418). > Please send WG last-call comments to the rohc mailing list rohc at > ietf.org before Tue, 2008-11-14, 17:00 UTC. Yoav Nir and Robert A. > Stangarone Jr are committed document reviewers (CDR) and have promised > to send in a review of complete framework before the deadline. > > The plan is to submit all drafts together. > > > Best Regards > > /Calle (ROHC WG chair) > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www.ietf.org/mailman/listinfo/rohc > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 3 16:02: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 F30F428C47E; Mon, 3 Nov 2008 16:02:44 -0800 (PST) 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 3608128C13F for ; Mon, 3 Nov 2008 16:02:44 -0800 (PST) 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 8GKaT2Dp6PV0 for ; Mon, 3 Nov 2008 16:02:43 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id D7E9228C487 for ; Mon, 3 Nov 2008 16:02:09 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so2755166rvf.49 for ; Mon, 03 Nov 2008 16:02:07 -0800 (PST) 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=mE/7BK6vYF8pnqWJtFAIShTO0QDhPzHFzz+ED3JENd8=; b=F725qNMsgIY+QanJkhKDNXeKtkNPSOrrwVB5Sxme1gcLPNlyy8OUhOm8M3HI2msE9c vahcBJZXc0nvBy2wUli5yb1eKhwUwg3UwKzeBdZGYx4sVon2vmVBUvYyk8voaqBt9Wfm Eqj1EF1GHQ5sk4CwZ3pau1Cxn+cZUgToMispg= 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=DTLjrt4N8yez1Uxkzc2AAIsX3jQbdtZrTDVMuBvsbUShRXV9CVmoT37/q0s+sEqyC7 FzlyilJhbFW3u0OzycWc6rnGCP1YC9pNvisjnlOWBHjA/cgyrfcqoN0fSSH3Dyu8r5RS kdUBmaM7UIaIRlLnsZGUKCmD7CvYmBdWCvsyM= Received: by 10.142.252.11 with SMTP id z11mr417932wfh.36.1225756927550; Mon, 03 Nov 2008 16:02:07 -0800 (PST) Received: by 10.142.225.19 with HTTP; Mon, 3 Nov 2008 16:02:07 -0800 (PST) Message-ID: Date: Mon, 3 Nov 2008 17:02:07 -0700 From: "Vijay Devarapalli" To: "Sheila Frankel" In-Reply-To: <20081023111335.93181fsvzkllr3q7@webmail.nist.gov> MIME-Version: 1.0 Content-Disposition: inline References: <20081023111335.93181fsvzkllr3q7@webmail.nist.gov> Cc: IPsec@ietf.org Subject: Re: [IPsec] Roadmap doc 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, On Thu, Oct 23, 2008 at 8:13 AM, Sheila Frankel wrote: > 8. Other Protocols that use IPsec/IKE > 8.1. Mobile IP (MIPv4 and MIPv6) You might want to add Proxy Mobile IPv6 [RFC 5213] to this. See section 4 of RFC 5213. Vijay _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 3 16:15:03 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 13D8D28C334; Mon, 3 Nov 2008 16:15:03 -0800 (PST) X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D0E703A6994; Mon, 3 Nov 2008 16:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081104001501.D0E703A6994@core3.amsl.com> Date: Mon, 3 Nov 2008 16:15:01 -0800 (PST) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-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: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Re-direct Mechanism for IKEv2 Author(s) : V. Devarapalli, K. Weniger Filename : draft-ietf-ipsecme-ikev2-redirect-01.txt Pages : 12 Date : 2008-11-03 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-ietf-ipsecme-ikev2-redirect-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. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2-redirect-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03161315.I-D@ietf.org> --NextPart 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 --NextPart-- From ipsec-bounces@ietf.org Mon Nov 3 16:23: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 446A93A6CD3; Mon, 3 Nov 2008 16:23:17 -0800 (PST) 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 5B7CD3A6CC0 for ; Mon, 3 Nov 2008 16:23:15 -0800 (PST) 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 1TvLkpXeqxYJ for ; Mon, 3 Nov 2008 16:23:14 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 1B9A33A6CBF for ; Mon, 3 Nov 2008 16:22:59 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so3089025wfd.31 for ; Mon, 03 Nov 2008 16:22:56 -0800 (PST) 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:content-transfer-encoding :content-disposition; bh=XcW4n5nG/8qsfpZoTryrCsNhNmceHjRCmmc619W5oz4=; b=NqU+0Mjr3AeIcxYoOrStvpEAMrMwiPjPcFJmSjXksTSTFzAY076lZWZ+EvAmDavLGL 3BrejUDA1nPIGKzwzvWLHzFgY6daOajcUAZe+LFxEI1VSQdgC6e/9/1RQVOzqIc9mt6P pqooXv8k2ZGnRyH92FiwVBkuirQRjz08QAh2c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=FdpwOMs4sF2g4ozDLFIf5bUykgx8uWgUidldddSbZm+UHCuCTEOfUpELttwMfo7ZuW jOJzfR0yga9FCwu1Ce85Y7TBqIYnHgB6ZEaHT8ltfoUCZJ/uV57r0fg9mzAp+6hyWXoX CUe+TGALUsRb9OXqul7+lTEKxhCqcUIypnJPE= Received: by 10.142.177.7 with SMTP id z7mr431198wfe.15.1225758176709; Mon, 03 Nov 2008 16:22:56 -0800 (PST) Received: by 10.142.225.19 with HTTP; Mon, 3 Nov 2008 16:22:56 -0800 (PST) Message-ID: Date: Mon, 3 Nov 2008 17:22:56 -0700 From: "Vijay Devarapalli" To: ipsec@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: [IPsec] Revised IKEv2 Re-direct draft 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, We just submitted a new draft version for the IKEv2 re-direct mechanism. Changes made in this version - Added a section on gateway-initiated re-direct. The earlier versions only spoke about re-direct during the IKE_SA_INIT exchange - Updated the reference to IKEv2bis draft - A few other minor fixes. Vijay 2008/11/3 : > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. > > > Title : Re-direct Mechanism for IKEv2 > Author(s) : V. Devarapalli, K. Weniger > Filename : draft-ietf-ipsecme-ikev2-redirect-01.txt > Pages : 12 > Date : 2008-11-03 > > 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-ietf-ipsecme-ikev2-redirect-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. > > > _______________________________________________ > 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 Nov 4 02:01: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 A0E243A698C; Tue, 4 Nov 2008 02:01:27 -0800 (PST) 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 BC1753A6972 for ; Tue, 4 Nov 2008 02:01:26 -0800 (PST) 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 PninjHei3xzR for ; Tue, 4 Nov 2008 02:01:16 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 657A23A698C for ; Tue, 4 Nov 2008 02:00:40 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 47341294005; Tue, 4 Nov 2008 12:00:25 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 290AB294003 for ; Tue, 4 Nov 2008 12:00:24 +0200 (IST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mA4A0NQC009467 for ; Tue, 4 Nov 2008 12:00:23 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 4 Nov 2008 12:00:22 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Tue, 4 Nov 2008 12:00:17 +0200 Thread-Topic: Ipsecme agenda for Minneapolis posted Thread-Index: Ack+ZCP9mJ2D7dv2RtCQbshKE0LmvA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A7811412@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [IPsec] Ipsecme agenda for Minneapolis posted 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="===============0172670897==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0172670897== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00E6_01C93E74.E78D5EE0" ------=_NextPart_000_00E6_01C93E74.E78D5EE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00E7_01C93E74.E78D5EE0" ------=_NextPart_001_00E7_01C93E74.E78D5EE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi everyone, We have posted the draft agenda at this link . Comments and corrections are welcome. Please note that we plan to spend most of the time on the last item: IKEv2-bis open issues. Thanks, Yaron ------=_NextPart_001_00E7_01C93E74.E78D5EE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi everyone,

 

We have posted the draft agenda at this link. Comments = and corrections are welcome.

 

Please note that we plan to spend most of the time on = the last item: IKEv2-bis open issues.

 

Thanks,

         =    Yaron

------=_NextPart_001_00E7_01C93E74.E78D5EE0-- ------=_NextPart_000_00E6_01C93E74.E78D5EE0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTEwNDEwMDAxN1owIwYJKoZIhvcNAQkEMRYEFFGAtuAh5gJZ pvZcLlEkvov1L7woMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA V+vvZudWSyl5pBpdCrag7FuuUacqeM4wXJ8lcOqOl9f2dzX/f+3pvRAhE5nEBgWbMyqSb4Qevolp bO/Ade3ZKb6SeH3gAsQdbJyCdvYVK8+ac2nzzlv4i6lqH6bhTvoKjmELRA7CppdLAFIC4GoOMTWS ya2r9TS9JI3E88sq6YTXjR2fC3uKCnfS47ARHl/Tgj4fWabZHTLiuzNZ3DpOI6oO1aEO4sBhscXg NYWmGJtOEersNxr6xwxWPW3cCXOYhnNlafqpnC3+Ui5IZOhvVN5J7RPL2v0CCfoPtptBhJpm8WFE bRHHMddnxbBRXnYiMLs3tz647CnBWyI27m0i7QAAAAAAAA== ------=_NextPart_000_00E6_01C93E74.E78D5EE0-- --===============0172670897== 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 --===============0172670897==-- From ipsec-bounces@ietf.org Tue Nov 4 14: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 B1B143A6CD8; Tue, 4 Nov 2008 14:09:12 -0800 (PST) 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 93D7B3A6CD8 for ; Tue, 4 Nov 2008 14:09:11 -0800 (PST) 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 rlI9gvA5dBSV for ; Tue, 4 Nov 2008 14:09:10 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 773C53A6A11 for ; Tue, 4 Nov 2008 14:09:10 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so2019748qwe.31 for ; Tue, 04 Nov 2008 14:09:06 -0800 (PST) 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=PFNCNGdib1kAx76kXInRfPit1OaX8rpk7YeVOvDVvJ4=; b=SzAbkmkUQx0pEqScwmesuM0M+2Yr8H7Zju/mQcyY9ikNCvvZ6pmaRXyvHBig7/4amM DlmbN9wvIACj6ZjnP1gbnyUNAkg5sMm8xSPiIKYHf4zhzRiZe6MwsIsUdwPF+MwIT1xw Uls5FJOsvhKSjey076O8/a0mBGW54PDxa2doM= 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=MYyzkXocutnKA7oWtcbQ/E54vg8ZAoUVqqZseDN81zGeYUaMZe8DwNgeTwTJ1ecSht PcjYf55YzUIP8kEjvt+X46mxn5bFnSlWUWv54ISQ41h9jMOTPem3g830hGkw1q3Mtlk0 um+V/6T2SWuGn3m+olr/j3TL9jH2j2YI7z3GI= Received: by 10.214.183.15 with SMTP id g15mr149571qaf.229.1225836546813; Tue, 04 Nov 2008 14:09:06 -0800 (PST) Received: by 10.215.100.8 with HTTP; Tue, 4 Nov 2008 14:09:06 -0800 (PST) Message-ID: Date: Tue, 4 Nov 2008 14:09:06 -0800 From: "fan zhao" To: "Vijay Devarapalli" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: ipsec@ietf.org Subject: Re: [IPsec] Revised IKEv2 Re-direct draft 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 and Killian, I have some comments on draft-ietf-ipsecme-ikev2-redirect-01. 1) The draft describes the redirection during the IKE_SA_INIT exchange and during the informational exchange that is after the SA is established. Please correct me if I am wrong. I think the redirection can be done during the IKE_AUTH exchange, right? We have discussed this before. 2) Near the end of section 3: "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." Based on RFC 4877, the lifetime of a dynamically assigned HoA is the same as that of the SA. So if the SA expires, the HoA expires and the BCE is invalid too, right? "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." If I understand correctly, in this case, the MN will use the anycast address in the IKE_SA_INIT, and then is redirected to the original home agent. Is this correct? 3) Some editorial issues: Abstract: 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. Maybe it is better: "The proposed mechanism can also be used in Mobile IPv6 ..." 3. IKEv2 Exchange with Redirect To redirect a IKEv2 session to s/a/an Thanks. Sincerely, fan On Mon, Nov 3, 2008 at 4:22 PM, Vijay Devarapalli wrote: > Hi, > > We just submitted a new draft version for the IKEv2 re-direct > mechanism. Changes made in this version > > - Added a section on gateway-initiated re-direct. The earlier versions > only spoke about re-direct during the IKE_SA_INIT exchange > - Updated the reference to IKEv2bis draft > - A few other minor fixes. > > Vijay > > > 2008/11/3 : >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. >> >> >> Title : Re-direct Mechanism for IKEv2 >> Author(s) : V. Devarapalli, K. Weniger >> Filename : draft-ietf-ipsecme-ikev2-redirect-01.txt >> Pages : 12 >> Date : 2008-11-03 >> >> 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-ietf-ipsecme-ikev2-redirect-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. >> >> >> _______________________________________________ >> 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 > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 5 14:23: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 1B0393A686A; Wed, 5 Nov 2008 14:23:35 -0800 (PST) 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 68E8A3A686A for ; Wed, 5 Nov 2008 14:23:34 -0800 (PST) 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 fkQrLny4BsIj for ; Wed, 5 Nov 2008 14:23:33 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 68DC83A6774 for ; Wed, 5 Nov 2008 14:23:33 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so257316wfd.31 for ; Wed, 05 Nov 2008 14:23:07 -0800 (PST) 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=ZTEtbaVzlnHM8NRjGVlO7pYN6OmcuLXPr0MUUX6n4os=; b=uh3K0noy8myszHBIb7Jfz9qa4oZwt2zVusFBC2r0Dg3rpwFmTJViteOh7JXqL7+SM0 PkNz8Cp7j3URAo09e7EzjmAzWTDRmUlGrLCzvp5VRpP3VXFjoEZF/AUjL7Ci50P1aGUO jzmLbqHpBPxVppvM83BTndrE0Nujmycr+jbg0= 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=PSHHu9CGyg4GaT/TGQcdzMdQB7vndvPp660mXrMVpWTCs8dsfY9eZQJnDlIKpmBVNd 0PXb46nL4SjY2xeey6lGBK9P680i1BF8VrF6ha+sWVUwz29TrkwrR+DvygMHNvTJLXeC dMA3Au6W10twUH9VIuN4g1sVh9GKNiAbf5dfs= Received: by 10.142.125.9 with SMTP id x9mr54574wfc.85.1225923787689; Wed, 05 Nov 2008 14:23:07 -0800 (PST) Received: by 10.142.225.19 with HTTP; Wed, 5 Nov 2008 14:23:07 -0800 (PST) Message-ID: Date: Wed, 5 Nov 2008 15:23:07 -0700 From: "Vijay Devarapalli" To: "fan zhao" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: ipsec@ietf.org Subject: Re: [IPsec] Revised IKEv2 Re-direct draft 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 Fan, On Tue, Nov 4, 2008 at 3:09 PM, fan zhao wrote: > Hi, Vijay and Killian, > > I have some comments on draft-ietf-ipsecme-ikev2-redirect-01. > > 1) The draft describes the redirection during the IKE_SA_INIT exchange > and during the informational exchange that is after the SA is established. > Please correct me if I am wrong. I think the redirection can be done during > the IKE_AUTH exchange, right? We have discussed this before. Yes, but this change has not been made yet. I had presented this issue at the last IETF, but there were no comments. I was looking for a little bit more discussion on this before adding this to the document. > 2) Near the end of section 3: > > "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." > Based on RFC 4877, the lifetime of a dynamically assigned HoA is > the same as that of the SA. So if the SA expires, the HoA expires > and the BCE is invalid too, right? The home address and the binding cache entry are not marked invalid right away. If the SAs expire, the mobile node can run IKEv2 with the home agent again and request for the same home address. > "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." > > If I understand correctly, in this case, the MN will use the anycast address > in the IKE_SA_INIT, and then is redirected to the original home agent. > Is this correct? No, we wanted to say that the mobile node should try running IKEv2 again with the existing home agent. Not use the anycast address as the destination address for the IKE_SA_INIT exchange. > 3) Some editorial issues: > > Abstract: 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. > > Maybe it is better: > "The proposed mechanism can also be used in Mobile IPv6 ..." > > > 3. IKEv2 Exchange with Redirect > To redirect a IKEv2 session to > > s/a/an Thanks for catching these. Vijay > > Thanks. > > Sincerely, > fan > > > On Mon, Nov 3, 2008 at 4:22 PM, Vijay Devarapalli wrote: >> Hi, >> >> We just submitted a new draft version for the IKEv2 re-direct >> mechanism. Changes made in this version >> >> - Added a section on gateway-initiated re-direct. The earlier versions >> only spoke about re-direct during the IKE_SA_INIT exchange >> - Updated the reference to IKEv2bis draft >> - A few other minor fixes. >> >> Vijay >> >> >> 2008/11/3 : >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. >>> >>> >>> Title : Re-direct Mechanism for IKEv2 >>> Author(s) : V. Devarapalli, K. Weniger >>> Filename : draft-ietf-ipsecme-ikev2-redirect-01.txt >>> Pages : 12 >>> Date : 2008-11-03 >>> >>> 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-ietf-ipsecme-ikev2-redirect-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. >>> >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 5 14:34: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 3EF233A6829; Wed, 5 Nov 2008 14:34:15 -0800 (PST) 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 7413A3A67FC for ; Wed, 5 Nov 2008 14:34:13 -0800 (PST) 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 zbMgzmw5WiVz for ; Wed, 5 Nov 2008 14:34:12 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 414013A63D2 for ; Wed, 5 Nov 2008 14:34:12 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so204376qwe.31 for ; Wed, 05 Nov 2008 14:33:18 -0800 (PST) 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=NzQdDN/7xOgUP/rbl8bHolMgy/hLgttI/voVTKVzN6M=; b=MjBvpQvchsSq098wOo0un0n9QPDzsXGrnVbQaIhO4BqxjZxIvTEzu4ruJ4ixIfHR4i rSEwRi8bCdcFxT1eayWN6hQrKJ2e5av3VK9WS1H/0ykDFnRhTybi2qEHpqisWvIEr65W 3oEkJu/NEmDt1i02SInojiRrg8EnlDIssndiE= 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=wTdq45CJmeAaLnIyxGkA69GdVzbl4uBfvPORMuq5txnf+TAgPTeglhqHj2rV4lVBvA PvPN4l6xTLIpS25kht9shK1bpZZj6/E1zE6FK0evPy+avPliJCikDZHBv4rhzupT1Qu1 W32JElne7eHByvjpoaYc1/Z5mfgyBZFVD8VsM= Received: by 10.215.12.5 with SMTP id p5mr1444008qai.270.1225924398707; Wed, 05 Nov 2008 14:33:18 -0800 (PST) Received: by 10.215.100.8 with HTTP; Wed, 5 Nov 2008 14:33:18 -0800 (PST) Message-ID: Date: Wed, 5 Nov 2008 14:33:18 -0800 From: "fan zhao" To: "Vijay Devarapalli" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: ipsec@ietf.org Subject: Re: [IPsec] Revised IKEv2 Re-direct draft 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, Thanks for your reply. Please see below. On Wed, Nov 5, 2008 at 2:23 PM, Vijay Devarapalli wrote: > Hi Fan, > > On Tue, Nov 4, 2008 at 3:09 PM, fan zhao wrote: >> Hi, Vijay and Killian, >> >> I have some comments on draft-ietf-ipsecme-ikev2-redirect-01. >> >> 1) The draft describes the redirection during the IKE_SA_INIT exchange >> and during the informational exchange that is after the SA is established. >> Please correct me if I am wrong. I think the redirection can be done during >> the IKE_AUTH exchange, right? We have discussed this before. > > Yes, but this change has not been made yet. I had presented this issue > at the last IETF, but there were no comments. I was looking for a > little bit more discussion on this before adding this to the document. OK. > >> 2) Near the end of section 3: >> >> "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." >> Based on RFC 4877, the lifetime of a dynamically assigned HoA is >> the same as that of the SA. So if the SA expires, the HoA expires >> and the BCE is invalid too, right? > > The home address and the binding cache entry are not marked invalid > right away. If the SAs expire, the mobile node can run IKEv2 with the > home agent again and request for the same home address. OK. This can be done. > >> "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." >> >> If I understand correctly, in this case, the MN will use the anycast address >> in the IKE_SA_INIT, and then is redirected to the original home agent. >> Is this correct? > > No, we wanted to say that the mobile node should try running IKEv2 > again with the existing home agent. Not use the anycast address as the > destination address for the IKE_SA_INIT exchange. I agree with what you said. Somehow, I read the text differently. Thanks. Sincerely, fan > >> 3) Some editorial issues: >> >> Abstract: 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. >> >> Maybe it is better: >> "The proposed mechanism can also be used in Mobile IPv6 ..." >> >> >> 3. IKEv2 Exchange with Redirect >> To redirect a IKEv2 session to >> >> s/a/an > > Thanks for catching these. > > Vijay > >> >> Thanks. >> >> Sincerely, >> fan >> >> >> On Mon, Nov 3, 2008 at 4:22 PM, Vijay Devarapalli wrote: >>> Hi, >>> >>> We just submitted a new draft version for the IKEv2 re-direct >>> mechanism. Changes made in this version >>> >>> - Added a section on gateway-initiated re-direct. The earlier versions >>> only spoke about re-direct during the IKE_SA_INIT exchange >>> - Updated the reference to IKEv2bis draft >>> - A few other minor fixes. >>> >>> Vijay >>> >>> >>> 2008/11/3 : >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. >>>> >>>> >>>> Title : Re-direct Mechanism for IKEv2 >>>> Author(s) : V. Devarapalli, K. Weniger >>>> Filename : draft-ietf-ipsecme-ikev2-redirect-01.txt >>>> Pages : 12 >>>> Date : 2008-11-03 >>>> >>>> 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-ietf-ipsecme-ikev2-redirect-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. >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 6 09:32: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 0DEF63A6A24; Thu, 6 Nov 2008 09:32:13 -0800 (PST) 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 863FC3A6A24 for ; Thu, 6 Nov 2008 09:32:11 -0800 (PST) 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 s6t12nXJVKLX for ; Thu, 6 Nov 2008 09:32:10 -0800 (PST) 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 1C1873A6992 for ; Thu, 6 Nov 2008 09:32:09 -0800 (PST) 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 mA6HVx2L020761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Nov 2008 10:32:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 6 Nov 2008 09:31:55 -0800 To: IPsecme WG From: Paul Hoffman Subject: [IPsec] Moving forwards on session resumption 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 Greetings again. As you know, we have an item in our charter to have an extension to handle session resumption. The charter says: ======================================= - 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 negotiation 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 gateway 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. ======================================= There were two proposals for this work, draft-tschofenig-ipsecme-ikev2-resumption and draft-xu-ike-sa-sync. The have both gone through revisions and been discussed on the mailing list. The charter is quite clear that the Working Group is supposed to produce one extension, not two. Because of that, I have had to pick the one that would be best for the Working Group to work on. Based on the discussion on the list and a careful reading of the latest version of the two drafts, and comparing the two drafts to the charter requirement above, I have chosen draft-tschofenig-ipsecme-ikev2-resumption as the starting point for the Working Group. (My co-chair recused himself from the decision because he is co-author on one of the candidate documents.) In discussing this decision offline with the co-authors of draft-xu-ike-sa-sync, they have expressed a desire to have the Working Group decide between the two documents. I explained that it is, in fact, the job of the chair to pick documents and authors; the Working Group's task is to make the work items be as good as possible. I based my decision on the completeness of the two proposed solutions and how well each proposal matched the charter. In the end, the two proposed solutions would be technically quite similar when draft-xu-ike-sa-sync was more complete and removed the extraneous material. Further, the co-authors of draft-xu-ike-sa-sync have repeatedly said that they do not like the restrictions in the charter; my response to them is the same as it is to the WG, namely that re-opening the charter discussion at this point is waste of time and is not an option. Given that, I request that the co-authors of draft-tschofenig-ipsecme-ikev2-resumption prepare to submit draft-ietf-ipsecme-ikev2-resumption-00 on Monday, Nov. 17. It should match draft-tschofenig-ipsecme-ikev2-resumption-01 exactly, other than the draft name change. The WG can start discussion the current draft-tschofenig-ipsecme-ikev2-resumption draft immediately. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 7 08:12: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 BC2423A684A; Fri, 7 Nov 2008 08:12:54 -0800 (PST) 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 218253A684A for ; Fri, 7 Nov 2008 08:12:53 -0800 (PST) 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_72=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 sv+u5sgJf+O4 for ; Fri, 7 Nov 2008 08:12:51 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 4D1A63A67AA for ; Fri, 7 Nov 2008 08:12:50 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so555390eyd.31 for ; Fri, 07 Nov 2008 08:11:47 -0800 (PST) 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=MQbuLlSnhYGYkC5Ijo+wLIYlUvDOh6cJueBFvzYzWx4=; b=ebv/Q+JTyNP//2F3r3hlvBatt+MG0IwNpkWT8HSWz2pmTYLF/+hS/Z2SjX9/4xn3Hy HxVKbiCSHhvOahy/F39eAJLP1RIp98h2CRe4raeTtANuEfgSUx2Hq7KhguY1CKzbto0V opXOQxEbi+hQeX9tHe/P1k845ruT2gN3pC1Lo= 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=dIC5tMb87GZIQCDRoOgxsU4pMwGejUbwoGLFZGeOVzY0Jo60++6zT9A31VUptjSTXc KRVehEJMK4o3SkZe11jI83jTSmeuZpBpG8qzleQCKIjrXkf/Oh54iGEfAL15PO01sVKT aBIh+JBp1B4bajVvPlrbdlBywalTfmGWYQDkA= Received: by 10.210.86.10 with SMTP id j10mr4077242ebb.181.1226074307031; Fri, 07 Nov 2008 08:11:47 -0800 (PST) Received: by 10.210.109.14 with HTTP; Fri, 7 Nov 2008 08:11:46 -0800 (PST) Message-ID: <1d38a3350811070811o6010bfdaw6e5ac061bce4d0d4@mail.gmail.com> Date: Sat, 8 Nov 2008 00:11:46 +0800 From: "Hui Deng" To: "Paul Hoffman" In-Reply-To: MIME-Version: 1.0 References: Cc: IPsecme WG Subject: Re: [IPsec] Moving forwards on session resumption 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="===============0734155496==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0734155496== Content-Type: multipart/alternative; boundary="----=_Part_41508_18903572.1226074307012" ------=_Part_41508_18903572.1226074307012 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear Chairs and all As the co-author of the draft-xu, I would like to question this decision. 1) I carefully read the reason of this decision below, found no any technical or concensus summary other than chairs own chosen. 2) Chair here say that authors of the draft-xu is not seeking for the concensus, I can show offline disucssion email if needed, authors of the draft-xu express clearly several times that they are expecting the concensus. 3) Regarding to the restrictions in the charter, I feel confused why chair call the discussion. http://www.ietf.org/mail-archive/web/ipsec/current/msg03232.html, it seems useless,no any technical summary for this discussion. For the wasting of time, I didn't see any deployment urgency for that technology, on the contrary, draft-xu is interested in by a scale operator. I guess that IETF always choose the more concensused and better solution. 4) authors of draft-xu would like to appeal this decision to the end, please wg chair and IESG chair sincerely consider this decision. we need sometime to prepare the appeal to IESG chair. 5) One remindness, please draft-tschofenig refer to other draft if it is using idea from it. Many thanks -Hui 2008/11/7 Paul Hoffman > > > Greetings again. As you know, we have an item in our charter to have an > extension to handle session resumption. The charter says: > > ======================================= > - 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 negotiation 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 gateway 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. > ======================================= > > There were two proposals for this work, > draft-tschofenig-ipsecme-ikev2-resumption and draft-xu-ike-sa-sync. The have > both gone through revisions and been discussed on the mailing list. > > The charter is quite clear that the Working Group is supposed to produce > one extension, not two. Because of that, I have had to pick the one that > would be best for the Working Group to work on. Based on the discussion on > the list and a careful reading of the latest version of the two drafts, and > comparing the two drafts to the charter requirement above, I have chosen > draft-tschofenig-ipsecme-ikev2-resumption as the starting point for the > Working Group. (My co-chair recused himself from the decision because he is > co-author on one of the candidate documents.) > > In discussing this decision offline with the co-authors of > draft-xu-ike-sa-sync, they have expressed a desire to have the Working Group > decide between the two documents. I explained that it is, in fact, the job > of the chair to pick documents and authors; the Working Group's task is to > make the work items be as good as possible. I based my decision on the > completeness of the two proposed solutions and how well each proposal > matched the charter. In the end, the two proposed solutions would be > technically quite similar when draft-xu-ike-sa-sync was more complete and > removed the extraneous material. > > Further, the co-authors of draft-xu-ike-sa-sync have repeatedly said that > they do not like the restrictions in the charter; my response to them is the > same as it is to the WG, namely that re-opening the charter discussion at > this point is waste of time and is not an option. > > Given that, I request that the co-authors of > draft-tschofenig-ipsecme-ikev2-resumption prepare to submit > draft-ietf-ipsecme-ikev2-resumption-00 on Monday, Nov. 17. It should match > draft-tschofenig-ipsecme-ikev2-resumption-01 exactly, other than the draft > name change. The WG can start discussion the current > draft-tschofenig-ipsecme-ikev2-resumption draft immediately. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > ------=_Part_41508_18903572.1226074307012 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Dear Chairs and all
 
As the co-author of the draft-xu, I would like to question this decision.
 
1) I carefully read the reason of this decision below, found no any technical or concensus summary other than chairs own chosen.
 
2) Chair here say that authors of the draft-xu is not seeking for the concensus,
I can show offline disucssion email if needed, authors of the draft-xu express clearly several times that they are expecting the concensus.
 
3) Regarding to the restrictions in the charter, I feel confused why chair call the discussion. 
http://www.ietf.org/mail-archive/web/ipsec/current/msg03232.html, it seems useless,no any technical summary for this discussion.
For the wasting of time, I didn't see any deployment urgency for that technology, on the contrary, draft-xu is interested in by a scale operator. I guess that IETF always choose the more concensused and better solution.
 
4) authors of draft-xu would like to appeal this decision to the end, please wg chair and IESG chair sincerely consider this decision. we need sometime to prepare the appeal to IESG chair.
 
5) One remindness, please draft-tschofenig refer to other draft if it is using idea from it.
 
Many thanks
 
-Hui
 
2008/11/7 Paul Hoffman <paul.hoffman@vpnc.org>
<co-chair hat on>

Greetings again. As you know, we have an item in our charter to have an extension to handle session resumption. The charter says:

=======================================
- 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 negotiation 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 gateway 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.
=======================================

There were two proposals for this work, draft-tschofenig-ipsecme-ikev2-resumption and draft-xu-ike-sa-sync. The have both gone through revisions and been discussed on the mailing list.

The charter is quite clear that the Working Group is supposed to produce one extension, not two. Because of that, I have had to pick the one that would be best for the Working Group to work on. Based on the discussion on the list and a careful reading of the latest version of the two drafts, and comparing the two drafts to the charter requirement above, I have chosen draft-tschofenig-ipsecme-ikev2-resumption as the starting point for the Working Group. (My co-chair recused himself from the decision because he is co-author on one of the candidate documents.)

In discussing this decision offline with the co-authors of draft-xu-ike-sa-sync, they have expressed a desire to have the Working Group decide between the two documents. I explained that it is, in fact, the job of the chair to pick documents and authors; the Working Group's task is to make the work items be as good as possible. I based my decision on the completeness of the two proposed solutions and how well each proposal matched the charter. In the end, the two proposed solutions would be technically quite similar when draft-xu-ike-sa-sync was more complete and removed the extraneous material.

Further, the co-authors of draft-xu-ike-sa-sync have repeatedly said that they do not like the restrictions in the charter; my response to them is the same as it is to the WG, namely that re-opening the charter discussion at this point is waste of time and is not an option.

Given that, I request that the co-authors of draft-tschofenig-ipsecme-ikev2-resumption prepare to submit draft-ietf-ipsecme-ikev2-resumption-00 on Monday, Nov. 17. It should match draft-tschofenig-ipsecme-ikev2-resumption-01 exactly, other than the draft name change. The WG can start discussion the current draft-tschofenig-ipsecme-ikev2-resumption draft immediately.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

------=_Part_41508_18903572.1226074307012-- --===============0734155496== 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 --===============0734155496==-- From ipsec-bounces@ietf.org Fri Nov 7 08:23:40 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 3AAC63A6B54; Fri, 7 Nov 2008 08:23:40 -0800 (PST) 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 CC92E3A6B54 for ; Fri, 7 Nov 2008 08:23:39 -0800 (PST) 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 UxEV80hfVx+I for ; Fri, 7 Nov 2008 08:23:39 -0800 (PST) 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 9028F3A69A4 for ; Fri, 7 Nov 2008 08:23:38 -0800 (PST) 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 mA7GNWUR017450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 09:23:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 7 Nov 2008 08:23:30 -0800 To: IPsecme WG From: Paul Hoffman Subject: [IPsec] Fwd: Posting of IPR Disclosure 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 Forwarded from the IETF Secretariat: >An IPR disclosure that pertains to your RFC entitled "Algorithms for Internet >Key Exchange version 1 (IKEv1)" (RFC4109) was submitted to the IETF Secretariat >on 2008-10-30 and has been posted on the "IETF Page of Intellectual Property >Rights Disclosures" (https://datatracker.ietf.org/public/ipr_list.cgi). The >title of the IPR disclosure is "Certicom's Statement about IPR related to RFC >4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC >4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC >3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...." > >The IETF Secretariat --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 7 08:41: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 D2C2C3A6942; Fri, 7 Nov 2008 08:41:53 -0800 (PST) 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 378B03A69A4 for ; Fri, 7 Nov 2008 08:41:53 -0800 (PST) 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 ENRIlUi-hjNn for ; Fri, 7 Nov 2008 08:41:52 -0800 (PST) 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 056793A6358 for ; Fri, 7 Nov 2008 08:41:51 -0800 (PST) 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 mA7GfjsZ019148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Nov 2008 09:41:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1d38a3350811070811o6010bfdaw6e5ac061bce4d0d4@mail.gmail.com> References: <1d38a3350811070811o6010bfdaw6e5ac061bce4d0d4@mail.gmail.com> Date: Fri, 7 Nov 2008 08:41:44 -0800 To: IPsecme WG From: Paul Hoffman Subject: Re: [IPsec] Moving forwards on session resumption 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 At 12:11 AM +0800 11/8/08, Hui Deng wrote: >Dear Chairs and all > >As the co-author of the draft-xu, I would like to question this decision. Hui was earlier informed of the decision and its rationale, and was also informed of the formal way to disagree with it. One of his co-authors has said that they are working on doing so the correct way. The mailing list should continue with the discussion of draft-tschofenig-ipsecme-ikev2-resumption regardless of Hui's misunderstanding of the IETF process. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Nov 9 02:54: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 1981F3A6915; Sun, 9 Nov 2008 02:54:10 -0800 (PST) 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 05EDA3A6964 for ; Sun, 9 Nov 2008 02:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.184 X-Spam-Level: X-Spam-Status: No, score=-1.184 tagged_above=-999 required=5 tests=[AWL=-1.185, BAYES_50=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 QXc7PMe3vi+h for ; Sun, 9 Nov 2008 02:54:07 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D76F53A6958 for ; Sun, 9 Nov 2008 02:54:06 -0800 (PST) Received: (qmail invoked by alias); 09 Nov 2008 10:54:01 -0000 Received: from a91-154-101-110.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.101.110] by mail.gmx.net (mp044) with SMTP; 09 Nov 2008 11:54:01 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+xpqJQfGyx6soCx0iPe3FWNHOe9bRUsQllHNELOp nqlnuR77WfDZau From: "Hannes Tschofenig" To: Date: Sun, 9 Nov 2008 12:54:01 +0200 Message-ID: <006701c94259$7a832f30$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclCWXmII6loYMcfTjSPmpbyU/UtZQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 Subject: [IPsec] Session Resumption 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 something I just noticed. With draft-tschofenig-ipsecme-ikev2-resumption-01.txt I submitted an older local copy of the draft. The latest version is here: http://tinyurl.com/5dtrz7 Sorry about that. Ciao Hannes _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Nov 9 03:11: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 D77FB3A68B2; Sun, 9 Nov 2008 03:11:55 -0800 (PST) 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 4331F3A68B2 for ; Sun, 9 Nov 2008 03:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.206, 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 WIIyiJsBABKp for ; Sun, 9 Nov 2008 03:11:53 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6DF563A6885 for ; Sun, 9 Nov 2008 03:11:51 -0800 (PST) Received: (qmail invoked by alias); 09 Nov 2008 11:11:46 -0000 Received: from a91-154-101-110.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.101.110] by mail.gmx.net (mp026) with SMTP; 09 Nov 2008 12:11:46 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/HdWxweXnHdd9BYXi1SAMh1xDvG89qEbMEVP4apy Nd8hh6eJRhfZNv From: "Hannes Tschofenig" To: "'Dan Harkins'" References: <200810161744113434215@mail.tsinghua.edu.cn><7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7DA@il-ex01.ad.checkpoint.com><1d38a3350810201135o22321abcw7ff23bfc5b28114e@mail.gmail.com><7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E3@il-ex01.ad.checkpoint.com> <03ff01c932e8$bbf3fa60$0900a8c0@nsnintra.net> <040501c932ec$20f3a980$0900a8c0@nsnintra.net> <6ebe21296f38bcced604f912ee5583fd.squirrel@www.trepanning.net> Date: Sun, 9 Nov 2008 13:11:46 +0200 Message-ID: <006a01c9425b$f59c05f0$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckzBjDmxpa9qi+RT/qUrNHlVeNHRgPTfvig In-Reply-To: <6ebe21296f38bcced604f912ee5583fd.squirrel@www.trepanning.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Cc: 'Hui Deng' , 'ipsec' , xuke@mail.tsinghua.edu.cn Subject: Re: [IPsec] Resuming the session resumption discussion 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 address your comment, Dan, I have added the recommended format back into the document. See Appendix A in http://tools.ietf.org/html/draft-tschofenig-ipsecme-ikev2-resumption-01 Ciao Hannes >-----Original Message----- >From: Dan Harkins [mailto:dharkins@lounge.org] >Sent: 21 October, 2008 01:50 >To: Hannes Tschofenig >Cc: 'Hannes Tschofenig'; 'Yaron Sheffer'; 'Hui Deng'; 'ipsec'; >xuke@mail.tsinghua.edu.cn >Subject: Re: [IPsec] Resuming the session resumption discussion > > > Well, strictly speaking it says "detailed contents" so I >guess it depends on what the word "detailed" means. > > If nothing is said on the matter I fear that the scenario >that Xuke mentioned will happen. Just because there are no >interoperability requirements on some particular part of a >protocol does not mean we can't recommend (or even insist >upon) behavior. There is precedence for recommending behavior >on things that have no interoperability impact. > > If the opaque blob is a reference or index into some >server-maintained context and has no sensitive components then >there really isn't much to worry about but if the opaque blob >contains cryptographic keying material then I don't think we >can be silent on the matter. > > Dan. > >On Mon, October 20, 2008 12:43 pm, Hannes Tschofenig wrote: >> I thought about using the term "ticket blob" again and I >think it is a >> really good idea. >> It puts a stronger emphasis on the fact that the document is not >> supposed to specify the content of the payload. >> >> I guess I will make this change to the draft. >> >> Thoughts? >> >>>-----Original Message----- >>>From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] >On Behalf >>>Of Hannes Tschofenig >>>Sent: 20 October, 2008 22:19 >>>To: 'Yaron Sheffer'; 'Hui Deng' >>>Cc: 'ipsec'; xuke@mail.tsinghua.edu.cn >>>Subject: Re: [IPsec] Resuming the session resumption discussion >>> >>>Since we got asked by the group to get rid of the ticket format >>>recommendations I believe we don't need to talk about the content at >>>all. >>>As such, it could be anything. We could call it ticket blob. >>> >>>I guess that should make everyone happy. >>> >>>Ciao >>>Hannes >>> >>> >>> >>>________________________________ >>> >>> From: ipsec-bounces@ietf.org >>>[mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer >>> Sent: 20 October, 2008 21:57 >>> To: Hui Deng >>> Cc: ipsec; xuke@mail.tsinghua.edu.cn >>> Subject: Re: [IPsec] Resuming the session resumption discussion >>> >>> >>> >>> Hi Hui, >>> >>> >>> >>> Yes, we should have cited your draft. And we could have >had a more >>>detailed description of the changes from the previous version. >>> >>> >>> >>> Note however that the idea of server-side storage of >crypto protocol >>>state has been around for ages, e.g. in the TLS "session >cache" notion >>>(RFC 2246). >>> >>> >>> >>> Thanks, >>> >>> Yaron >>> >>> >>> >>> ________________________________ >>> >>> From: Hui Deng [mailto:denghui02@gmail.com] >>> Sent: Monday, October 20, 2008 20:36 >>> To: Yaron Sheffer >>> Cc: xuke@mail.tsinghua.edu.cn; ipsec >>> Subject: Re: [IPsec] Resuming the session resumption discussion >>> >>> >>> >>> Dear authors, >>> >>> >>> >>> I would not like to offend how your authors are doing here. >>> >>> >>> >>> But we do carefully read through your previous draft and your >>>"update" part of the new draft, >>> >>> Nothing could be found related to the "ticket reference". >>> >>> >>> >>> In such case, something would better be reminded that >if some idea >>>has been invented by the other draft, and you would like to >use it by >>>some revised form, please do refer to that draft. >>> >>> >>> >>> Many thanks >>> >>> >>> >>> -Hui >>> >>> 2008/10/20 Yaron Sheffer >>> >>> >>> >>> Seen from a protocol point of view, it is critically >important that >>>the >>> ticket (or stub) is secured. But the contents of the >ticket is much >>>less >>> critical, since it is opaque to the client anyway. >>> >>> Draft-tschofenig mentions that the ticket can contain >the actual IKE >>> (subset-) state, or it can contain a reference >>>(pointer) to such state, >>> which is presumably stored on the gateway or near it. Quoting: >>> >>> Ticket reference: A pointer to a ticket. When >resolving the >>> reference it obtains the ticket. >>> >>> In subsequent sections we use the term ticket >and thereby >>>refer to >>> both the ticket per value and by reference, unless indicated >>>otherwise. >>> >>> (And yes, we could do a better job of mentioning this >concept in Sec. >>>5, >>> where we describe the ticket in detail.) >>> >>> >>> Thanks, >>> Yaron >>> >>> -----Original Message----- >>> From: ipsec-bounces@ietf.org >>>[mailto:ipsec-bounces@ietf.org] On Behalf Of >>> >>> xuke >>> Sent: Thursday, October 16, 2008 11:44 >>> To: ipsec >>> Subject: Re: [IPsec] Resuming the session resumption discussion >>> >>> Hi, all >>> >>> Basically, I agree with Yoav that the "ticket" concept is very >>>similar >>> to the "stub" concept. >>> We did once thought to store the stub in the >corresponding client >>> separately. And, in our draft, we also analyzed this case. >>> However, In the case of stub co-located with IPsec >Client, the stub >>> MUST be perfectly protected to prevent the malicious >attackers from >>> cracking the stub, if they can obtain the stub on the link. >>>Actually, >>> from previous experiences, even if the stub is strongly >encrypted, >>> there still has the risk. With the development of >harware in accord >>> with the Moore's Law, the capability of computing >equipment will be >>> increased step by step. Sometime, somehow, the brutal force >>>decryption >>> of the stub/ticket encryption method may be possible. >>>And, there is >>> also posibility that the currently safe encryption >algorithm may be >>> proved to be mathematically solvable. So, in our >draft, it is only >>> optional to transport the stub on the untrusted >network, even if it >>> can be protected strongly. >>> >>> And, If we see it from the client point of view, the >client does not >>> need to maintain a data structure to store the stubs. >>> Lastly, in the mobile network, the transfer of stubs >over the air at >>> client side surely have much more service cost than >doing it over the >>> fiber in network side. >>> >>> All in all, to keep the client to be simpler, easier >for upgrade in >>> the future and keep the stub safer, personally, I'd >rather to keep >>>the >>> stub in the network side. >>> >>> xuke >>> Tsinghua University >>> >>> > >>> > >>> > We now have revised drafts from the two parties who >has published >>>earlier >>> drafts on session resumption. The (truncated) announcements are >>>below. >>> > >>> > The WG should start discussing what we want from >session resumption >>>and >>> which of these two drafts (or what ideas from each of these two >>>drafts) is >>> of interest to the WG. As a reminder, I start off with what our >>>charter >>> says. >>> > >>> > Extra points are awarded for not copying this entire >message in >>>your >>> response. :-) >>> > >>> > --Paul Hoffman >>> > >>> _______________________________________________ >>> IPsec mailing list >>> IPsec at 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 >>> >>> >>> >>> >>> >>> 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 >> > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 11 17: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 8F9FB3A682B; Tue, 11 Nov 2008 17:09:12 -0800 (PST) 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 D5B8E3A682B for ; Tue, 11 Nov 2008 17:09:11 -0800 (PST) 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 FltCFpBxpAL9 for ; Tue, 11 Nov 2008 17:09:11 -0800 (PST) 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 9C4223A67E6 for ; Tue, 11 Nov 2008 17:09:10 -0800 (PST) Received: from [165.227.249.203] (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 mAC192pI012072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Nov 2008 18:09:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 11 Nov 2008 17:09:00 -0800 To: IPsecme WG From: Paul Hoffman Subject: [IPsec] Additions/changes to the agenda? 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 Greetings again. We are less than a week away from the WG meeting, and Yaron and I want to be sure that anyone who has agenda items () have told us. Send me mail off-list if you have any additions or changes. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 12 00:01:26 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 7C7093A681D; Wed, 12 Nov 2008 00:01:26 -0800 (PST) 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 AD9103A681D for ; Wed, 12 Nov 2008 00:01:24 -0800 (PST) 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 wV7yYVHUvWIK for ; Wed, 12 Nov 2008 00:01:24 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 500BA3A67A8 for ; Wed, 12 Nov 2008 00:01:23 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 5359829C001; Wed, 12 Nov 2008 10:01:23 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 2BFCA294003; Wed, 12 Nov 2008 10:01:22 +0200 (IST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mAC81LQC025045; Wed, 12 Nov 2008 10:01:21 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 12 Nov 2008 10:01:20 +0200 From: Yaron Sheffer To: IPsecme WG , "Ertekin, Emre [USA]" Importance: high Date: Wed, 12 Nov 2008 10:01:15 +0200 Thread-Topic: [IPsec] Additions/changes to the agenda? Thread-Index: AclEY0zBdxWX+c5xTuO+dyIqWeHcLwAN7Ehg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A7811BC3@il-ex01.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [IPsec] Additions/changes to the agenda? 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="===============1974222959==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1974222959== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001F_01C94459.C7F3C6B0" ------=_NextPart_000_001F_01C94459.C7F3C6B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Also, all authors of drafts on the agenda, please send us your slides by Thursday end of day. Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Tuesday, November 11, 2008 17:09 To: IPsecme WG Subject: [IPsec] Additions/changes to the agenda? Greetings again. We are less than a week away from the WG meeting, and Yaron and I want to be sure that anyone who has agenda items () have told us. Send me mail off-list if you have any additions or changes. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. ------=_NextPart_000_001F_01C94459.C7F3C6B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTExMjA4MDExNVowIwYJKoZIhvcNAQkEMRYEFBp51yLWNr2o dSqNJyasw2KqKmKtMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA PQqMb0Fsiob0RHBo8hFxGmQmEtk8kb3KW77ZjSPfxFl/anEXO9WlsTjsqOkrppXLGl/XaN1WBY9z s4Q5hRvFd7fbDyNawqLAWA9911zHmjsprfDouQc9m8I8WDtZenWJtoKB0A77Hc67gRUNbhLkpErB FhyiNWL6reL+urJ/jlFxyiJdJBVYUPuYynlIkg7h8sG22iHh6YXmf2G3qheniEd+t6yCARDKryJV SoznNUhMl8SBDU3+pi3YOlHOn8eRg3JVELz6l4cCIgICjrVjJM4to2P2+CHS13R5mX/u6kRCyyiB HYKF7X630BOx6NY4xyA2UoQTdu3ybkLXCfI9ZQAAAAAAAA== ------=_NextPart_000_001F_01C94459.C7F3C6B0-- --===============1974222959== 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 --===============1974222959==-- From ipsec-bounces@ietf.org Thu Nov 13 18:27: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 39F1C3A686B; Thu, 13 Nov 2008 18:27:14 -0800 (PST) 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 5795B3A683F for ; Thu, 13 Nov 2008 18:27:12 -0800 (PST) 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 l+xACkaH3Cv5 for ; Thu, 13 Nov 2008 18:27:11 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by core3.amsl.com (Postfix) with ESMTP id 25DD43A6808 for ; Thu, 13 Nov 2008 18:27:10 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id b11so644582nfh.39 for ; Thu, 13 Nov 2008 18:27:09 -0800 (PST) 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=HDNbLvtRN88Og4wCNWRs5V9uEZ37BbA6FlR1A0QAJnk=; b=Mn0y+q3W/G9MSPzKUwzLgzyvZej431758VwG/Z2a8+2YiVCtcygMnyUHtot807L04x 6OgG6vCA5g+OMWPIDYhw+nTpGyQCXpHOmnjFLv0OdMCOGp/501ZTEHJyVMMdXmYdCxGK 1T9zTvbR8mRUEegOHe6eCIEyo4V5jPn+YnALk= 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=V4rUAmBm9fdJ+8zvd7CAyZeOYHQKLa8+cOSJwRaA+WreQi20kRJQ3u9brZ0FyMFhV/ aQEdV6GDRM9JnOO+Dp4fodaIVyIhH6/vXSfnDjW44sCXlIWwZu1feKebVIeXZsuaJ7gk Dir1yJ/LLd3/Iixnk4eAp2hPIjsVmFHrDFEEs= Received: by 10.103.171.6 with SMTP id y6mr131796muo.110.1226629629844; Thu, 13 Nov 2008 18:27:09 -0800 (PST) Received: by 10.103.91.2 with HTTP; Thu, 13 Nov 2008 18:27:09 -0800 (PST) Message-ID: <5b28795b0811131827i7454cbdemec5c110f53c3c7c8@mail.gmail.com> Date: Thu, 13 Nov 2008 18:27:09 -0800 From: "Ameya Damle" To: ipsec@ietf.org MIME-Version: 1.0 Cc: Stefano Faccin , fanzhao@marvell.com Subject: [IPsec] Question regarding usage of "IDr" field in the IKEv2 signalling. 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="===============0148066066==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0148066066== Content-Type: multipart/alternative; boundary="----=_Part_149_30922857.1226629629809" ------=_Part_149_30922857.1226629629809 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello everyone, There's some discussion going on in 3GPP SA2 WG (for TS 23.402) regarding usage of IDr field in the IKEv2 signalling. The problem we are discussing there is that when the UE (the initiator of the IPsec SA) includes an identity of the PDN (APN) it wants to connect in the IDr field, then can the responder change the IDr field to include a different APN when it sends the IKE_AUTH response message? I tried to read through the RFC 4306 but somehow this point was not clear t= o me. The text in RFC 4306, section 1.2 (page 8) says that, "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 machin= e on which the responder is running is hosting multiple identities at the sam= e IP address. =85=85=85=85..... .......The responder asserts its identity with the IDr payload, optionally sends one or more certificates =85. " My understanding on reading the text above is that, when the initiator includes the IDr payload, the responder just asserts or maintains the same IDr in the response. Hence the IDr field cannot be changed. Is that the correct understanding ? Can you please clarify whether or not IDr field can be changed, when UE includes it during tunnel establishment ? Thanks, -- Ameya Damle Marvell Semiconductors, ------=_Part_149_30922857.1226629629809 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hello everyone,
 
There's some discussion going on in 3GPP SA2 WG (for TS 23.40= 2) regarding usage of IDr field in the IKEv2 signalling.
The problem we are discussing there is that when the UE (the initiator= of the IPsec SA) includes an identity of the PDN (APN)  it wants to c= onnect in the IDr field, then can the responder change the IDr field t= o include a different APN  when it sends the IKE_AUTH response message= ?
 
I tried to read through the RFC 4306 but somehow this point was not cl= ear to me.
 
The text in RFC 4306, section 1.2 (page 8) says that, 
 
 "The optional payload IDr enables the initiator to specify which= of the responder's identities it wants to talk to.  This is usefu= l when the machine on which the responder is running is hosting multip= le identities at the same IP address.  =85=85=85=85.....
 
.......The responder asserts its identity with the IDr payload, option= ally sends one or more certificates =85. "
 
My understanding on reading the text above is that, when the initiator= includes the IDr payload, the responder just asserts or maintains the same= IDr in the response. Hence the IDr field cannot be changed.
 
Is that the correct understanding ?
Can you please clarify whether or not IDr field can be changed, when U= E includes it during tunnel establishment ?
 
Thanks,
--
Ameya Damle
Marvell Semiconductors,
 
------=_Part_149_30922857.1226629629809-- --===============0148066066== 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 --===============0148066066==-- From ipsec-bounces@ietf.org Thu Nov 13 19:11:11 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 4000B3A690A; Thu, 13 Nov 2008 19:11:11 -0800 (PST) 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 725EA3A690A; Thu, 13 Nov 2008 19:11:10 -0800 (PST) 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 mK8ul34Hpsh8; Thu, 13 Nov 2008 19:11:09 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id EF1673A68FB; Thu, 13 Nov 2008 19:11:08 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e33.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id mAE3Afo3015258; Thu, 13 Nov 2008 20:10:41 -0700 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mAE3B8nG159758; Thu, 13 Nov 2008 20:11:08 -0700 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.13.1/8.13.3) with ESMTP id mAE3B7nr004530; Thu, 13 Nov 2008 20:11:07 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av06.boulder.ibm.com (8.13.1/8.12.11) with ESMTP id mAE3B7Bh004518; Thu, 13 Nov 2008 20:11:07 -0700 In-Reply-To: <5b28795b0811131827i7454cbdemec5c110f53c3c7c8@mail.gmail.com> References: <5b28795b0811131827i7454cbdemec5c110f53c3c7c8@mail.gmail.com> To: "Ameya Damle" MIME-Version: 1.0 X-KeepSent: FB026D70:51F1777B-85257501:00111E9B; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 11/13/2008 10:10:32 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 11/13/2008 10:10:32 PM, Serialize complete at 11/13/2008 10:10:32 PM, S/MIME Sign failed at 11/13/2008 10:10:32 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V85_10262008HFIGS1|October 26, 2008) at 11/13/2008 20:11:07, Serialize complete at 11/13/2008 20:11:07 Message-ID: Date: Thu, 13 Nov 2008 22:11:06 -0500 Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, Stefano Faccin , fanzhao@marvell.com Subject: Re: [IPsec] Question regarding usage of "IDr" field in the IKEv2 signalling. 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="===============1899117940==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============1899117940== Content-Type: multipart/alternative; boundary="=_alternative 001171AD85257501_=" This is a multipart message in MIME format. --=_alternative 001171AD85257501_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgQW1leWEsDQoNCklmIHlvdSByZWFkIHRoZSBjdXJyZW50IGRyYWZ0IG9mIElLRXYyIG1haW50 ZW5hbmNlICgNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaXBzZWNtZS1p a2V2MmJpcy0wMSkgeW91J2xsIGZpbmQgdGhlIA0KZm9sbG93aW5nIHRleHQgdG8gYW5zd2VyIHlv dXIgcXVlc3Rpb24uICBXaGlsZSB0aGlzIGlzIG5vdCB5ZXQgYW4gUkZDLCBpdCANCmRvZXMgcmVw cmVzZW50IHRoZSBnZW5lcmFsIG9waW5pb24gb2YgaG93IFJGQ3MgNDMwNiBhbmQgNDcxOCBzaG91 bGQgYmUgDQp1bmRlcnN0b29kOg0KDQogICBUaGUgb3B0aW9uYWwgcGF5bG9hZCBJRHIgZW5hYmxl cyB0aGUgaW5pdGlhdG9yIHRvIHNwZWNpZnkgd2hpY2ggb2YNCiAgIHRoZSByZXNwb25kZXIncyBp ZGVudGl0aWVzIGl0IHdhbnRzIHRvIHRhbGsgdG8uICBUaGlzIGlzIHVzZWZ1bCB3aGVuDQogICB0 aGUgbWFjaGluZSBvbiB3aGljaCB0aGUgcmVzcG9uZGVyIGlzIHJ1bm5pbmcgaXMgaG9zdGluZyBt dWx0aXBsZQ0KICAgaWRlbnRpdGllcyBhdCB0aGUgc2FtZSBJUCBhZGRyZXNzLiAgSWYgdGhlIElE ciBwcm9wb3NlZCBieSB0aGUNCiAgIGluaXRpYXRvciBpcyBub3QgYWNjZXB0YWJsZSB0byB0aGUg cmVzcG9uZGVyLCB0aGUgcmVzcG9uZGVyIG1pZ2h0IHVzZQ0KICAgc29tZSBvdGhlciBJRHIgdG8g ZmluaXNoIHRoZSBleGNoYW5nZS4gIElmIHRoZSBpbml0aWF0b3IgdGhlbiBkb2VzDQogICBub3Qg YWNjZXB0IHRoYXQgZmFjdCB0aGF0IHJlc3BvbmRlciB1c2VkIGRpZmZlcmVudCBJRHIgdGhhbiB0 aGUgb25lDQogICB0aGF0IHdhcyByZXF1ZXN0ZWQsIHRoZSBpbml0aWF0b3IgY2FuIGNsb3NlIHRo ZSBTQSBhZnRlciBub3RpY2luZyB0aGUNCiAgIGZhY3QuDQoNCg0KU2NvdHQgTW9vbmVuIChzbW9v bmVuQHVzLmlibS5jb20pDQp6L09TIENvbW11bmljYXRpb25zIFNlcnZlciBUQ1AvSVAgRGV2ZWxv cG1lbnQNCmh0dHA6Ly9zY290dC5hbmRzdHVmZi5vcmcvDQpodHRwOi8vd3d3LmxpbmtlZGluLmNv bS9pbi9zbW9vbmVuDQoNCg0KDQpGcm9tOg0KIkFtZXlhIERhbWxlIiA8YWRhbWxlMkBnbWFpbC5j b20+DQpUbzoNCmlwc2VjQGlldGYub3JnDQpDYzoNClN0ZWZhbm8gRmFjY2luIDxzbWZhY2NpbkBt YXJ2ZWxsLmNvbT4sIGZhbnpoYW9AbWFydmVsbC5jb20NCkRhdGU6DQoxMS8xMy8yMDA4IDA5OjI3 IFBNDQpTdWJqZWN0Og0KW0lQc2VjXSBRdWVzdGlvbiByZWdhcmRpbmcgdXNhZ2Ugb2YgIklEciIg ZmllbGQgaW4gdGhlIElLRXYyIHNpZ25hbGxpbmcuDQoNCg0KDQpIZWxsbyBldmVyeW9uZSwNCiAN ClRoZXJlJ3Mgc29tZSBkaXNjdXNzaW9uIGdvaW5nIG9uIGluIDNHUFAgU0EyIFdHIChmb3IgVFMg MjMuNDAyKSByZWdhcmRpbmcgDQp1c2FnZSBvZiBJRHIgZmllbGQgaW4gdGhlIElLRXYyIHNpZ25h bGxpbmcuDQpUaGUgcHJvYmxlbSB3ZSBhcmUgZGlzY3Vzc2luZyB0aGVyZSBpcyB0aGF0IHdoZW4g dGhlIFVFICh0aGUgaW5pdGlhdG9yIG9mIA0KdGhlIElQc2VjIFNBKSBpbmNsdWRlcyBhbiBpZGVu dGl0eSBvZiB0aGUgUEROIChBUE4pICBpdCB3YW50cyB0byBjb25uZWN0IA0KaW4gdGhlIElEciBm aWVsZCwgdGhlbiBjYW4gdGhlIHJlc3BvbmRlciBjaGFuZ2UgdGhlIElEciBmaWVsZCB0byBpbmNs dWRlIGEgDQpkaWZmZXJlbnQgQVBOICB3aGVuIGl0IHNlbmRzIHRoZSBJS0VfQVVUSCByZXNwb25z ZSBtZXNzYWdlPyANCiANCkkgdHJpZWQgdG8gcmVhZCB0aHJvdWdoIHRoZSBSRkMgNDMwNiBidXQg c29tZWhvdyB0aGlzIHBvaW50IHdhcyBub3QgY2xlYXIgDQp0byBtZS4gDQogDQpUaGUgdGV4dCBp biBSRkMgNDMwNiwgc2VjdGlvbiAxLjIgKHBhZ2UgOCkgc2F5cyB0aGF0LCANCiANCiAiVGhlIG9w dGlvbmFsIHBheWxvYWQgSURyIGVuYWJsZXMgdGhlIGluaXRpYXRvciB0byBzcGVjaWZ5IHdoaWNo IG9mIHRoZSANCnJlc3BvbmRlcidzIGlkZW50aXRpZXMgaXQgd2FudHMgdG8gdGFsayB0by4gIFRo aXMgaXMgdXNlZnVsIHdoZW4gdGhlIA0KbWFjaGluZSBvbiB3aGljaCB0aGUgcmVzcG9uZGVyIGlz IHJ1bm5pbmcgaXMgaG9zdGluZyBtdWx0aXBsZSBpZGVudGl0aWVzIA0KYXQgdGhlIHNhbWUgSVAg YWRkcmVzcy4gIOKApuKApuKApuKApi4uLi4uDQogDQouLi4uLi4uVGhlIHJlc3BvbmRlciBhc3Nl cnRzIGl0cyBpZGVudGl0eSB3aXRoIHRoZSBJRHIgcGF5bG9hZCwgb3B0aW9uYWxseSANCnNlbmRz IG9uZSBvciBtb3JlIGNlcnRpZmljYXRlcyDigKYuICINCiANCk15IHVuZGVyc3RhbmRpbmcgb24g cmVhZGluZyB0aGUgdGV4dCBhYm92ZSBpcyB0aGF0LCB3aGVuIHRoZSBpbml0aWF0b3IgDQppbmNs dWRlcyB0aGUgSURyIHBheWxvYWQsIHRoZSByZXNwb25kZXIganVzdCBhc3NlcnRzIG9yIG1haW50 YWlucyB0aGUgc2FtZSANCklEciBpbiB0aGUgcmVzcG9uc2UuIEhlbmNlIHRoZSBJRHIgZmllbGQg Y2Fubm90IGJlIGNoYW5nZWQuIA0KIA0KSXMgdGhhdCB0aGUgY29ycmVjdCB1bmRlcnN0YW5kaW5n ID8gDQpDYW4geW91IHBsZWFzZSBjbGFyaWZ5IHdoZXRoZXIgb3Igbm90IElEciBmaWVsZCBjYW4g YmUgY2hhbmdlZCwgd2hlbiBVRSANCmluY2x1ZGVzIGl0IGR1cmluZyB0dW5uZWwgZXN0YWJsaXNo bWVudCA/DQogDQpUaGFua3MsDQotLQ0KQW1leWEgRGFtbGUNCk1hcnZlbGwgU2VtaWNvbmR1Y3Rv cnMsDQogX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklQ c2VjIG1haWxpbmcgbGlzdA0KSVBzZWNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaXBzZWMNCg0KDQoNCg== --=_alternative 001171AD85257501_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEFtZXlhLDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SWYgeW91IHJlYWQgdGhlIGN1 cnJlbnQgZHJhZnQgb2YgSUtFdjINCm1haW50ZW5hbmNlICg8L2ZvbnQ+PGEgaHJlZj0iaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pcHNlY21lLWlrZXYyYmlzLTAxIj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1pcHNlY21lLWlrZXYyYmlzLTAxPC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+KQ0KeW91J2xsIGZpbmQgdGhlIGZvbGxvd2luZyB0ZXh0IHRvIGFuc3dlciB5 b3VyIHF1ZXN0aW9uLiAmbmJzcDtXaGlsZSB0aGlzDQppcyBub3QgeWV0IGFuIFJGQywgaXQgZG9l cyByZXByZXNlbnQgdGhlIGdlbmVyYWwgb3BpbmlvbiBvZiBob3cgUkZDcyA0MzA2DQphbmQgNDcx OCBzaG91bGQgYmUgdW5kZXJzdG9vZDo8L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mz4mbmJzcDsgJm5ic3A7VGhlIG9wdGlvbmFsIHBheWxvYWQgSURyIGVuYWJsZXMgdGhlDQppbml0 aWF0b3IgdG8gc3BlY2lmeSB3aGljaCBvZjxicj4NCiAmbmJzcDsgdGhlIHJlc3BvbmRlcidzIGlk ZW50aXRpZXMgaXQgd2FudHMgdG8gdGFsayB0by4gJm5ic3A7VGhpcyBpcyB1c2VmdWwNCndoZW48 YnI+DQogJm5ic3A7IHRoZSBtYWNoaW5lIG9uIHdoaWNoIHRoZSByZXNwb25kZXIgaXMgcnVubmlu ZyBpcyBob3N0aW5nIG11bHRpcGxlPGJyPg0KICZuYnNwOyBpZGVudGl0aWVzIGF0IHRoZSBzYW1l IElQIGFkZHJlc3MuICZuYnNwO0lmIHRoZSBJRHIgcHJvcG9zZWQgYnkNCnRoZTxicj4NCiAmbmJz cDsgaW5pdGlhdG9yIGlzIG5vdCBhY2NlcHRhYmxlIHRvIHRoZSByZXNwb25kZXIsIDx1PnRoZSBy ZXNwb25kZXINCm1pZ2h0IHVzZTxicj4NCjwvdT4gJm5ic3A7IDx1PnNvbWUgb3RoZXIgSURyIHRv IGZpbmlzaCB0aGUgZXhjaGFuZ2U8L3U+LiAmbmJzcDtJZiB0aGUNCmluaXRpYXRvciB0aGVuIGRv ZXM8YnI+DQogJm5ic3A7IG5vdCBhY2NlcHQgdGhhdCBmYWN0IHRoYXQgcmVzcG9uZGVyIHVzZWQg ZGlmZmVyZW50IElEciB0aGFuIHRoZQ0Kb25lPGJyPg0KICZuYnNwOyB0aGF0IHdhcyByZXF1ZXN0 ZWQsIHRoZSBpbml0aWF0b3IgY2FuIGNsb3NlIHRoZSBTQSBhZnRlciBub3RpY2luZw0KdGhlPGJy Pg0KICZuYnNwOyBmYWN0Ljxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj48YnI+DQpTY290dCBNb29uZW4gKHNtb29uZW5AdXMuaWJtLmNvbSk8YnI+ DQp6L09TIENvbW11bmljYXRpb25zIFNlcnZlciBUQ1AvSVAgRGV2ZWxvcG1lbnQ8YnI+DQo8L2Zv bnQ+PGEgaHJlZj1odHRwOi8vc2NvdHQuYW5kc3R1ZmYub3JnLz48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+aHR0cDovL3Njb3R0LmFuZHN0dWZmLm9yZy88L2ZvbnQ+PC9hPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGEgaHJlZj1odHRwOi8vd3d3Lmxp bmtlZGluLmNvbS9pbi9zbW9vbmVuPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5odHRw Oi8vd3d3LmxpbmtlZGluLmNvbS9pbi9zbW9vbmVuPC9mb250PjwvYT4NCjxicj4NCjxicj4NCjxi cj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+PGZvbnQgc2l6ZT0x IGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+RnJvbTo8L2ZvbnQ+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O0FtZXlhIERhbWxlJnF1b3Q7ICZsdDthZGFt bGUyQGdtYWlsLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD48Zm9udCBzaXpl PTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5Ubzo8L2ZvbnQ+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmlwc2VjQGlldGYub3JnPC9mb250Pg0KPHRyPg0KPHRk IHZhbGlnbj10b3A+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+ Q2M6PC9mb250Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5TdGVmYW5vIEZh Y2NpbiAmbHQ7c21mYWNjaW5AbWFydmVsbC5jb20mZ3Q7LA0KZmFuemhhb0BtYXJ2ZWxsLmNvbTwv Zm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZh Y2U9InNhbnMtc2VyaWYiPkRhdGU6PC9mb250Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj4xMS8xMy8yMDA4IDA5OjI3IFBNPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+U3ViamVjdDo8L2Zv bnQ+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPltJUHNlY10gUXVlc3Rpb24g cmVnYXJkaW5nIHVzYWdlIG9mDQomcXVvdDtJRHImcXVvdDsgZmllbGQgaW4gdGhlIElLRXYyICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NpZ25hbGxpbmcuPC9mb250PjwvdGFibGU+DQo8YnI+ DQo8aHIgbm9zaGFkZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+SGVsbG8gZXZlcnlv bmUsPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0zPlRoZXJlJ3Mgc29tZSBkaXNjdXNzaW9uIGdvaW5nIG9uIGluIDNHUFAgU0EyIFdHIChmb3Ig VFMNCjIzLjQwMikgcmVnYXJkaW5nIHVzYWdlIG9mIElEciBmaWVsZCBpbiB0aGUgSUtFdjIgc2ln bmFsbGluZy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPlRoZSBwcm9ibGVtIHdlIGFyZSBkaXNj dXNzaW5nIHRoZXJlIGlzIHRoYXQgd2hlbiB0aGUgVUUNCih0aGUgaW5pdGlhdG9yIG9mIHRoZSBJ UHNlYyBTQSkgaW5jbHVkZXMgYW4gaWRlbnRpdHkgb2YgdGhlIFBETiAoQVBOKSAmbmJzcDtpdA0K d2FudHMgdG8gY29ubmVjdCBpbiB0aGUgSURyIGZpZWxkLCB0aGVuIGNhbiB0aGUgcmVzcG9uZGVy IGNoYW5nZSB0aGUgSURyDQpmaWVsZCB0byBpbmNsdWRlIGEgZGlmZmVyZW50IEFQTiAmbmJzcDt3 aGVuIGl0IHNlbmRzIHRoZSBJS0VfQVVUSCByZXNwb25zZQ0KbWVzc2FnZT8gPC9mb250Pg0KPGJy Pjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPkkgdHJpZWQgdG8g cmVhZCB0aHJvdWdoIHRoZSBSRkMgNDMwNiBidXQgc29tZWhvdyB0aGlzDQpwb2ludCB3YXMgbm90 IGNsZWFyIHRvIG1lLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTM+VGhlIHRleHQgaW4gUkZDIDQzMDYsIHNlY3Rpb24gMS4yIChwYWdlIDgp IHNheXMgdGhhdCwNCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0KPGJy Pjxmb250IHNpemU9Mz4mbmJzcDsmcXVvdDtUaGUgb3B0aW9uYWwgcGF5bG9hZCBJRHIgZW5hYmxl cyB0aGUgaW5pdGlhdG9yDQp0byBzcGVjaWZ5IHdoaWNoIG9mIHRoZSByZXNwb25kZXIncyBpZGVu dGl0aWVzIGl0IHdhbnRzIHRvIHRhbGsgdG8uICZuYnNwO1RoaXMNCmlzIHVzZWZ1bCB3aGVuIHRo ZSBtYWNoaW5lIG9uIHdoaWNoIHRoZSByZXNwb25kZXIgaXMgcnVubmluZyBpcyBob3N0aW5nDQpt dWx0aXBsZSBpZGVudGl0aWVzIGF0IHRoZSBzYW1lIElQIGFkZHJlc3MuICZuYnNwO+KApuKApuKA puKApi4uLi4uPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zPi4uLi4uLi5UaGUgcmVzcG9uZGVyIGFzc2VydHMgaXRzIGlkZW50aXR5IHdpdGgg dGhlIElEcg0KcGF5bG9hZCwgb3B0aW9uYWxseSBzZW5kcyBvbmUgb3IgbW9yZSBjZXJ0aWZpY2F0 ZXMg4oCmLiAmcXVvdDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTM+TXkgdW5kZXJzdGFuZGluZyBvbiByZWFkaW5nIHRoZSB0ZXh0IGFib3Zl IGlzIHRoYXQsIHdoZW4NCnRoZSBpbml0aWF0b3IgaW5jbHVkZXMgdGhlIElEciBwYXlsb2FkLCB0 aGUgcmVzcG9uZGVyIGp1c3QgYXNzZXJ0cyBvciBtYWludGFpbnMNCnRoZSBzYW1lIElEciBpbiB0 aGUgcmVzcG9uc2UuIEhlbmNlIHRoZSBJRHIgZmllbGQgY2Fubm90IGJlIGNoYW5nZWQuIDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5JcyB0 aGF0IHRoZSBjb3JyZWN0IHVuZGVyc3RhbmRpbmcgPyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z PkNhbiB5b3UgcGxlYXNlIGNsYXJpZnkgd2hldGhlciBvciBub3QgSURyIGZpZWxkIGNhbiBiZQ0K Y2hhbmdlZCwgd2hlbiBVRSBpbmNsdWRlcyBpdCBkdXJpbmcgdHVubmVsIGVzdGFibGlzaG1lbnQg PzwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9 Mz5UaGFua3MsPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4tLTwvZm9udD4NCjxicj48Zm9udCBz aXplPTM+QW1leWEgRGFtbGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPk1hcnZlbGwgU2VtaWNv bmR1Y3RvcnMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+PHR0Pjxmb250 IHNpemU9Mj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCklQc2VjIG1haWxpbmcgbGlzdDxicj4NCklQc2VjQGlldGYub3JnPGJyPg0KPC9mb250Pjwv dHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjPjx0 dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNl YzwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjwvZm9udD48L3R0Pg0KPGJy Pg0KPGJyPg0K --=_alternative 001171AD85257501_=-- --===============1899117940== 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 --===============1899117940==-- From ipsec-bounces@ietf.org Mon Nov 17 00:32: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 8699A3A69FB; Mon, 17 Nov 2008 00:32:59 -0800 (PST) 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 46A8B3A698A; Mon, 17 Nov 2008 00:32:58 -0800 (PST) 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 0BiSduYjrQE8; Mon, 17 Nov 2008 00:32:57 -0800 (PST) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 4388A3A696C; Mon, 17 Nov 2008 00:32:57 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1L1zXG-0006cY-98; Mon, 17 Nov 2008 09:32:42 +0100 X-Hashcash: 1:20:081117:mext@ietf.org::uS+ElyPx6d1zShNw:00002aX9 X-Hashcash: 1:20:081117:mobopts@irtf.org::rBHPMCBm0o28YDvh:00gRY X-Hashcash: 1:20:081117:ipsec@ietf.org::rW2BcA47NML8k/be:000EcwZ From: arno@natisbad.org (Arnaud Ebalard) To: IETF MEXT WG ML X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 Date: Mon, 17 Nov 2008 00:30:57 -0800 Message-ID: <87d4guwy7y.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: IPsec IETF WG ML , Mobopts IRTF WG ML Subject: [IPsec] MIPv6 IPsec Route Optimization (IRO) 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, Sorry for crossposting but the topic discussed in the draft may be of interest for people of the 3 lists. > IETF I-D Submission Tool writes: > > A new version of I-D, draft-ebalard-mext-ipsec-ro-00.txt has been > successfuly submitted by Arnaud Ebalard and posted to the IETF > repository. > > Filename: draft-ebalard-mext-ipsec-ro > Revision: 00 > Title: Mobile IPv6 IPsec Route Optimization (IRO) > Creation_date: 2008-11-17 > WG ID: Independent Submission > Number_of_pages: 44 > > Abstract: > > This memo specifies an improved alternate route optimization procedure > for Mobile IPv6 designed specifically for environments where IPsec is > used between peers (most probably with IKE). The replacement of the > complex Return Routability procedure for a simple mechanism and the > removal of HAO and RH2 extensions from exchanged packets result in > performance and security improvements. I have just submitted a new I-D [1] which certainly requires an introduction (and disclaimer): it specifies a MIPv6 Route Optimization procedure *dedicated* to environments where IPsec/IKE is used between peers (MN-HA, MN-CN, MN-MN) for protecting both signaling and data traffic. Some of the improvements provided by this "IPsec Route Optimization" mechanism (IRO) are also proposed for the IPsec communications between the MN and its HA. Among the features provided by IRO (introduction of the document as a more accurate list): * Complete removal of RH2 and HAO (resulting in simplified packet handling on both sides and possibly better compatibility with filtering implemented in the network), * Per packet MTU gains between 24 and 48 bytes in comparison with equivalent uses of IPsec in standard RO context, * Improved and more generic proof of address ownership mechanism, * Safe by default behavior avoiding direct unprotected traffic flows, * No additionnal changes to IPsec or IKE protocols and limited changes to MIPv6 via four simple messages and a single option. Next steps is to gather some initial feedback from interested people of the WG. Then, I intend to spend some time implementing it (under Linux) to challenge the ideas provided in the draft. Comments are welcome. Note that this is a -00 which implies that some parts are still quite raw and might deserve additional comments/work. Cheers, a+ [1]: http://www.ietf.org/internet-drafts/draft-ebalard-mext-ipsec-ro-00.txt _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 17 07:45:03 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 E358D3A69D4; Mon, 17 Nov 2008 07:45:03 -0800 (PST) X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id ED3E03A69D4; Mon, 17 Nov 2008 07:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081117154501.ED3E03A69D4@core3.amsl.com> Date: Mon, 17 Nov 2008 07:45:01 -0800 (PST) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-resumption-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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : IKEv2 Session Resumption Author(s) : Y. Sheffer, et al. Filename : draft-ietf-ipsecme-ikev2-resumption-00.txt Pages : 21 Date : 2008-11-17 The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round-trips required and the cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol (EAP) is used for authentication, which adds several more round trips and consequently latency. To re-establish security associations (SA) upon a failure recovery condition is time consuming, especially when an IPsec peer, such as a VPN gateway, needs to re-establish a large number of SAs with various end points. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment. In order to avoid the need to re-run the key exchange protocol from scratch it would be useful to provide an efficient way to resume an IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA. A client can reconnect to a gateway from which it was disconnected. The proposed approach uses a IKEv2 state (or a reference into a state store). to store state information that is later made available to the IKEv2 responder for re-authentication. Restoring state information by utilizing a ticket is one possible way. This document does not specify the format of the ticket but recommendations are provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption-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. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2-resumption-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-17073500.I-D@ietf.org> --NextPart 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 --NextPart-- From ipsec-bounces@ietf.org Mon Nov 17 08:41: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 DB6E828C161; Mon, 17 Nov 2008 08:41:30 -0800 (PST) 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 0EF1328C161 for ; Mon, 17 Nov 2008 08:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, 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 AB4ocrZmRxqv for ; Mon, 17 Nov 2008 08:41:28 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 6994D28C14C for ; Mon, 17 Nov 2008 08:41:28 -0800 (PST) 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 mAHGelLL020787; Mon, 17 Nov 2008 10:41:25 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 18:40:47 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 18:40:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Nov 2008 18:40:44 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB72024BB14C@vaebe104.NOE.Nokia.com> In-Reply-To: <1d38a3350811070811o6010bfdaw6e5ac061bce4d0d4@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Moving forwards on session resumption Thread-Index: AclA87bcPaa8Z/UcSp+ClLvX/aU1TAH30Zzg References: <1d38a3350811070811o6010bfdaw6e5ac061bce4d0d4@mail.gmail.com> From: To: , X-OriginalArrivalTime: 17 Nov 2008 16:40:45.0269 (UTC) FILETIME=[3CD57050:01C948D3] X-Nokia-AV: Clean Cc: tim.polk@nist.gov Subject: Re: [IPsec] Moving forwards on session resumption 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="===============2085448565==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============2085448565== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C948D3.3CD95562" This is a multi-part message in MIME format. ------_=_NextPart_001_01C948D3.3CD95562 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have received an appeal from Hui Deng and Peny Yang. Upon = consideration, we have decided not to take any further action. We hope = Hui and Peny are satisifed with our explanation, which we provided = off-list. =20 We're encouraged by the frank and open exchange of ideas -- which is = critical for making good progress on the chartered work items -- and = hope to see lively discussion in the future as well. =20 Best regards, Pasi & Tim ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of ext Hui Deng Sent: 07 November, 2008 18:12 To: Paul Hoffman Cc: IPsecme WG Subject: Re: [IPsec] Moving forwards on session resumption =09 =09 Dear Chairs and all =20 As the co-author of the draft-xu, I would like to question this = decision. =20 1) I carefully read the reason of this decision below, found no any = technical or concensus summary other than chairs own chosen. =20 2) Chair here say that authors of the draft-xu is not seeking for the = concensus, I can show offline disucssion email if needed, authors of the draft-xu = express clearly several times that they are expecting the concensus. =20 3) Regarding to the restrictions in the charter, I feel confused why = chair call the discussion.=20 http://www.ietf.org/mail-archive/web/ipsec/current/msg03232.html, it = seems useless,no any technical summary for this discussion. For the wasting of time, I didn't see any deployment urgency for that = technology, on the contrary, draft-xu is interested in by a scale = operator. I guess that IETF always choose the more concensused and = better solution. =20 4) authors of draft-xu would like to appeal this decision to the end, = please wg chair and IESG chair sincerely consider this decision. we need = sometime to prepare the appeal to IESG chair. =20 5) One remindness, please draft-tschofenig refer to other draft if it = is using idea from it. =20 Many thanks =20 -Hui =20 2008/11/7 Paul Hoffman =09 =09 Greetings again. As you know, we have an item in our charter to have = an extension to handle session resumption. The charter says: =09 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - 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 negotiation 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. =09 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 gateway 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. =09 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. =09 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. = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =09 There were two proposals for this work, = draft-tschofenig-ipsecme-ikev2-resumption and draft-xu-ike-sa-sync. The = have both gone through revisions and been discussed on the mailing list. =09 The charter is quite clear that the Working Group is supposed to = produce one extension, not two. Because of that, I have had to pick the = one that would be best for the Working Group to work on. Based on the = discussion on the list and a careful reading of the latest version of = the two drafts, and comparing the two drafts to the charter requirement = above, I have chosen draft-tschofenig-ipsecme-ikev2-resumption as the = starting point for the Working Group. (My co-chair recused himself from = the decision because he is co-author on one of the candidate documents.) =09 In discussing this decision offline with the co-authors of = draft-xu-ike-sa-sync, they have expressed a desire to have the Working = Group decide between the two documents. I explained that it is, in fact, = the job of the chair to pick documents and authors; the Working Group's = task is to make the work items be as good as possible. I based my = decision on the completeness of the two proposed solutions and how well = each proposal matched the charter. In the end, the two proposed = solutions would be technically quite similar when draft-xu-ike-sa-sync = was more complete and removed the extraneous material. =09 Further, the co-authors of draft-xu-ike-sa-sync have repeatedly said = that they do not like the restrictions in the charter; my response to = them is the same as it is to the WG, namely that re-opening the charter = discussion at this point is waste of time and is not an option. =09 Given that, I request that the co-authors of = draft-tschofenig-ipsecme-ikev2-resumption prepare to submit = draft-ietf-ipsecme-ikev2-resumption-00 on Monday, Nov. 17. It should = match draft-tschofenig-ipsecme-ikev2-resumption-01 exactly, other than = the draft name change. The WG can start discussion the current = draft-tschofenig-ipsecme-ikev2-resumption draft immediately. =09 --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =09 ------_=_NextPart_001_01C948D3.3CD95562 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
We have received=20 an appeal from Hui Deng and Peny Yang.  Upon=20 consideration, we have decided not to take any further = action. We hope Hui and Peny are satisifed = with our=20 explanation, which we provided=20 off-list.
 
We're encouraged=20 by the frank and open exchange of ideas -- which=20 is critical for making good progress on the chartered work items = -- and hope to see lively discussion in = the future=20 as well.
 
Best=20 regards,
Pasi & Tim

From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of ext Hui=20 Deng
Sent: 07 November, 2008 18:12
To: Paul=20 Hoffman
Cc: IPsecme WG
Subject: Re: [IPsec] Moving = forwards on session resumption

Dear Chairs and all
 
As the co-author of the draft-xu, I would like to question this=20 decision.
 
1) I carefully read the reason of this decision below, found no = any=20 technical or concensus summary other than chairs own chosen.
 
2) Chair here say that authors of the draft-xu is not seeking for = the=20 concensus,
I can show offline disucssion email if needed, authors of = the=20 draft-xu express clearly several times that they are expecting = the=20 concensus.
 
3) Regarding to the restrictions in the charter, I feel confused = why=20 chair call the discussion. 
http://www.ietf.org/mail-archive/web/ipsec/current/msg03232.html,=20 it seems useless,no any technical summary for this = discussion.
For the=20 wasting of time, I didn't see any deployment urgency for that = technology, on=20 the contrary, draft-xu is interested in by a scale operator. I guess=20 that IETF always choose the more concensused and better=20 solution.
 
4) authors of draft-xu would like to appeal this decision to the = end,=20 please wg chair and IESG chair sincerely consider this decision. we = need=20 sometime to prepare the appeal to IESG chair.
 
5) One remindness, please draft-tschofenig refer to other draft = if it is=20 using idea from it.
 
Many thanks
 
-Hui
 
2008/11/7 Paul Hoffman <paul.hoffman@vpnc.org>
<co-chair=20 hat on>

Greetings again. As you know, we have an item in = our=20 charter to have an extension to handle session resumption. The = charter=20 = says:

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

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

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

To=20 the degree its content falls within the scope of this work item, = text
and=20 ideas from draft-sheffer-ipsec-failover will be used as a=20 = starting
point.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
There=20 were two proposals for this work, = draft-tschofenig-ipsecme-ikev2-resumption=20 and draft-xu-ike-sa-sync. The have both gone through revisions and = been=20 discussed on the mailing list.

The charter is quite clear = that the=20 Working Group is supposed to produce one extension, not two. Because = of=20 that, I have had to pick the one that would be best for the Working = Group to=20 work on. Based on the discussion on the list and a careful reading = of the=20 latest version of the two drafts, and comparing the two drafts to = the=20 charter requirement above, I have chosen=20 draft-tschofenig-ipsecme-ikev2-resumption as the starting point for = the=20 Working Group. (My co-chair recused himself from the decision = because he is=20 co-author on one of the candidate documents.)

In discussing = this=20 decision offline with the co-authors of draft-xu-ike-sa-sync, they = have=20 expressed a desire to have the Working Group decide between the two=20 documents. I explained that it is, in fact, the job of the chair to = pick=20 documents and authors; the Working Group's task is to make the work = items be=20 as good as possible. I based my decision on the completeness of the = two=20 proposed solutions and how well each proposal matched the charter. = In the=20 end, the two proposed solutions would be technically quite similar = when=20 draft-xu-ike-sa-sync was more complete and removed the extraneous=20 material.

Further, the co-authors of draft-xu-ike-sa-sync = have=20 repeatedly said that they do not like the restrictions in the = charter; my=20 response to them is the same as it is to the WG, namely that = re-opening the=20 charter discussion at this point is waste of time and is not an=20 option.

Given that, I request that the co-authors of=20 draft-tschofenig-ipsecme-ikev2-resumption prepare to submit=20 draft-ietf-ipsecme-ikev2-resumption-00 on Monday, Nov. 17. It should = match=20 draft-tschofenig-ipsecme-ikev2-resumption-01 exactly, other than the = draft=20 name change. The WG can start discussion the current=20 draft-tschofenig-ipsecme-ikev2-resumption draft = immediately.

--Paul Hoffman, Director
--VPN=20 = Consortium
_______________________________________________
IPsec=20 mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

------_=_NextPart_001_01C948D3.3CD95562-- --===============2085448565== 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 --===============2085448565==-- From ipsec-bounces@ietf.org Mon Nov 17 10:19:25 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 D997A3A692D; Mon, 17 Nov 2008 10:19:25 -0800 (PST) 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 5F8263A692D for ; Mon, 17 Nov 2008 10:19:24 -0800 (PST) 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 FM7hBuH3Z1Lq for ; Mon, 17 Nov 2008 10:19:20 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id 121D23A6835 for ; Mon, 17 Nov 2008 10:19:20 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so2519142rvf.49 for ; Mon, 17 Nov 2008 10:19:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:x-mailer:date:to:from:subject :in-reply-to:references:mime-version:content-type:message-id; bh=eHwejP+J2/BpH2b+TUUmYiOGKoSqqIpjbf+ikBKlGPw=; b=b80/OgS80Tb7boSejP+6x7CWO8EV9wn/rpTrJ+Oz7RDxvkB5DBTgoTsCklRtz/fBhR 5TzLndNDuwhFTSIXSV3p2IpEOxg7zhsNVh5ADAjCNkV74q6HSnNrtzrX4iKRmY1LoAl9 NgCnsmCsB0tKaBOGiMpfqshV0hXVbKu8iIRgg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-mailer:date:to:from:subject:in-reply-to:references:mime-version :content-type:message-id; b=lPoFUJZC8Lw94wsskE1Q0p4q9kK+XIkXBwX/mcb3J1LbcvT1bnYqoNIZMYKEUH6KSt h7EiIEHOM5gpE2Z4Y3Z16KRtALKCWzOLYG4Zmo3oJtTvXHo8xQSfx5/A/GATb2PwE47s vTpF3pgtcF41xf/4FugkoiSCrX1tYWO5h/5kM= Received: by 10.141.29.18 with SMTP id g18mr2399392rvj.89.1226945959398; Mon, 17 Nov 2008 10:19:19 -0800 (PST) Received: from Gregory-T60.gmail.com (70.sub-70-219-46.myvzw.com [70.219.46.70]) by mx.google.com with ESMTPS id l31sm10380735rvb.2.2008.11.17.10.19.16 (version=SSLv3 cipher=RC4-MD5); Mon, 17 Nov 2008 10:19:17 -0800 (PST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 17 Nov 2008 10:19:11 -0800 To: Paul Hoffman ,IPsecme WG From: "Gregory M. Lebovitz" In-Reply-To: References: Mime-Version: 1.0 Message-ID: <4921b5a5.1f588c0a.477a.ffffb344@mx.google.com> Subject: Re: [IPsec] Additions/changes to the agenda? 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 Paul, Since IKEv2bis-01 is 133 pages, would it make sense to enumerate in one email for the list the "~5 big open topics" (or at least point to their issue tracker numbers) so the community can review at least those? You know, create low hanging fruit? We might get better discussion on them that way. Gregory. At 05:09 PM 11/11/2008, Paul Hoffman wrote: >Greetings again. We are less than a week away from the WG meeting, >and Yaron and I want to be sure that anyone who has agenda items >() have >told us. Send me mail off-list if you have any additions or changes. > >--Paul Hoffman, Director >--VPN Consortium >_______________________________________________ >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 Nov 17 10:49: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 2DD763A68AC; Mon, 17 Nov 2008 10:49:21 -0800 (PST) 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 C45123A68AC for ; Mon, 17 Nov 2008 10:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.251, 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 LGWhSUFfpD1x for ; Mon, 17 Nov 2008 10:49:18 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id C84093A67A6 for ; Mon, 17 Nov 2008 10:49:17 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 59D6B29C001; Mon, 17 Nov 2008 20:49:16 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 1257B294003; Mon, 17 Nov 2008 20:49:15 +0200 (IST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mAHInEQC008868; Mon, 17 Nov 2008 20:49:14 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Mon, 17 Nov 2008 20:49:14 +0200 From: Yaron Sheffer To: "Gregory M. Lebovitz" , Paul Hoffman , IPsecme WG Date: Mon, 17 Nov 2008 20:49:10 +0200 Thread-Topic: [IPsec] Additions/changes to the agenda? Thread-Index: AclI4QsYTWZ43KHKRsC1X7xpxz+QcAAA8meQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A7812127@il-ex01.ad.checkpoint.com> References: <4921b5a5.1f588c0a.477a.ffffb344@mx.google.com> In-Reply-To: <4921b5a5.1f588c0a.477a.ffffb344@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [IPsec] Additions/changes to the agenda? 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="===============0783474366==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0783474366== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_018D_01C948B2.E2BA79A0" ------=_NextPart_000_018D_01C948B2.E2BA79A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_018E_01C948B2.E2BA79A0" ------=_NextPart_001_018E_01C948B2.E2BA79A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Gregory, We have posted the slides on the usual place . The v2-bis slides have a large number of open issues on them, in *very rough* priority order. So if you can only look at 5, go ahead and read the first five. Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Gregory M. Lebovitz Sent: Monday, November 17, 2008 12:19 To: Paul Hoffman; IPsecme WG Subject: Re: [IPsec] Additions/changes to the agenda? Paul, Since IKEv2bis-01 is 133 pages, would it make sense to enumerate in one email for the list the "~5 big open topics" (or at least point to their issue tracker numbers) so the community can review at least those? You know, create low hanging fruit? We might get better discussion on them that way. Gregory. At 05:09 PM 11/11/2008, Paul Hoffman wrote: >Greetings again. We are less than a week away from the WG meeting, >and Yaron and I want to be sure that anyone who has agenda items >() have >told us. Send me mail off-list if you have any additions or changes. > >--Paul Hoffman, Director >--VPN Consortium >_______________________________________________ >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. ------=_NextPart_001_018E_01C948B2.E2BA79A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Gregory,

 

We have posted the slides on the usual place. The = v2-bis slides have a large number of open issues on them, in *very rough* = priority order. So if you can only look at 5, go ahead and read the first = five.

 

Thanks,

      = Yaron

 

-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of Gregory M. Lebovitz
Sent: Monday, November 17, 2008 12:19
To: Paul Hoffman; IPsecme WG
Subject: Re: [IPsec] Additions/changes to the agenda?

 

Paul,

Since IKEv2bis-01 is 133 pages, would it make sense to enumerate = in

one email for the list the "~5 big open topics" (or at = least point to

their issue tracker numbers) so the community can review at = least

those? You know, create low hanging fruit? We might get = better

discussion on them that way.

 

Gregory.

 

At 05:09 PM 11/11/2008, Paul Hoffman = wrote:

>Greetings again. We are less than a week away from the WG = meeting,

>and Yaron and I want to be sure that anyone who has agenda = items

>(<http://www.ietf.org/proceedings/08nov/agenda/ipsecme.txt= >) have

>told us. Send me mail off-list if you have any additions or changes.

> 

>--Paul Hoffman, Director

>--VPN Consortium

>_______________________________________________

>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.

------=_NextPart_001_018E_01C948B2.E2BA79A0-- ------=_NextPart_000_018D_01C948B2.E2BA79A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTExNzE4NDkxMFowIwYJKoZIhvcNAQkEMRYEFHWWmhNnKWzF F80xkCglHKvhG7DtMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA AAbYjYGS5m1JlgVgelHUt5MsgxSNq0AUx95DJMnWVSQKRGfJeV9xsmthJTEqL8LdZHKbpyVFblY3 zRJgiXG5X2GsAFOWYEaYk2apqxvEMWs4/z53c2TRuqr9Jugz+UMGAXBJixPbFIM3YKmYN1LGrfMR ejYy9yDVnzeIpMAqxxXyzLqzrDWCDWAVqeJseWsN/4z//nNZjNYY2Z2EcPzCWGkmNvLF2mdzDtP4 MmGm0hol4I6ly7Vl3r6hgs35V4tfB98VsOemwkYElpjJrTi1SKV+5Npqs7RGyTaMkPGhDVpZ9cSe Gi1Amo4hCxOebDaFOB60v2WOMU3WWoQmEeT8mgAAAAAAAA== ------=_NextPart_000_018D_01C948B2.E2BA79A0-- --===============0783474366== 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 --===============0783474366==-- From ipsec-bounces@ietf.org Mon Nov 17 14:19:19 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 302163A6A75; Mon, 17 Nov 2008 14:19:19 -0800 (PST) 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 D16113A6A75 for ; Mon, 17 Nov 2008 14:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 w2WUPa+YM5eH for ; Mon, 17 Nov 2008 14:19:18 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id BFA063A6907 for ; Mon, 17 Nov 2008 14:19:17 -0800 (PST) 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 mAHMJEhf005426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 00:19:14 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mAHMJDuK025276; Tue, 18 Nov 2008 00:19:13 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18721.60897.415739.640988@fireball.kivinen.iki.fi> Date: Tue, 18 Nov 2008 00:19:13 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 16 min X-Total-Time: 22 min Subject: [IPsec] draft-ietf-ipsecme-ikev2-resumption-00.txt lifetimes 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 What is the reason for sending the lifetime of the ticket along with ticket? We have mostly tried to get rid of lifetimes visible on protocol level on the IKEv2 and made all those local policy matters, so why do we need externally visible lifetime for the ticket? What purpose does it serve? Why does the client need to know the ticket lifetime? It would be much simplier if this was left as local matter, i.e. client would always use the latest ticket is has, and every time if he has ticket (i.e. the last IKE SA was NOT deleted, but was interrupted), it would send that to the server (i.e. use the IKE_SESSION_RESUME). If ticket is no longer valid in the server, server will reply with N(TICKET_NACK) and client will restart with full exchange. In most of the cases the resumption happens quite quickly after the connection was interrupted, so most likely the ticket is still valid. Then for the server side when the ticket is about expire, it would simply push new ticket to the client using informational message (this is set as one of the requirements "o Allowing a gateway to push state to clients.", but I do not see the actual description how to do it in document). This way server could use also non-time based policies for the ticket lifetimes, i.e. it could for example decide to change the ticket encryption key every now and then, and then slowly generate new tickets for those sessions using old key, and when all sessions have been sent new ticket, it can forget the old ticket encryption key. Also what is the meaning of the lifetime field of the N(TICKET_OPAQUE) in IKE_SESSION_RESUME? Does it need to be copied from the original notification or what? -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 17 14:24: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 DA14C28C16A; Mon, 17 Nov 2008 14:24:15 -0800 (PST) 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 43EC228C16A for ; Mon, 17 Nov 2008 14:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 HchL+qhV74yI for ; Mon, 17 Nov 2008 14:24:13 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 2135728C164 for ; Mon, 17 Nov 2008 14:24:12 -0800 (PST) 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 mAHMOBwP014747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 00:24:11 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mAHMOBtn013068; Tue, 18 Nov 2008 00:24:11 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18721.61195.155616.874575@fireball.kivinen.iki.fi> Date: Tue, 18 Nov 2008 00:24:11 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 4 min Subject: [IPsec] draft-ietf-ipsecme-ikev2-resumption-00.txt SPI values 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 The draft says that ticket has SPI values, but those are not used, so I am bit confused what SPI values is used in which places. 1) When the client does IKE_SESSION_RESUME what SPI values he uses in the HDR? New SPIi, and SPIr=0? Or old SPIi and SPIr? 2) From the test it seems that when creating new keying material the new SPIi and SPIr are used, so I assume the IKE_SESSION_RESUME request needs to use SPIi = new, and SPIr = 0, and then IKE_SESSION_RESUME reply will use same SPIi, and allocate new SPIr and those are used when creating the keying material? 3) Why are the SPIi and SPIr needed on the ticket at all? -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 17 14:47: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 064AF28C173; Mon, 17 Nov 2008 14:47:45 -0800 (PST) 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 9B61028C172; Mon, 17 Nov 2008 14:47:43 -0800 (PST) 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 SJI4rkdTvP01; Mon, 17 Nov 2008 14:47:42 -0800 (PST) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 80B713A6922; Mon, 17 Nov 2008 14:47:42 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1L2Csc-0003LC-9N; Mon, 17 Nov 2008 23:47:38 +0100 X-Hashcash: 1:20:081117:ipsec@ietf.org::5nr40BJfxY5+aE/9:0000k6B From: arno@natisbad.org (Arnaud Ebalard) To: "Haddad\, Wassim Michel" 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:081117:mext@ietf.org::vI8uGZGwHWmdiCo8:00000+50 X-Hashcash: 1:20:081117:mobopts@irtf.org::6F9PKFB227oVUlps:030T6 X-Hashcash: 1:20:081117:whaddad@qualcomm.com::1904AmG5DqwOftse:000000000000000000000000000000000000000005ymi Date: Mon, 17 Nov 2008 14:45:54 -0800 In-Reply-To: (Wassim Michel Haddad's message of "Mon, 17 Nov 2008 12:57:23 -0800") Message-ID: <87r65adl99.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: IPsec IETF WG ML , Mobopts IRTF WG ML , IETF MEXT WG ML Subject: Re: [IPsec] [Mobopts] MIPv6 IPsec Route Optimization (IRO) 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, "Haddad, Wassim Michel" writes: > I have just submitted a new I-D [1] which certainly requires an > introduction (and disclaimer): it specifies a MIPv6 Route Optimization > procedure *dedicated* to environments where IPsec/IKE is used between > peers (MN-HA, MN-CN, MN-MN) for protecting both signaling and data > traffic. > > Some of the improvements provided by this "IPsec Route Optimization" > mechanism (IRO) are also proposed for the IPsec communications between > the MN and its HA. > > Among the features provided by IRO (introduction of the document as > a more accurate list): > > * Complete removal of RH2 and HAO (resulting in simplified packet > handling on both sides and possibly better compatibility with > filtering implemented in the network), > > => You can have complete removal of both options without introducing a > new RO mode. Sure. But there are additional reasons (and advantages, as provided in my previous list) to introduce a new RO mode. IMHO, those advantages are worth the introduction. But I am interested on feedback about those specific parts of my I-D. > Please check > http://www.ietf.org/internet-drafts/draft-haddad-mipshop-tunneling-optimization-01.txt I already read version -00. I basically took a look at all I-D and reference documents associated with tunneling optimizations and MIPv6 RO (always in an IPsec context): ERO, BEET, RO design history, your draft ... Your proposal may have an interest for the common RO case if one intend to keep the RRP. I just don't. I am convinced that removing the duplicated states and exchanges when IPsec/IKE are used in a MIPv6 context can provide a far better solution. >From my perspective, I just don't feel the need to introduce additional states and exchanges (the PaT) because those are already available locally (and synchronized over time) on the IPsec/MIPv6 entities (SA/Bindings). Obviously, this is only true for IPsec entities, which are (as presented before) my targets. Thanks for your comments. Cheers, a+ ps: note that my -00 lacks pictures to ease the understanding of what happens. That's on the todo list for -01. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 17 15:34: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 00A353A6A86; Mon, 17 Nov 2008 15:34:27 -0800 (PST) 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 2871228C127 for ; Mon, 17 Nov 2008 15:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.166, 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 9O5ZbZrTiF+u for ; Mon, 17 Nov 2008 15:34:24 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id AE1893A68EC for ; Mon, 17 Nov 2008 15:34:23 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id A134929C001; Tue, 18 Nov 2008 01:34:21 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id D7662294003; Tue, 18 Nov 2008 01:33:15 +0200 (IST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mAHNXEQC007501; Tue, 18 Nov 2008 01:33:15 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 18 Nov 2008 01:33:14 +0200 From: Yaron Sheffer To: Tero Kivinen , "ipsec@ietf.org" Date: Tue, 18 Nov 2008 01:33:16 +0200 Thread-Topic: [IPsec] draft-ietf-ipsecme-ikev2-resumption-00.txt SPI values Thread-Index: AclJAz64F0TZ0rCYQNSiMG+NNLLo0AAB2kzg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A7812136@il-ex01.ad.checkpoint.com> References: <18721.61195.155616.874575@fireball.kivinen.iki.fi> In-Reply-To: <18721.61195.155616.874575@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-resumption-00.txt SPI values 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="===============0166914189==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0166914189== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01E0_01C948DA.933934C0" ------=_NextPart_000_01E0_01C948DA.933934C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tero, Thanks for your review! The wording in Sec. 4.5 is not very clear on this. So here goes: There are two pairs of SPIs. The old one is the IKE SA that was interrupted. SPIi and SPIr of this SA are included in the (opaque) ticket to help the gateway associate the ticket with a particular IKE state. The ticket is opaque, so if you don't want to do it, nobody will notice :-) The other pair of SPIs is generated during IKE_SESSION_RESUME, and as you suggest, HDR for the initiator has new SPIi, and SPIr=0. A related correction: Sec. 4.5 says "the sequence numbers are reset to 0". But in reality they should be 0 for the IKE_SESSION_RESUME messages, and increment from there. Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen Sent: Monday, November 17, 2008 16:24 To: ipsec@ietf.org Subject: [IPsec] draft-ietf-ipsecme-ikev2-resumption-00.txt SPI values The draft says that ticket has SPI values, but those are not used, so I am bit confused what SPI values is used in which places. 1) When the client does IKE_SESSION_RESUME what SPI values he uses in the HDR? New SPIi, and SPIr=0? Or old SPIi and SPIr? 2) From the test it seems that when creating new keying material the new SPIi and SPIr are used, so I assume the IKE_SESSION_RESUME request needs to use SPIi = new, and SPIr = 0, and then IKE_SESSION_RESUME reply will use same SPIi, and allocate new SPIr and those are used when creating the keying material? 3) Why are the SPIi and SPIr needed on the ticket at all? -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. ------=_NextPart_000_01E0_01C948DA.933934C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTExNzIzMzMxNlowIwYJKoZIhvcNAQkEMRYEFEnJ0lkJL9d5 ggjr4YNrRAUhLE9pMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA c3yJlYPzVV4TdLyoJC2s/SY+ielh9DZBppSgeTcktVTwd9DOvhy2u5FOrCVtT/b2RfB7ih/kNbs3 zSLL7GWhbrPjiqp24UzFuu2eHTUPgr1DnBX5gPgNLlZQccqvxW6XS510oRU5TC0fmw9o3NRW0Ici 269hSNWWo9AB8vev3w0xdnUwcooz/7SnwD7Su+66uyKR9/dKfMumsLu3xJpLPLlr8twpb41dCI+c vptt2w20gg/x/uBfgak3lbM65PreXw26+5e7MR3I+11c0oWJjWfX3v8O0hZWbjBjFfa3HyxB69It gTEQiFQKBtiQyPmFdMlcCEt0tIGy74QUhjNJbwAAAAAAAA== ------=_NextPart_000_01E0_01C948DA.933934C0-- --===============0166914189== 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 --===============0166914189==-- From ipsec-bounces@ietf.org Mon Nov 17 19:58: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 C9D603A68DA; Mon, 17 Nov 2008 19:58:05 -0800 (PST) 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 281603A68DA for ; Mon, 17 Nov 2008 19:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.109 X-Spam-Level: X-Spam-Status: No, score=-104.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, 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 zBUyGO5LosfD for ; Mon, 17 Nov 2008 19:58:03 -0800 (PST) Received: from g4t0014.houston.hp.com (g4t0014.houston.hp.com [15.201.24.17]) by core3.amsl.com (Postfix) with ESMTP id 4153F3A6828 for ; Mon, 17 Nov 2008 19:58:03 -0800 (PST) Received: from G3W0631.americas.hpqcorp.net (g3w0631.americas.hpqcorp.net [16.233.59.15]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0014.houston.hp.com (Postfix) with ESMTPS id 6A4F424541 for ; Tue, 18 Nov 2008 03:58:02 +0000 (UTC) Received: from G5W0324.americas.hpqcorp.net (16.228.8.69) by G3W0631.americas.hpqcorp.net (16.233.59.15) with Microsoft SMTP Server (TLS) id 8.1.263.0; Tue, 18 Nov 2008 03:56:55 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G5W0324.americas.hpqcorp.net ([16.228.8.69]) with mapi; Tue, 18 Nov 2008 03:56:55 +0000 From: "Sanchez, Mauricio (ProCurve)" To: "ipsec@ietf.org" Date: Tue, 18 Nov 2008 03:56:53 +0000 Thread-Topic: re: draft-ietf-ipsecme-traffic-visibility-00.txt Thread-Index: AclJMbFddXjqGBAvT72OpPV/URxyKA== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C4AA2541E5E@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Gabriel Montenegro , "ken.grewal@intel.com" Subject: Re: [IPsec] draft-ietf-ipsecme-traffic-visibility-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="===============0712421296==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0712421296== Content-Language: en-US Content-Type: multipart/related; boundary="_004_9BC2F7926B33FE4AB10D69891D58FC1C4AA2541E5EGVW0671EXCame_"; type="multipart/alternative" --_004_9BC2F7926B33FE4AB10D69891D58FC1C4AA2541E5EGVW0671EXCame_ Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C4AA2541E5EGVW0671EXCame_" --_000_9BC2F7926B33FE4AB10D69891D58FC1C4AA2541E5EGVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just want to go on the record that I have read the draft and support the ap= proach described by it to address visibility requirements. Cheers, MS -------------------------------------------- Mauricio Sanchez, CISSP Chief Security Architect ProCurve Networking by HP Hewlett Packard 8000 Foothills Boulevard, ms 5541 Roseville CA, 95747-5557 916.785.1910 Tel 916.785.1815 Fax mauricio.sanchez@hp.com [cid:image001.png@01C948FF.66C0C6E0] -------------------------------------------- --_000_9BC2F7926B33FE4AB10D69891D58FC1C4AA2541E5EGVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just want to go on the record that I have read the dra= ft and support the approach described by it to address visibility requirements.&nb= sp;

 

Cheers,

MS

--------------= ------------------------------
Mauricio Sanchez, CISSP
C= hief Security Architect
<= br> ProCurve Networking by HP
H= ewlett Packard
8= 000 Foothills Boulevard, ms 5541
R= oseville CA, 95747-5557
9= 16.785.1910 Tel
9= 16.785.1815 Fax
<= a href=3D"mailto:mauricio.sanchez@hp.com">mauricio.sanchez@hp.com
3D"http://procurve.hp.com/marcom/branding/downloads/thumbdrive/emailsig=
-= -------------------------------------------

 

--_000_9BC2F7926B33FE4AB10D69891D58FC1C4AA2541E5EGVW0671EXCame_-- --_004_9BC2F7926B33FE4AB10D69891D58FC1C4AA2541E5EGVW0671EXCame_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=7705; creation-date="Tue, 18 Nov 2008 03:56:54 GMT"; modification-date="Tue, 18 Nov 2008 03:56:54 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAMcAAACCCAIAAAB98ktOAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAHb5JREFUeF7tnQ9w3VWVx9/ry0vSlyavaLqzTaFVJyxJUTqMhSZKy0iLLQIi LbI4rFgWZLUryiAVwdSt0gUZFNF1o4uyLSgjW0lZRccCBQeKNmAdhmLbsHZUSltmt3FM2iZt86dv P/d3Xu67ub/3//3ykrT3zm/e/N7vnXvuued+7znnnnt/STiRSIRccRoIVANTAuXmmDkNKA04VDkc BK8Bh6rgdeo4OlQ5DASvAYeq4HXqODpUOQwErwGHquB16jg6VDkMBK8Bh6rgdeo4OlQ5DASvAYeq 4HXqODpUOQwErwGHquB16jhOblT9ZTCxqXuIyxpInrzef2J8RzcoGdbsHWjdfYwrU494fv0eRcCn ScO9XzM5dSK1UGxOyiwE4Ul9Eob+r3jhMN3rWFS7vL5C9zO86a8tzVO3NVdnVw0jsaRmyl2zK0vR YKa6ecqQvWmAsmHH0VAsEoqGOubFzD5KxTC/7jmWYhINt82LSY/oXefuo4nlpxXUO6ll6bMgDhBP blule7vi1f5Cew496tvSN84mLbvYGw4MAqnEsrrE4jo/pMCcglQ80rUsDnqAAtzWbe8rxU6vnlHB hDw7VhIwSqpcxECOSZWZ0VDvsFJxhoJJEyeCNxHbLk8UsA4OcsPXF3uHTX/BV3NsTHemXZJJrx2H OCO/IGk9tSYzJZSH4txDSBtV0iKPn+cGr6Gu1mlneSAAdh2t07hp2nNcE8NH+0fLr6XtCHgCWMKQ YrrXTNXhY8l2MnhA5uiK7f2hwRPdy+Jvj4bpoel9wr/rD71xXDmRWDjEOMUj3YtqH3hrcN2fj6uv 3vO2d1TtGziBr9m6uO6CeERxeLInFJuCheCeEV347CF+ao5NqcfhMsDQDIZC/cOhOVWJ98agEccR wgt7QR6Ww5RBfm2bX5PW26YkjIaEORI+3zsszj1Z6isSnikygagIZkYTHpJ0wSe2TY/QUFIkRCXE BCUeZ+kR+MjeEfGbquM0AbKlX9Fw1+I6ADeqOnRwHtGDiHFS2CriqvkxOl/vMxJqugMp+owTWVQL MlBB/Y6jKF0GqWWOuuHrDTMY0tBDBwGL0qZSZe+wzE71MBoGbVTkIeBgbGAIW5iPioh7h4G4Fcow lRXgGqvTQmqUhIvrYC4SYngUH4bTu7EghVSveMuRlumpaFJGNHHOVKshJhsC49fgLNIqRWXviMdq oRdXoLSk6rCCnoYvwxbq6ovrVp4zFT2YFuskQZWKOfCDe45ZnmLFH5QWuum2V5QdgvKAbbGTP8Ui Ko4JhVZ70Qw3mDQ+N7wxEGrwInoqxpUZEG5d3mpgBb+OFCJlK/pB1wQ6yqKMyKCJ5UaqCyuKYo6Q 6SS0KuYZEeIfxX7j11IcPONtd8TTlS4qAACCc6rEePPZ0lgdGlBQ7iTYMKqv5znx3P6UHk4SVKmB mac8kUyvVPGMTf2TPfgjuZSmMi2bG6L8in3qZFAZg3gETSlzxbyUIeHeCGOTwUdfKuKxjERnz9A6 kSfLQt2rruMYRUwTeSzsWb1aOEv7dRRnTaE6oqAmJUkzutGdni3EmWoy1tRJbwtl/7BWqdLq6D7m JVk+0o87DapRRr576LuegTELXsm60krb7kHnNuZx73A7CMMndg+JuboFQ1hEoW5DpXJq6ZJqGfnl ASnqLvVMCMC1+BCl+cPnImSXKoSb6evGI5ZKt3qzWsrJgyo68/PGKizzqlePphThGf8L4xEck1z/ m3nMPg10ouENe5Qlv5r1FMAaTChjE4+IE+FXFfmOlOQisSY1m+0BIO6WKCcWyZj78KqPygWodV/K kGQChHJMuOnRGUuJ0tb1pFkwjuKjOpLKc6btiCQXNvSm+ss6ILztSFIP3pJTXxLknZyoYuzb5lar pdlIaZulYiCCX4m7ibpWbe9bsWsEdtGwcnZmIeqiugcjFSGh/cFEiwRVFG56h7UlaPK8W8ecjElU KgoclVRGRbNBqS5RMEUx7x1WEUweRbH1VnMCC3on2O1idmUvdKTf6IjXutUR5Ra9GFRCVfVJOFXp mSGWKUYqR2JHFYyOlJPKVtEpZRiMJLv66q3U6jf3hp89RIIgFJ2SstUeSngeHlnDCwpHwSgUug+j 5RUV9RNsbe9TVTYfCuHgGqv9yUn/gIq5WrcrTR5LVfckhCFsVWgfjyijm0dRbMFf73ATvdv0V9U7 b2mWPpYyGNod8ZbJ/o6IomCLfjzVhWVV0c1nPEIiRsm82ZO5vmKUzOzYTN7S1Tfcsuson2YXtvYM 8bDj4KB+yD1PuNreON49cEI/537lH9RzLnnIE5OhVDSZm1X8TZiUaWWwRNX07QcGtIQmEwTmyj5A 0l+5TP6W8Jau6AicpVaWjkgtLhRlqg6RdHWEtySc3FnQPOazIxkHDZxsHnAcVOia9GnAocqBIngN OFQFr1PH0aHKYSB4DThUBa9Tx9GhymEgeA04VAWvU8fRocphIHgNOFQFr1PH0aHKYSB4DThUBa9T x9GhymEgeA04VAWvU8fRocphIHgNOFQFr1PH0aHKYSB4DThUBa9Tx9GhymEgeA04VAWvU8fRocph IHgNOFQFr1PH0aHKYSB4DThUBa9Tx9GhymEgeA04VAWvU8fRocphIHgNOFQFr1PH0f2dhfJh4PXX Xz9y6JC0N62u7qyzzipf2+VtKYUq+vyv69bl03rLggXNzc3rN2yA+PqVKw8fOfL444/nU1Fo4rW1 n/nc50Snv3r22We2bOHm4iVLPrB4cf5MNGXjO9+Zvdb06dPnvvvdyHzl8uUzGxqKaKLEKr/77W87 Nm16evPmnp4ekxWCfXDZsptvvnlcpCqxU9mrJ1F1+PDhDyxaZHU7U83v/+AHmzo6fvnLX0Kw9de/ XvWpT7322msFSfme97zniZ/9jCrXffzjp59++u6dO2vj8Ud++MOCmAhxTlSZPG/9/OdXfeYzRbRS XBW02v6d73z/wQezV//kTTfdfscdxTUxMWsl46r/6erKB1Lvu+CC/9q4cf755wuk+Mo8Ax97/vSn X2zevPYrX5k9e3Y+/dQoBFLQ9/b2nj137lsHDuRTtxSa+7/xjTvLNX5A6rprr80JKboDTdmkKkV7 +dctIFoHNJiT95533k+feEIauOqqq3RLeLR/uO66555/HjJse/4SHAZSZ5+97803y+MINj72GG43 f/GKprzz9tvzN+Flk6ro7hRUMekB8f1/f/XVWWre/8ADH77iCiG48sMfFn29smNHbe2of1ggBIRo 115zTXbjh3kTYprmE7AWJLcmtjwgxvKqj35U/9r50ku/efFFizM0oL+45vKs9bOf/vTWW27xt/uP N9wwa9asl19++ScbN1r6KYNUeQpfOlleqDLDEfzUwve/n4YvueSSf2tvzyRBTmBpVJXYBwtVOGUr Pks7YQgHM5lGOnhg//5MazSZA5SGWbOyGNeLLrxw7969ZtcIJR959FE9CdPqh4C1uCVLFh2KwH/X 1JR2/heqfN397Axze0DmkBnhPrFpk4iyfMWKLDLhEJmXhQo9FvRYwauvucbiDG54wloBUOqLJ/fe cw9zBrNtLYcBwc2rVkHJT3JBNv/cc6EnfrKY42EtSEHQ/r3vmeOaVj/YMGFlCUbIr5tgXE2Z9aSy nlMFmQG3SEvc/KNHHrEq+gNZ6aNcmFuzUav7555zDi7LpDGVkBtVt9x6q1nh8Z/8RL6SWaDzqJV7 5DMlpjO0BxbzDN7HAkwmz9NnzcqnCWROG1wzQpcuWyYLFLPgwqBn7WwFapIrMYssa6yHiy++2HrS uW1bPnLmSfPF1atNcC9essSq+KxPTrOPH7joIqFnJQEu/d0nCsLLgy3/vMqNKs2dBoC/CApc9u3d S8iCWnmoDRh2nl+hkQzW0mXL8lTBmJLt8yxTzvLA/ff7aYAUK8csdcHWJ2+8UbsGKDt/8xuLnmyZ n4M/C5p/dJ+zL888/bTFDVjL6OjyUmen+dWcG4Q3YlmBFCuJLM3RCktdC1g5UMUkM+32f4+4vzVf /nI8HqcxlntoRwwY99h5kUBSBkt88yOnOgInYLz9eiEs8Dfkd1tMGAtSKIToh7WLNUL/dNNNWrN+ PiSN0/aLNI1crHsINIOKNWkrLUBXGGt2aDA/JhpME3vx0qUQgDNLdcQSSIsG0IPuEW3dc/fdZgdz oErAoQsrF+4xVE3NzSI32WFtwLjXRpVcOb8WvbIrGltYUKyLvvDR/rWtNVWytPWwt3+gCx3/9/Z2 AmqWw4TeZgIFiyUJF7874GFdnfqvfP6CfuQKJJTOqTS/E/zVc8/pWmT/9b04qLu++lWTJ9nau++5 B2nRAHowwxvAZ0ZpuVBlRCQgVxbD+LVHHn5Y2gM92oCtWL78Px96iIeoO/C1TE6VCQF2AuuiL39a ARp2mTJxQ3LybawQZSFpzVTWH3r4uWltbTX5dHhOn7g4T1HLQCaWFRMo09vvBDtHnCCmQWc6xP35 1xzXfeITWmYIzAwOz80oLQeqzIhEW8iPLF/+lIdrQY82YKzGxfh/NGvqqwzazNIENjwL4u/7+tfJ 5UpkbYZKwtByZM1z55oNYbzTGqrx6i+2hLlhddZygto+adOgLIXn/nbv3m1JTvRs+gErWjWjtFyo 2rdPWKMvkUDsnkaPacC0ZMBOapVhE6agMRMbnqkKXTPHwK9Wq+LpZ5xhPcFQld/pZ+qOtXgXMssJ Yp9k8oiZkCLujwSyxdl0AtxbhnzfCFSolQNV2oPggMVC4gV0tAF6/AaMsdGrm9+O5AwLGvtgiTGo OALwhF/LvolrrVgPjZxaySTPrJJPQDDrxs68nZduuwIzbAbadG3Lli2IoVcYevVX6CiY64PcmQXJ dD3z1FMa7NpoNTQ0aBNKRkckM92trlWoiEXTozJZTOlr+yuv4AjAU859xqBCZmvY6MtLvnkvHbx7 3TrSiTrVR+6n6I77K2bqr7l7K1bKDIkyJbdlcma/tAy5USWZp5XXXy9r4Gm1tf/x4IPcfPfBB7UB A+Ds6sj18ZGYjhngT50FqLWxZpUpHaDb3Z/hkIU/O0X2yC8tVmpboGnPPBViJiCpgi144JvflLpZ llmcUWNyZr8KQBVOkGS/uQaWe9ycNkV3trWRSZdLz/jbb789z35OTLKG0VkVhLRgxDkLS3IJqjge aD3HO/hj/x8+/LC1wdwyelGZVi05/XJOZTJAWAGTTItBbkg/t+ZG2tW0Dt5xaKwiC0AVpGDZrCOV mWpiisgH+o0tOdm0cuTs88QhYNpYO056HS5CWhZID5U/doGYNKkJLCaqP2WvVzmWEszYS47gllhk lecvkmWU4t9Qsnb9WKjp+J2tm+9861uFoQosc7LFmm36lNX1vl3knGn+EpVStupWSoZVj55dqNjK XxMkaMG+1NZmCYkOyceyIU1ils+1//IvFgEhS6aT7GyLYRVokbqBzFXLCYoklvvzT6qvrl2rgcXN 6ttuM7tgBmS54yqpKUoBLjpZIEk/iikiyCPkzL5zVDZMlN4QMaJlrliUMLT00To+haEycwoMCbs6 fgFQI7DwnzxjRO+9915Nb21p8ByrQIuBQApufifIQ9P9iSRk78wuIDYyyNqCG7MXTAkzKZMvqoQ7 cOEECIciwJbMVLTJeSRmEoCTcxcBbpGWDosSOaB9FiXW0VaG1uojMcDdBiakUXZ1WLvkIwD8H33s MTOKYJciU0WIrS3IfJrw0/idoOn+hJ55knZuWNyQhw0c82ESVdTPX1beXEjt9y1dSvpKcmL+XdVM HSZ7VJwuyl8Lq8OQZ1EO88o8jmdKyNqFDZPsx4GY5U/+4heW70t7JgzOgj/0X7oeLCeYafXH3Mje BfYq/N1PvblFSEiolM8Sgzju9a4uWQGhOALPfGppRZCS1oeVS9eOeaINbgUxJzgw13ELFizIkhmH mGid14EwVPI2GG9wEF/n81qfvKBG9nnX73+P4wCjICPny2S0SFpHV2GFyE4cJs0SW85U4j30eSTR as63iUw+OfUGMUt+upBP991bpqUD23GwNVBYXOX05zSQjwYmParW7B0Iv3D4+j3HXu8/kU+Hy0OD vyAw0G3xNfCNdhhaCSSCgYJaobo/N+vXj0kGfwk5zMML/kYnParW/fl4qHtow46jTS8cKQ9i8mmF eIiMlB51vsr7F1aRscmHoZ8GhtYfIuCUwSHfqxlmRY0JeUj1TBuUZi2TjEYlecunnISh0csvvdQC 1qRH1dZ5sdDMqNKC9yHlu28Ntu4+xmdxAxZILRZ3pA2tIwngjLyMvJmDnWBIuHio7QEPxX6QbuUh ZNg8MmR8CitQSOzPEy2kvHfPuLJtXFdbK6xI9HBJzpZP7mn32o99zJIHZGhK2Oqj6/kYV9IfLAjY GTzjjDOshcKkR9UF8UiidVpi+WmJxalTvKv+cKxz99FV247gHwOBSBFMPvfZz3Kw2DRFgGn9Qw+R g+49dIg3CEyeLEU3rF/Pk299+9tyw2G1Q729vABNthm48Mm9GAmS2uYmHc8BB2tDsYh8sjvEa0W8 FP5p7zQ9+yLxujoSVKR+rE0hjpy0tLRACc3+/fvlSDFVSHJyjEBLCH+Bu//MGcT8QQPrCPWkR1Xa 8W4/s1oZsGj43Fiyg5iu8LYjZbZe5KbZbNHegUOzF3/wgwwAs5z1OUdnAQcXeRaSNZxfYIRIscpL ChxQ4dAE91+77z4I+NQvL8BWZw2wNDt37rzjzjtNPXAWFwISs8BI/oIGB4FgQkbjgHG2jipQ8lze FualaugxbCSYyEKZ54J4awi4c+kNFejX3XUXJvOKyy7jvZgrrrzSFODkRNWnZ0aVAbt8+vL6Cult 58HB0FuDWC/5+pfBRBmie7Jf5Ej12Q1Glw1pGR7rDJYkvXhTBXrGnuMMepDkJ/mUQ/F6bwQIkj8D CmxvmIMqgJBPZCANi/sDf2+++SavsfgpeUL6DVtF69hIoGPl2dkPlTMwbWvW6OocVsYeA3H+fIt1 NO3kRJXfgHXNr1l5ztT21mnyU/32vqbNveEdR9OaugAfckaINCYXPMmdshMvw4OJIgYyG2Ibjv2J BS0tjBYvlbS8733yepmEWRLxWEladTL90UfZF8ryh8fkDSjYzm1uJolvnS6RMItPJMQ04p0xqIAv n5dZoJczUX51nRKo2tQ9tLP/xPrGamyYqGDljIpQLLIyFub+xd5hchO4yADBpFkxipzJ1oezid+J tHAcGC1+whtyI7GXmIfzFizggp6vGAC2toiiIODTv811+uzZ0LAFDiYy5QgEu8D06WeewWpaS04c NNHeP69aRcQtr2RBXPrLLJG1a9eOhTYnDk9SWXe+3LfxjYGv7D72VCh8I3gKhT7ytoq1jVV8cr/3 eGL9zqP7ouG1Z1SCsDk7jy2pmTK7uqT5FolEmkb+YAZOpyYWO3/BgosWL/7bmTPZ3Zo7d+4dX/pS VVXVO9/1rilTphw/fvy888+vnzEDsks+9KH6+vqKiopLLr0UggsWLjztbW+jyuVXXHHDjTciLT9B zE04HFav+DY1QXbmmWfyCTJolIdYEf64iBATvw8MDa1ZswbrCAH5DkAjDgsh8Wh//OMftTw8fOzH P77tC19ABj2CkGmGNHraaachAJzpUaYz2Sf/jg2GagXh1GBCqSkWSSxTS8Xws4dCZE3rKzrOrNax F8+BIKkvfCWGDet13fSINm8TZ54UJAk5AgykIGn3rl2sCTjIn5aD3umTP4NYSjn5USXawQj932Di 7NiUs7xVYfjJniTO6isSi2pZG5KMCNVEtjZWzYiGUzT82jqNxaMFvlI0Xv66xGSSEcDh8uZWlj+x xFEUVnOlvxVyqqDKGkvWgM/3Dt93cOi+higZLzFRisYDGVaKNePKhigWS0Fw86GVjZU3zIgufLWf qF8w50oWDZyiqPJrBEf5ZM8Q0AFkGCfSENCQXFXrxAODLXMqN8ypbNp2xMy1TkZgkRZet38AAzym wp/qqCJrdXAwAZIsLQOyv4mGea7s1u6j5FSVK9z0V8i6lsV/1D3EzV2zK8d0bAJnriC1vS80pyrx 3ljgzE2GpzSq8IP1m3t1II9B2tZcLc4RHV0Yj7w9qlIPuiiE9Qx1z6+RWlsX1y1kkGZEuxqryFyY Uf+YjllxzJXR3XOsDJBSMUMi4S2OTtWSCtvRQDRMOj4VY/HEM1HE8o/0KJxJEMYNFk5ghK9sma7S E9iztvk1HKBgt/u1/hNX11dYiBxfBYd/1x9643h5IOVQpcYaZ8fnK/0n2DQEKKwWicpDmCuSEeL4 XjjMYRtF6sXyCoiUeKS7ddrG7qEDgwnZbWSB2bT7WFdzNVl7chOE//jKcQztVUrl1f62M6sJpAgT JV1SHnCf6rYqHy1jmVa+oc4+SPpKgwzQEL8r/PE/MvCG5MDika7WaRB3DibapkcEpvk0ESwNAjcx MVhwxCKhfiUedrScUaBDVUkDimF7qne4IRq+KB5pIsYilp9fg62SgVShMagiOBtMdMydKokM0mZj BzWCwsv2HO8kfgqFWhqrOw8MAPoyQ8p5wGyQIpx6uW/4ci9sEgeHO9OxPE9kkZiJhabEt67rGcZ0 qWOrNRHiGxIWJWF5dGWQ3RybQhinlni7jinjNKeqY06l7CiUH1IOVRkHVwUlhFNm8WJ5ncqSXwhW +ExmUL1ga+v8GuUKvcIRiVUHh0I9KibjyNcqUEWsFg23zapUCIuG299RxTpg9YwKzBg07D9u6TvB OjQfzKn9AGodGFQwYtcczgR/8UjHvBhwX+gJ3z6/Zlx2nFyaOP0IYplUUGIWzyzJii9ZouHzayJc ysd5kApNr2DDR3k9uTKUfQPJFzeAFEl8jBmfXJg0PomKwDSXOmm44yhhHLuWpMpkVQGYWNCxYlBn xVjWxaeodgmheodbmqeSpIWbQGrrotpxgZSzVfkYhbGikWODz/UOS9qCosIg0CzH7QElMPKMUMuM qDp1SJGlKMBtqGxviCpQEkJ5a9WueTEcdDLPGQ0DqSzeeay6NMLXRetjrWGV3CJ9TzOrDwx2gqS+ YXYYk04Tc8gZLw8rWBqgA4CaoiGCOXKw3YOJrx0Y2ICbE5yNgAkLpNzfq0eV74tFOubHJPxPbgOM N6ScrQoSUpIaZTOxazAEMtRuNJ5ITuAIaNj58YrKZhEPeQHW0njEWhXCR4GJXIaXs1BlZhTKW2ZG CcmT6bQRIOogLJnnjEW2ttaMo5USeZ2tKgZYOoPFBo7ghoxoavPHY9mxqDYZ72OQ4lPwUGAFI6RP 41gNK7iAJIm+fWDigdpfYteFWIpSX2GenkhCCvO2qHYi5PQdqopB1ah9Ho0hORvoJag4wUwiG6Dk NBujlnIiSzyyck7l1+dUmfhQ3k1CqFikfd5UHYYrqGERsWoTBlLOVhUDKaU1cgcMpBcVEQmRESg0 c63AhFkiPB9xkQKmLzZUWps8KsexvV8MGG70540ptE1MSDlUFYmq4qoBggfeGpRduRQHXspoTAMm CNTGC9n5kS1I9q1Ny6c85rY+hbb6CvzvRHB8ulPOAxaHkAJqJaNvvZSTqti5hujWOZVpXaQyQrzz 4228qKB+XsyyhQpSshQY+8NSBXR1hNShqgil5VUlzVIuF5iErzqKA6TEMzZWdzdXW3ZIeU9s2ESF lPOAeeGjUKLUfpyuaaSasnAzQyjZ/PFbsmSeEy4T0kpJ75ytKhQzuelT57HyAxMcU2dXPJe3srk6 7VmoSQEph6rcECmCQs6O5rkwTJ5dGUmQYoG6z5maNvROJqXKfliqCA04W1WE0gKromwPx+skhPKO G2Q6ejWJIOVsVWD4KJSRHP9N7slEw5ywy3QARq0Hya96+YVxOSxVaNccqorQWKlVVAjFEk82Xigj xw3S8k3lOScPpByqSoVIofVTGy/UNI4bpOWjklJkEEjiR8MdrdPG7lxyob3ISe/iqpwqCpJA3lOl sPeS/cxnKs85AU62FKoCh6pCNVYSvbJV/Sd4uyv7G12pv2MzCSHlPGBJEBmjyqmk1OSElEPVGAGj eLYpSHmvFo7jS6rF98Hl1kvRXeB1k38KAb4T6bBUEd10cVURShuTKjrPOdkhhXbcm1tjApFCmXJO IZnBmuRWSjruUFUoAMaEXr0hzVb0zOgEOXheYiedByxRga56Gg04W+VgEbwG/h+7AVSP0DwjiAAA AABJRU5ErkJggg== --_004_9BC2F7926B33FE4AB10D69891D58FC1C4AA2541E5EGVW0671EXCame_-- --===============0712421296== 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 --===============0712421296==-- From ipsec-bounces@ietf.org Mon Nov 17 22:07: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 4CFB23A68F3; Mon, 17 Nov 2008 22:07:14 -0800 (PST) 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 CC2213A68F3 for ; Mon, 17 Nov 2008 22:07:13 -0800 (PST) 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 aZh41yiI6Ev1 for ; Mon, 17 Nov 2008 22:07:13 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by core3.amsl.com (Postfix) with ESMTP id 7FFDD3A68DF for ; Mon, 17 Nov 2008 22:07:12 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id b11so1398272nfh.39 for ; Mon, 17 Nov 2008 22:07:09 -0800 (PST) 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=1law6rFvMXgXovg58ZkpatOFtNsJr127NLcoCr1Z71s=; b=x7G74apMvBjQlKMm4347qyG1/44TNaVE7fkV+4IvO474S0KzjHoMdcRR3KKYZ0x/aQ JGj4ObpBKbKCVhexINgkvsZaiweucyA0i2+Zd2JKRETfJSA0Gdf+0mzSid0ptRl4cHV9 IvWW8hkR05NMRKDOaT0FlG3hvZLMefrStPupI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=bZLpua0lXJNrxiWykZfkXHMxmC6odNiQWDYNMBrvSm4m8H1xFkZHn4fmbcIhcNhXaT O4SCTniCCgiLHggdgAnJhXwW2TQt9vSupUwsCSsci/J1b97LGy7llvZK1uZV8rOG/kr5 wvEvCg+vqEcUfP/Eml51J1W2RbCBYln2BCSDM= Received: by 10.210.18.18 with SMTP id 18mr4646899ebr.71.1226988429803; Mon, 17 Nov 2008 22:07:09 -0800 (PST) Received: by 10.210.109.14 with HTTP; Mon, 17 Nov 2008 22:07:09 -0800 (PST) Message-ID: <1d38a3350811172207m1801bf77ra4518f06deb61207@mail.gmail.com> Date: Tue, 18 Nov 2008 14:07:09 +0800 From: "Hui Deng" To: ipsec@ietf.org MIME-Version: 1.0 Subject: [IPsec] draft-ietf-ipsecme-ikev2-resumption-00.txt ticket location 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="===============0920199382==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0920199382== Content-Type: multipart/alternative; boundary="----=_Part_48403_16585172.1226988429797" ------=_Part_48403_16585172.1226988429797 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, authors, After reading your draft and rethinking of the main issues, I would like to raise one issue about ticket location issue: there have two problems on sending tickets with all the information to the client a) If the session resumption solution is deployed in mobile network, it will consume a lot of air-interface cost to request/present/update the ticket. As the mobile operators, we prefer not do that. b) As discussed in the list, the packet to send the ticket may be fragmented. When session resumption happened, a large number of the client may try to present the ticket at the same time. In this case, a bunch of fragmented IP packets will be sent to the gateway. Some equipments (such as mobile network GW, firewalls, etc) between clients and gateway may be overloaded to handle the IP fragment. And, some equipments may treat it as DoS attack and simply drop all the fragmented packets. the most important issue, the wireless base station will be chunked and died. thanks for your consideration. under this consideration, we would like to recommend the solution which could store the ticket information purely on the network side. thanks for your consideration. -Hui ------=_Part_48403_16585172.1226988429797 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello, authors,
 
After reading your draft and rethinking of the main issues, I would like to raise one issue about ticket location issue:
there have two problems on sending tickets with all the information to the client

a) If the session resumption solution is deployed in mobile network,
it will consume a lot of air-interface cost to request/present/update
the ticket. As the mobile operators, we prefer not do that.

b) As discussed in the list, the packet to send the ticket may be
fragmented. When session resumption happened, a large number of the
client may try to present the ticket at the same time. In this case, a
bunch of fragmented IP packets will be sent to the gateway. Some
equipments (such as mobile network GW, firewalls, etc) between clients
and gateway may be overloaded to handle the IP fragment. And, some
equipments may treat it as DoS attack and simply drop all the
fragmented packets. the most important issue, the wireless base station
will be chunked and died.
 
thanks for your consideration. under this consideration, we would like to
recommend the solution which could store the ticket information purely on
the network side.
thanks for your consideration.
 
-Hui
------=_Part_48403_16585172.1226988429797-- --===============0920199382== 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 --===============0920199382==-- From ipsec-bounces@ietf.org Mon Nov 17 22:19: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 9A83A28C138; Mon, 17 Nov 2008 22:19:08 -0800 (PST) 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 DF7E13A67F7 for ; Mon, 17 Nov 2008 22:19:07 -0800 (PST) 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 NsNPb2Dh185T for ; Mon, 17 Nov 2008 22:19:07 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 2BA553A67F1 for ; Mon, 17 Nov 2008 22:19:07 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so3128754wfd.31 for ; Mon, 17 Nov 2008 22:19:06 -0800 (PST) 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:content-transfer-encoding :content-disposition; bh=wMlHaJHMfyR4BCVB/dyjCPJUPx0GQ0TnU+yyF0TtwsA=; b=qMcJNWVbAI5sWnIn66/CPcnWZM41ik/l74uZ9E3mxPapYNLZek1LIrQ1YO0O1VghBI c9ug6gpIbmTwA/O0djtF7YK0NxwTn0qazxnnRa7PFsNJ8udq/x2wgLVHLvBIPOeI87lq RpjdQ2gvDUMvLPw2qU15wEAAw405J/cCc9LhE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=TDxCyZWJFDuN+ngfqGMWYCn54mgPfcKarNz/zjbJfkn0Fhwo4Qy48pN8dCmq9TKPEo T0pp6SRWuq5BpdqyqctM83SRCaR9qDKDq9AGOKQyemMocZCGWJ60qDc7gB+zAP8Vg/1x i9obrvsQHS4snG2zOeAlO/LAHJ5M3GILsdfqc= Received: by 10.142.115.20 with SMTP id n20mr200494wfc.344.1226989145997; Mon, 17 Nov 2008 22:19:05 -0800 (PST) Received: by 10.142.211.4 with HTTP; Mon, 17 Nov 2008 22:19:05 -0800 (PST) Message-ID: <4c5c7a6d0811172219j96ce787qd265ded48f4c60b6@mail.gmail.com> Date: Tue, 18 Nov 2008 14:19:05 +0800 From: "Peny Yang" To: ipsec@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: [IPsec] Comment on draft-ietf-ipsecme-ikev2-resumption-00 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 just went through the updated WG draft and RFC5077 as well. In the draft, the new IKE_SESSION_RESUME is defined to present ticket from client gateway for session resumption. However, this need to modify IKEv2 base protocol by new messages and related protection of them. From the implementation point of view, we do not think this modification is small. And, when we consider the case that the session resumption can not be continued by the gateway, gateway will reject this message. Then, the regular IKEv2 procedure will be done afterwards. In this case, at least one round trip is wasted. Also, I checked RFC 5077 as a reference indicated in the charter. It just added a SessionTicket extension to the ClientHello message for ticket presenting from client during session resumption. Solution: Add a payload in the IKE INIT message for client to present the index of ticket to GW. Then if GW can not do the session resumption for some reason, it just sends the IKE INIT response to clients and starts the regular IKEv2 initiation procedure. IMHO, this way is more efficient and flexible. Peny _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 17 23:51: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 6DA6F28C14F; Mon, 17 Nov 2008 23:51:55 -0800 (PST) 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 89C8C28C136 for ; Mon, 17 Nov 2008 23:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.783 X-Spam-Level: X-Spam-Status: No, score=-0.783 tagged_above=-999 required=5 tests=[AWL=-0.605, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] 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 R6H1weGR07OB for ; Mon, 17 Nov 2008 23:47:02 -0800 (PST) Received: from mail.f5.com (mail.f5.com [65.197.145.96]) by core3.amsl.com (Postfix) with ESMTP id 5819328C118 for ; Mon, 17 Nov 2008 23:47:02 -0800 (PST) Received: from exch11.olympus.f5net.com ([192.168.16.104]) by e2k7ca1.olympus.f5net.com ([192.168.16.101]) with mapi; Mon, 17 Nov 2008 23:47:01 -0800 From: James Goodwin To: "ipsec@ietf.org" Date: Mon, 17 Nov 2008 23:47:00 -0800 Thread-Topic: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-00.txt Thread-Index: AclJUK5aADx+lUBaRNqUVQqA4N1m2gAADhVQ Message-ID: <4B18A8F75A6384449755BC7784073E935F6AB05D39@exch11.olympus.f5net.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Jeff Bellamy , Amit Jain , Ryan Korock Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-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="===============0650081477==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0650081477== Content-Language: en-US Content-Type: multipart/related; boundary="_004_4B18A8F75A6384449755BC7784073E935F6AB05D39exch11olympus_"; type="multipart/alternative" --_004_4B18A8F75A6384449755BC7784073E935F6AB05D39exch11olympus_ Content-Type: multipart/alternative; boundary="_000_4B18A8F75A6384449755BC7784073E935F6AB05D39exch11olympus_" --_000_4B18A8F75A6384449755BC7784073E935F6AB05D39exch11olympus_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi again, One additional note. Forwarding some food for thought on behalf of a collea= gue. We are certainly in support of the traffic visibility draft presented. Stra= ight-forward solution and will be easy for our traffic management appliance= s to act as intermediate devices to view and act on the unencrypted data pa= yload. Below is simply an additional idea that may have been explored already (or = may not be feasible for compatibility reasons). Thanks to Amit for spending= some time putting these thoughts down. Cheers, --James The alternative is to use the reserve space of SPI (0 - 255) to indicate th= e ESP integrity only mode. (Something similar to what is proposed in the UD= P encapsulation case in the draft) The way it may work is: 1: Reserved SPI value of 0x00000001 is used to indicate the presence of int= egrity mode. 2: There is no change in the ESP header for the integrity only mode. This'l= l allow the non-compliant devices to just treat the integrity only mode as = normal ESP/IPSEC traffic. 3: The compliant device treats the packet with SPI value of 0x00000001 as t= he ESP integrity mode packets only. 4: The real/effective SPI of ESP integrity mode packets are part of payload= . (Just like IV is in case of some encryption methods). It may be first fou= r bytes of the payload. So if the sender of IPSEC packet is supports ESP integrity mode, it puts th= e SPI value of 0x00000001 in the SPI fields of ESP header, prepares the oth= er fields just like it would normally and then puts the actual SPI in the f= irst four bytes of payload. (Since the payload is not encrypted, the SPI ca= n be retrieved at the destination) =F0 The intermediate devices, which understands ESP integrity only mode; l= ooks into payload and apply traffic management functionality. =F0 The intermediate devices, which do not understands ESP integrity only = mode, this packet will look like just like any other ESP packet and they ca= n treat this as the normal ESP traffic. =F0 The receiver upon receiving this packet extracts the real or effective= SPI from payload and applies the IPSEC processing. Since the payload is no= t encrypted, SPI can be retrieved at receiver. In this scheme, both the sender and receiver need to be modified to support= ESP integrity only mode. But the intermediate devices need not to be modif= ied. This'll lower the deployment efforts for the ESP integrity only mode and he= lp facilitate the use of it. From: James Goodwin Sent: Monday, November 17, 2008 11:39 PM To: 'ipsec@ietf.org' Cc: Jeff Bellamy; Ryan Korock; Amit Jain Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-00.tx= t Hi, As a follow-up to other comments on the Wrapped ESP for Traffic Visibility = draft, I'd like to add a quick note. I have reviewed this IETF draft, and does appear to be a reasonable solutio= n to the problem of intermediate devices determining on a per-packet basis = whether the ESP data payload is encrypted or clear-text (for network monito= ring and deep packet inspection). It overcomes the original problem of ESP = not providing an integrity-only flag. This, IMHO, is a cleaner solution than a heuristics based approach (pattern= matching to determine if payload is encrypted). The data in the defined XE= SP will allow our traffic management OS (TMOS) to easily determine whether = the data payload is encrypted, inspect, and apply traffic management rules = based on content in the data payload. This will be possible with fairly str= aight-forward software changes (and may be supported to some degree via bui= lt-in rules language - no code changes necessary). A couple questions/concerns: - Why not include an "integrity-only" bit in the header (flags oct= et) so that the wrapper may be used to handle both integrity-only and encry= ption + integrity modes for ESP? I believe Yaron has also asked this questi= on. - How much change to silicon (cost to chip vendors) is required to= support the additional XESP header and new protocol number? This must be w= idely supported by IPSec silicon vendors for this proposal to succeed. Thanks, --James James Goodwin | Sr. Director, Product Development F5 Networks t: 408.273.4821 www.f5.com c: 408.421.6956 [cid:image001.gif@01C9490E.85B71DB0] --_000_4B18A8F75A6384449755BC7784073E935F6AB05D39exch11olympus_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi again,

 =

One additional note. For= warding some food for thought on behalf of a colleague.

 =

We are certainly in supp= ort of the traffic visibility draft presented. Straight-forward solution and will = be easy for our traffic management appliances to act as intermediate devices t= o view and act on the unencrypted data payload.

 =

Below is simply an addit= ional idea that may have been explored already (or may not be feasible for compatibility reasons). Thanks to Amit for spending some time putting these thoughts down.

 =

Cheers,

--James

 =

The alternative is to use the reserve space of SPI (0 – 255) to indicate = the ESP integrity only mode. (Something similar to what is proposed in the UDP encapsulation case in the draft) The way it may work is:<= /p>

 

1: Reserved SPI value of 0x00000001 is used to indicate the presence of integr= ity mode.

2: There is no change in the ESP header for the integrity only mode. This̵= 7;ll allow the non-compliant devices to just treat the integrity only mode as no= rmal ESP/IPSEC traffic.

3: The compliant device treats the packet with SPI value of 0x00000001 as the = ESP integrity mode packets only.

4: The real/effective SPI of ESP integrity mode packets are part of payload. (= Just like IV is in case of some encryption methods). It may be first four bytes = of the payload.

 

So if the sender of IPSEC packet is supports ESP integrity mode, it puts the S= PI value of 0x00000001 in the SPI fields of ESP header, prepares the other fie= lds just like it would normally and then puts the actual SPI in the first four bytes of payload. (Since the payload is not encrypted, the SPI can be retri= eved at the destination)

 

=F0  The intermediat= e devices, which understands ESP integrity only mode; looks into payload and apply traffic management functionality.

=F0  The intermediat= e devices, which do not understands ESP integrity only mode, this packet will look like just like any other ESP packet and they can treat this as the nor= mal ESP traffic.

=F0  The receiver up= on receiving this packet extracts the real or effective SPI from payload and applies the IPSEC processing. Since the payload is not encrypted, SPI can b= e retrieved at receiver.

 

In this scheme, both the sender and receiver need to be modified to support ES= P integrity only mode. But the intermediate devices need not to be modified.<= o:p>

This’ll lower the deployment efforts for the ESP integrity only mode and help facilitate the use of it.

 =

 =

From: James Goodwin=
Sent: Monday, November 17, 2008 11:39 PM
To: 'ipsec@ietf.org'
Cc: Jeff Bellamy; Ryan Korock; Amit Jain
Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-00.txt

 

Hi,

 

As a follow-up to other comments on the Wrapped ESP fo= r Traffic Visibility draft, I’d like to add a quick note.

 

I have reviewed this IETF draft, and does appear to be= a reasonable solution to the problem of intermediate devices determining on a per-packet basis whether the ESP data payload is encrypted or clear-text (f= or network monitoring and deep packet inspection). It overcomes the original problem of ESP not providing an integrity-only flag.

 

This, IMHO, is a cleaner solution than a heuristics ba= sed approach (pattern matching to determine if payload is encrypted). The data = in the defined XESP will allow our traffic management OS (TMOS) to easily determine whether the data payload is encrypted, inspect, and apply traffic management rules based on content in the data payload. This will be possibl= e with fairly straight-forward software changes (and may be supported to some degree via built-in rules language – no code changes necessary).=

 

A couple questions/concerns:

-&nb= sp;         Why not include an “integrity-only” bit= in the header (flags octet) so that the wrapper may be used to handle both integrity-only and encryption + integrity modes for ESP? I believe Yaron ha= s also asked this question.

-&nb= sp;         How much change to silicon (cost to chip vendors) i= s required to support the additional XESP header and new protocol number? Thi= s must be widely supported by IPSec silicon vendors for this proposal to succ= eed.

 

Thanks,

--James

 

James Goodwin | Sr. Director, Product Development

 

F5 Networks 

t: 408.273.4821

 =

www.f5.com 

c: 408.421.6956

 

3D"cid:image001.gif@01C8F717.E4DD0E60"

 

 

 

 

 

=  

=  

 

 

 

--_000_4B18A8F75A6384449755BC7784073E935F6AB05D39exch11olympus_-- --_004_4B18A8F75A6384449755BC7784073E935F6AB05D39exch11olympus_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=4931; creation-date="Mon, 17 Nov 2008 23:47:00 GMT"; modification-date="Mon, 17 Nov 2008 23:47:00 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhyAAuAOZ/AIqJia6SkpIwOLQUL7i4uNbW1nk6O7shNuvr6+Hg4P3+/um0t+eYluenqZJz c+fW2G9SUddmZ/TW1vn5+cQ6R7unp5BPUtt0dPX19dJdYtjHyPns7MLCwlQ4NpqYmOjEyahqbfHF xdGaodV4g97c3Pz09MzMzOGAfvX7+8inqtFYW8tKUs2xs603R/Ly8tuBhuOKiMlDTO3z8vj//mc+ Pda2udqNl6ZETtq9wK2tre/b3aOjo96VnHtmZdvS09Ntef35+c5RV/rk4+66uvXr7KGFhd95eMOU mOGco/bg4b8tPd2kq+esseugnfH19cVmdqmfnuTP0dKEkOfo6NivtPPl571XZuTk5Lu1tNDCwuaQ jlhIRttvbvLNzu/AwLaxse2xr93f37CmpaEiMvv7+/vv77yEidHQ0Pr8/Pz29vLw8Pno6e7n6Mtf b3FfXUUwLnBwcHt6eu6rpsB0fO/49u3v7/b398bGxr67u8Gvrv38/LudntnY2GZmZv///////yH/ C05FVFNDQVBFMi4wAwEAAAAh+QQFAAB/ACwAAAAAyAAuAAAH/4B+goOEhYJpaWVlJUCGjo+QkZKT lJWWl5iZmpdCXWBNDCcnLzAMCxIKm6qrrK2ur6xAEmChRkZcXBEqQSsxKj9MJbDDxMXGx4N6s6Ba WjAnRhcRERm7MRQUQQuNyN3e3+B+ZUNNcnKgz7e41Lu9FEoHP0nh9PX2mEJN5eblQ15eQ7RMq9br mhIlAyh0ucewYcMkDBjoGyKhjB5CQBboyvDiRQZe7wYcGOKwpElkSZxpkSOBWwkhwgaFUHFBAZqb RB4sENHmSZWTQIOu0tPEyAk5ZQataVJqwQZBQ1Q0UDBhgh07GJw4oTMlARmhYMNOkqDlQpOYgkKI inaCCRhdSf8UkKmKwYWaOlOm+KiRRqzfv342DHm2phCYtdLYnUijoLGCGTNQ0KlTR8ONKIAzCw0x WI6hotFyUdPmJwkSHqiXLKGC40EKASA0yy65AcyQExIMMcAluloGHX6GwDtAXKSSFjcECHgwu7m9 Lg0WXJhXiMG0gSpWvGiExOCA79/HjFF+xLn5b0CGMPGC5GkhCf8AejkRo4EfMhskfEAixcqBAeIp B1sq5xVYzBoNdAEEgZLwoEJuZKDxGGQIfCBFC+MpZ0ECBnYIiw5I5MYgIRusscYGSdiwwg8K6DGX VXVtVYcPZihngAFZeKgjKxLwwEQITCRVSAYrFFlkffe9aIf/Cy7UgQACU1xxhAA35rHjlZqEwAMS DYxQ2JBGFhSXkks2CWUCYYRRxI0VPNLHm30QQEAfgsTpB5xxDIJAHwVg0EeeBMDhxw5wwLFDnW8C gMGdBAgy55+NEgKnooz6Meeded5pwqCFRopoH5Ti+eibo9KJp6VvwsGBnnz6CSgcl8Jp56ye3pmo rX0cmsYCWzbwwpeEqBDDsNf8EGFVV9WlxpNXJEACHyZY0EGbjhSwA58IXFpprgVwOAisBbyJgQcA 5ABHAQXAkcOdOYTbqJ2oZgtvne3Siqqtq/bBAQd9mICupPW+u0O3CIQ7cMHc3jkwh3Mi4IGg3xIQ bh/jAnCp/7XYblsrtxzGicCifnhhAxJIjPCTY6kEQcE170wlyGN1mRllGHyccUYR00Ki7Zzozrow IQB4QAAAfMZBQByHDpqnx/pWeq8fAGRaJwF75ttorFHfuW8fOYA8CNfhbsrx1F9HOvalHkgNtdBE F2D0znTWOfC8CheAgK3nCtKFDVuOIIQfKPuxAjbYKNHGCFIgcQoKKMjsbM0miNGBlY/ADee7tw6S Q9Cb58AnvLFmDnrc10oq+tWmcgCHCU1f2/TXop9e9qcAoPpmAYRs7kHnfMINO6mm5+pHAghk7YcE fCPxw98oK7DCQdD/990BSqwgRRTMJsBHASaY8AUNOVYet/+29hbCuqoPU4y0IDssncO1i44uiPH0 wl9prBwM/XrxEE9dtdNkC+C85pQAdRHifBxIHwZ8Rza60c0PnhOEEHjAN3kADmUUoN5wpAceAMFG A1MgQQHOYII75AACJNDZ+OLms3+xqg8JmFOezIUuAzJNbAtr2Jw2RrV+QQ0ABQBA7fTlJ30lwF/0 Y1e48jUw3AEQXtzCHdrUticYyvBp2tKYpDwlsTjUzg9p4A8P2jCP5sWAOMXpIIACJAALpECEJeQA FHowARU6ioWYe1MhCuWHcHmAfYVKmp3i8MdJPcpihRjkH4sHqrv50HP+ggOonPgpD8QPTgF0mqzu xTpvCYL/j37EYty0ODs/YIBoALibIBYgBR7EABVkiCUZFGAFNYpkjRmykQXwwD0O4MEDf8SSMC+R Ih5QAJayREMtO/gDHViBjTa6UREKcAc8EMABfBimNivBBBHc4ANUqcoElBmeMcxBDTPAgYCieSMH mCB/OSjCNucpiSp4cwloQJYdJvBM8bRAAzNwgRNqRKUb3YgGRTCBNePgA3o61BEKsAwV0HCVis4h QGM4AgookwALGPSgECBA/gg5ooeaNA0aYEOZmIQBKiRHQwnAyxQ04ICD0qAHOahmHHqgSpP69GUk QAAKknUVH7AgBSAQAAtk0JUr8KECAQgAFDhwByi4YQuUsfzpT6NgARAUIQB7YEEWNEACGezBABYo Qh5McAZ0jfCXbuhAB1al1br6AQce/ahebUoDCLjBDRCQ6xsgsCm72lUHDqDBXmnA2MYyVq6CjcMV DEtZDOQBAo7NbGMFO1gs2IGyoPUDAirQg8BCFrJvSO0W3NC10LoWcGeAQhEc0IPa9sCLUDjDRV77 WjKowQd4gIJwoYAHEqjhK7xNrnKXy9zmOve50I2udKdL3epaNzOBAAAh+QQFAAB/ACwAAAQACgAf AAAHwoB/goOCQF6EgyUScoh/ZV1djIRlIZVghGtDXl4SJYMKTQxeXUCEEhFNIZ6EWhkMSYinrmWI DEFBMKWJFxlGTHqEXSpIacCEQzENf36IDUoRL2DMgzxKFEowCoN+L9YU2YQ2B9cv2tNIA0oHL8DT TAfwI+aCH0oDAyPGghsU9z/6gn7ca5PGjzZBXg4MIGiQkJWFG/4A/DDmSRIFAPXMAVFFARlEVaLY QTMBAyI/RDAomNCICAsWZhr9SZJCpiAMRQIBACH5BAUAAH8ALAQAAgAKACMAAAfTgH+Cg38Ka4SC CmUSXYgbEpAShEJNXpGDSQxaIRJJh39JWjCbZXqCZVpGJ3KIDVxGTSWIXBcnn4QRXGCIghERkrwq KreIMGW8yIgKyX88srwUKsfIGdOIFEEbhX7cgkor2grcfoPg2+N/BzFEiOR/FMR/7gM6CmQK+H5t f/T2+OJ/xgz48GcCGT163I2hgsYgmXuCxtRAY8fgBDSCarCx42KCRzQsCpFAgAINGjIYBUWxYIGF higPNAzCYaDInpsWCD3Ic3MPBERkHlTYkwyDjz+BAAAh+QQFAAB/ACwIAAEACgAmAAAH84B/goMl QhKDf0ASEl1eC4J6EmBNIV0hXn9lQ01ycl2WQ4KcnV0SSUl/DE1NQxJpCohyEkCCQCW0mYSWIYiC SV6OvX8SwI+9XUNeYMLIQ8vHC0NMGb1rp6jC2YIl3GnCYA0NSMJM4eOICuXiggrtf+JIPOzu8PJ/ 7e1LSEg2vQrxPPqh48dDiiAyCNEwsWHD4B+ECBc2FDShIhmJDifYsTNhoQiHG+1gwHFExBFBLlJi eJBChBlBGzFgmMDmQZQ/IIoE2MMiwRU1E/5YMEDUwM49e/7ocECD6NEAgjDkgUDjKSIEFbJCgSps ig882RRMmPInEAAh+QQFAAB/ACwMAAAACgAnAAAH/4B/goJ6emklg0JdC11dIUyCYAwnJ0OWDYIM WlowXpcZf00MMDCWQw2gTXJDIUlJXU2gZXqDf35dgyVCiLV/a00wTRK8giGUlV46uH9gJ0aVCwtN QaFG1kPRSCt/DFxcFwtgCwwq3BERXGDiWiN/El5erUleWr2DXUiCG2trG2UhDRaQ+ZNhxYogDRog kSCo4EGFSDbYUhEjxgqFCxQMDEKBQgwkPCT4EbSi40ceC5i8+LNCiRIKPGL+EEThgMuYPNr9iXHA po2fMxVYGTDgwE8b7dAMLWpDypAqf5QSNYpjggJBVsaMaSGCjQI7f+zM0driSBQ0GBD8oXJDgIAj KU/UYAhrxweLFDWOPJj7J4sGEjJ87MFb4Y+Bwxb2KC4i6LABCIorMP5DozLkPWKKdPjTA0IHGlBC F3kj6AyUIni+YIHiRhAZNXxInPFxx0MgACH5BAUAAH8ALA8AAAALACcAAAf/gH9/aWllZUB6goJg TQwnMCEhXV2CRkZcERdgDUwvQYInl0YLTGAvFH+hXFyjYKYxf15eQ1qtpqiKJSGkCw0jiopCYEN+ ggwLG4I6TBKKRhcnDV69ZaDPEZlMXomCF5gZF8x/QoKYESpcyMDYGSoRIYlMqLNeRhnNCiWUijwR 1QoKZghKYmPFDz8Aua1YGKPBH4BkBDGMkQShnoh/YsSg8EMPQAUTMlKgoKSBAkEIBY1U0kbKhy46 qtj5o6TmACU2pPD4gevAgQEUeNiw0UaQzwE3hfJ4IggpUgpDRTwZ88fpjz9UbIiYI2jMmDlqZugQ sbVrCw0zXEzQsFXAHwFjZY7QqTNBDQsQigRYSOACAwY2ARSBEJBChou+CRTtMWAhAIkrCBL/MUDZ AIQKYioUgTCZhufLeyo4EOT5cwUoYuK8+dOhdQcIUDxAidNBkIMePeJgwZOFg4k/PvBAQX2GRB0M fwIBACH5BAUAAH8ALBMAAAALACcAAAf/gH9/JUCChoYnLzAMXmV+hlwRKkExEQtDEoUXEREZQRdM SA0vTH+Rnj9MDQ1tgpyeXKGsB0ALkio8IUwLP4YhKhcKwgqHQyoNfnrKE39MYJJJfwrKdoIZKidp f37crp4Lf2Vd46HXGTp/OjzrQQN/Ky9AQENLSEhBfycxDX9kZWtJJCARpEJCP2nCDk0jQ0YPmQkY Dj2c4BCiIQUT9Uyw2A/Nxn4bXRySNmOiyD8jpCBZoEPBjAkiDwyYOSAIkw9s1PyRSTMGDxsijmT5 Q3PAChFIrQjYOWDMGCtIRYBYqsOKU6giUoAwhEPA0xR7tBpyYkYACLApHPxB8adOAgsWYdA66NB2 ypShFfbsceCGxZ8pCRJc4aPhDBZBRfKYOEOizhQEJgQZoEHZAZYvX3q8+UOZRoceYqCI6SGocwc3 oaEAyPGnQ4c3byDk+FKA2Z8ePeIA+IKAmCEoUPCQcOFbUCAAIfkEBQAAfwAsFwABAAwAJgAAB/+A fwsSCn+Gh4YrMSo/TCWIhipBMRRKf0mFh5KKSj9IQ2WaijGdSDZIOoYZLy8ZKyMNPDwxC4doaCgY azoSI22GChMTdn9oZGiQZMPCwwiICtDQM2gyh0lIPDaDEjofPoZDSgcDGaY8K4Z+SJQHGTxSNi2H GxIfPEsL2fKGyDMzfxiqdLFySJgdDH8moJjwwBCZhHZc/LFz0NkhihIpYphy8aALDB6n8DmEwYWa iS5cXDkkAQWKjCmvFPhzQMkKKVE+pgxzaMCAMWP+IHCihsQhoEBBpPDhYqShMQKi/kmRIgGfO4ai Sk2xJwsfDn+0CjDwp0LXM4fGGiBrNssZAoZb1q4tWyGMCUMaHKzt8AdPgStg/1zhUyFAEcEy4/z5 VqCxiTMmvohxg8cQBDdutjgQ4yEHn0I0aHTo8AYOFDwnDYkm/SbOlYeI3mxxkwMhpD9Qzui5fUgN bN6BAAAh+QQFAAB/ACwbAAMACwAhAAAH/4AUQQtAf4aHfxRKBz9JiIaKSgMUEo9BK4oDP0KIaEQP CzZICyWIdhhOTihOagqGExguagguGFM6eoYzMyh0GHZXS448PEtLVA91DyJmfwfPAwMjSyIiFn+S 0QNPIkciN39IUlYH29UiiAgfUlLnBoYuTnR1bDjV138udQhTLi4a1uDtm1JHnwYLHf7MQnAFwT4E AvklcIgAoqGBCabwm5LDUMUrYTROuYLljwAQGqbwmTLyyheTAiykIHGlpRhDAgxYwMMyQYJDBoIW GZmABABDQQ04SHCFRAEProLSKHKlKJ6ffwzQgICFTwI8JgzRoNEjx50CeL7YMRQACoc7HiKgiLH4 5wweD246AJiCCEKHDm8gFPCD6O+bOFceGeK6VnEgACH5BAUAAH8ALB8ABQAIAB0AAAeygH9df4SF fwdDhn8ibU9VinRTCWSFdVNTPjVplXUaNzqFOA8pAkuEB0otNwJHaoQDY2MCZlGEsQKzNYQtsrMp rj5muAF7OghTV0ezew9/CWFhRcQ+ziR8JikBPldhfGdnHNp/1mcmZ3skCXwFJncFYgkkBeUcZxV1 f+x3HCZYevkmOBDgR6jAHTwECBAhFJCAGA5+GCKMQ4LQQAJxPBjCE6cHgkJQ3GwpoKgDB0V/TKAM BAAh+QQF6AN/ACwjAAoABAATAAAHPoB/UX+EIIR/Ag+EAkeLhogWCX8GBlmTBnmXFX8WHZtFnn9i HXkmXzRZdzkQJH9QPRN4Hh6EDnx/OUWHPoSBADs= --_004_4B18A8F75A6384449755BC7784073E935F6AB05D39exch11olympus_-- --===============0650081477== 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 --===============0650081477==-- From ipsec-bounces@ietf.org Mon Nov 17 23:52: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 0C22528C1D0; Mon, 17 Nov 2008 23:52:08 -0800 (PST) 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 E420728C0D0 for ; Mon, 17 Nov 2008 23:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[AWL=-1.211, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] 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 Ijru7WdC18e7 for ; Mon, 17 Nov 2008 23:38:46 -0800 (PST) Received: from mail.f5.com (mail.f5.com [65.197.145.96]) by core3.amsl.com (Postfix) with ESMTP id 06CBA3A6A4C for ; Mon, 17 Nov 2008 23:38:46 -0800 (PST) Received: from exch11.olympus.f5net.com ([192.168.16.104]) by e2k7ca1.olympus.f5net.com ([192.168.16.101]) with mapi; Mon, 17 Nov 2008 23:38:44 -0800 From: James Goodwin To: "ipsec@ietf.org" Date: Mon, 17 Nov 2008 23:38:42 -0800 Thread-Topic: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-00.txt Thread-Index: AclJUK5aADx+lUBaRNqUVQqA4N1m2g== Message-ID: <4B18A8F75A6384449755BC7784073E935F6AB05D35@exch11.olympus.f5net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Jeff Bellamy , Amit Jain , Ryan Korock Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-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="===============0301313527==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0301313527== Content-Language: en-US Content-Type: multipart/related; boundary="_004_4B18A8F75A6384449755BC7784073E935F6AB05D35exch11olympus_"; type="multipart/alternative" --_004_4B18A8F75A6384449755BC7784073E935F6AB05D35exch11olympus_ Content-Type: multipart/alternative; boundary="_000_4B18A8F75A6384449755BC7784073E935F6AB05D35exch11olympus_" --_000_4B18A8F75A6384449755BC7784073E935F6AB05D35exch11olympus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As a follow-up to other comments on the Wrapped ESP for Traffic Visibility = draft, I'd like to add a quick note. I have reviewed this IETF draft, and does appear to be a reasonable solutio= n to the problem of intermediate devices determining on a per-packet basis = whether the ESP data payload is encrypted or clear-text (for network monito= ring and deep packet inspection). It overcomes the original problem of ESP = not providing an integrity-only flag. This, IMHO, is a cleaner solution than a heuristics based approach (pattern= matching to determine if payload is encrypted). The data in the defined XE= SP will allow our traffic management OS (TMOS) to easily determine whether = the data payload is encrypted, inspect, and apply traffic management rules = based on content in the data payload. This will be possible with fairly str= aight-forward software changes (and may be supported to some degree via bui= lt-in rules language - no code changes necessary). A couple questions/concerns: - Why not include an "integrity-only" bit in the header (flags oct= et) so that the wrapper may be used to handle both integrity-only and encry= ption + integrity modes for ESP? I believe Yaron has also asked this questi= on. - How much change to silicon (cost to chip vendors) is required to= support the additional XESP header and new protocol number? This must be w= idely supported by IPSec silicon vendors for this proposal to succeed. Thanks, --James James Goodwin | Sr. Director, Product Development F5 Networks t: 408.273.4821 www.f5.com c: 408.421.6956 [cid:image001.gif@01C9490C.E0D0DF30] --_000_4B18A8F75A6384449755BC7784073E935F6AB05D35exch11olympus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

As a follow-up to other comments on the Wrapped ESP fo= r Traffic Visibility draft, I’d like to add a quick note.

 

I have reviewed this IETF draft, and does appear to be= a reasonable solution to the problem of intermediate devices determining on a per-packet basis whether the ESP data payload is encrypted or clear-text (f= or network monitoring and deep packet inspection). It overcomes the original problem of ESP not providing an integrity-only flag.

 

This, IMHO, is a cleaner solution than a heuristics ba= sed approach (pattern matching to determine if payload is encrypted). The data = in the defined XESP will allow our traffic management OS (TMOS) to easily determin= e whether the data payload is encrypted, inspect, and apply traffic managemen= t rules based on content in the data payload. This will be possible with fair= ly straight-forward software changes (and may be supported to some degree via = built-in rules language – no code changes necessary).

 

A couple questions/concerns:

-&nb= sp;         Why not include an “integrity-only” bit= in the header (flags octet) so that the wrapper may be used to handle both integrity-only and encryption + integrity modes for ESP? I believe Yaron ha= s also asked this question.

-&nb= sp;         How much change to silicon (cost to chip vendors) i= s required to support the additional XESP header and new protocol number? Thi= s must be widely supported by IPSec silicon vendors for this proposal to succ= eed.

 

Thanks,

--James

 

James Goodwin | Sr. Director, Product Development

 

F5 Networks 

t: 408.273.4821

 =

www.f5.com 

c: 408.421.6956

 

3D"cid:image001.gif@01C8F717.E4DD0E60"

 

 

 

 

 

=  

=  

 

 

 

--_000_4B18A8F75A6384449755BC7784073E935F6AB05D35exch11olympus_-- --_004_4B18A8F75A6384449755BC7784073E935F6AB05D35exch11olympus_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=4931; creation-date="Mon, 17 Nov 2008 23:38:43 GMT"; modification-date="Mon, 17 Nov 2008 23:38:43 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhyAAuAOZ/AIqJia6SkpIwOLQUL7i4uNbW1nk6O7shNuvr6+Hg4P3+/um0t+eYluenqZJz c+fW2G9SUddmZ/TW1vn5+cQ6R7unp5BPUtt0dPX19dJdYtjHyPns7MLCwlQ4NpqYmOjEyahqbfHF xdGaodV4g97c3Pz09MzMzOGAfvX7+8inqtFYW8tKUs2xs603R/Ly8tuBhuOKiMlDTO3z8vj//mc+ Pda2udqNl6ZETtq9wK2tre/b3aOjo96VnHtmZdvS09Ntef35+c5RV/rk4+66uvXr7KGFhd95eMOU mOGco/bg4b8tPd2kq+esseugnfH19cVmdqmfnuTP0dKEkOfo6NivtPPl571XZuTk5Lu1tNDCwuaQ jlhIRttvbvLNzu/AwLaxse2xr93f37CmpaEiMvv7+/vv77yEidHQ0Pr8/Pz29vLw8Pno6e7n6Mtf b3FfXUUwLnBwcHt6eu6rpsB0fO/49u3v7/b398bGxr67u8Gvrv38/LudntnY2GZmZv///////yH/ C05FVFNDQVBFMi4wAwEAAAAh+QQFAAB/ACwAAAAAyAAuAAAH/4B+goOEhYJpaWVlJUCGjo+QkZKT lJWWl5iZmpdCXWBNDCcnLzAMCxIKm6qrrK2ur6xAEmChRkZcXBEqQSsxKj9MJbDDxMXGx4N6s6Ba WjAnRhcRERm7MRQUQQuNyN3e3+B+ZUNNcnKgz7e41Lu9FEoHP0nh9PX2mEJN5eblQ15eQ7RMq9br mhIlAyh0ucewYcMkDBjoGyKhjB5CQBboyvDiRQZe7wYcGOKwpElkSZxpkSOBWwkhwgaFUHFBAZqb RB4sENHmSZWTQIOu0tPEyAk5ZQataVJqwQZBQ1Q0UDBhgh07GJw4oTMlARmhYMNOkqDlQpOYgkKI inaCCRhdSf8UkKmKwYWaOlOm+KiRRqzfv342DHm2phCYtdLYnUijoLGCGTNQ0KlTR8ONKIAzCw0x WI6hotFyUdPmJwkSHqiXLKGC40EKASA0yy65AcyQExIMMcAluloGHX6GwDtAXKSSFjcECHgwu7m9 Lg0WXJhXiMG0gSpWvGiExOCA79/HjFF+xLn5b0CGMPGC5GkhCf8AejkRo4EfMhskfEAixcqBAeIp B1sq5xVYzBoNdAEEgZLwoEJuZKDxGGQIfCBFC+MpZ0ECBnYIiw5I5MYgIRusscYGSdiwwg8K6DGX VXVtVYcPZihngAFZeKgjKxLwwEQITCRVSAYrFFlkffe9aIf/Cy7UgQACU1xxhAA35rHjlZqEwAMS DYxQ2JBGFhSXkks2CWUCYYRRxI0VPNLHm30QQEAfgsTpB5xxDIJAHwVg0EeeBMDhxw5wwLFDnW8C gMGdBAgy55+NEgKnooz6Meeded5pwqCFRopoH5Ti+eibo9KJp6VvwsGBnnz6CSgcl8Jp56ye3pmo rX0cmsYCWzbwwpeEqBDDsNf8EGFVV9WlxpNXJEACHyZY0EGbjhSwA58IXFpprgVwOAisBbyJgQcA 5ABHAQXAkcOdOYTbqJ2oZgtvne3Siqqtq/bBAQd9mICupPW+u0O3CIQ7cMHc3jkwh3Mi4IGg3xIQ bh/jAnCp/7XYblsrtxzGicCifnhhAxJIjPCTY6kEQcE170wlyGN1mRllGHyccUYR00Ki7Zzozrow IQB4QAAAfMZBQByHDpqnx/pWeq8fAGRaJwF75ttorFHfuW8fOYA8CNfhbsrx1F9HOvalHkgNtdBE F2D0znTWOfC8CheAgK3nCtKFDVuOIIQfKPuxAjbYKNHGCFIgcQoKKMjsbM0miNGBlY/ADee7tw6S Q9Cb58AnvLFmDnrc10oq+tWmcgCHCU1f2/TXop9e9qcAoPpmAYRs7kHnfMINO6mm5+pHAghk7YcE fCPxw98oK7DCQdD/990BSqwgRRTMJsBHASaY8AUNOVYet/+29hbCuqoPU4y0IDssncO1i44uiPH0 wl9prBwM/XrxEE9dtdNkC+C85pQAdRHifBxIHwZ8Rza60c0PnhOEEHjAN3kADmUUoN5wpAceAMFG A1MgQQHOYII75AACJNDZ+OLms3+xqg8JmFOezIUuAzJNbAtr2Jw2RrV+QQ0ABQBA7fTlJ30lwF/0 Y1e48jUw3AEQXtzCHdrUticYyvBp2tKYpDwlsTjUzg9p4A8P2jCP5sWAOMXpIIACJAALpECEJeQA FHowARU6ioWYe1MhCuWHcHmAfYVKmp3i8MdJPcpihRjkH4sHqrv50HP+ggOonPgpD8QPTgF0mqzu xTpvCYL/j37EYty0ODs/YIBoALibIBYgBR7EABVkiCUZFGAFNYpkjRmykQXwwD0O4MEDf8SSMC+R Ih5QAJayREMtO/gDHViBjTa6UREKcAc8EMABfBimNivBBBHc4ANUqcoElBmeMcxBDTPAgYCieSMH mCB/OSjCNucpiSp4cwloQJYdJvBM8bRAAzNwgRNqRKUb3YgGRTCBNePgA3o61BEKsAwV0HCVis4h QGM4AgookwALGPSgECBA/gg5ooeaNA0aYEOZmIQBKiRHQwnAyxQ04ICD0qAHOahmHHqgSpP69GUk QAAKknUVH7AgBSAQAAtk0JUr8KECAQgAFDhwByi4YQuUsfzpT6NgARAUIQB7YEEWNEACGezBABYo Qh5McAZ0jfCXbuhAB1al1br6AQce/ahebUoDCLjBDRCQ6xsgsCm72lUHDqDBXmnA2MYyVq6CjcMV DEtZDOQBAo7NbGMFO1gs2IGyoPUDAirQg8BCFrJvSO0W3NC10LoWcGeAQhEc0IPa9sCLUDjDRV77 WjKowQd4gIJwoYAHEqjhK7xNrnKXy9zmOve50I2udKdL3epaNzOBAAAh+QQFAAB/ACwAAAQACgAf AAAHwoB/goOCQF6EgyUScoh/ZV1djIRlIZVghGtDXl4SJYMKTQxeXUCEEhFNIZ6EWhkMSYinrmWI DEFBMKWJFxlGTHqEXSpIacCEQzENf36IDUoRL2DMgzxKFEowCoN+L9YU2YQ2B9cv2tNIA0oHL8DT TAfwI+aCH0oDAyPGghsU9z/6gn7ca5PGjzZBXg4MIGiQkJWFG/4A/DDmSRIFAPXMAVFFARlEVaLY QTMBAyI/RDAomNCICAsWZhr9SZJCpiAMRQIBACH5BAUAAH8ALAQAAgAKACMAAAfTgH+Cg38Ka4SC CmUSXYgbEpAShEJNXpGDSQxaIRJJh39JWjCbZXqCZVpGJ3KIDVxGTSWIXBcnn4QRXGCIghERkrwq KreIMGW8yIgKyX88srwUKsfIGdOIFEEbhX7cgkor2grcfoPg2+N/BzFEiOR/FMR/7gM6CmQK+H5t f/T2+OJ/xgz48GcCGT163I2hgsYgmXuCxtRAY8fgBDSCarCx42KCRzQsCpFAgAINGjIYBUWxYIGF higPNAzCYaDInpsWCD3Ic3MPBERkHlTYkwyDjz+BAAAh+QQFAAB/ACwIAAEACgAmAAAH84B/goMl QhKDf0ASEl1eC4J6EmBNIV0hXn9lQ01ycl2WQ4KcnV0SSUl/DE1NQxJpCohyEkCCQCW0mYSWIYiC SV6OvX8SwI+9XUNeYMLIQ8vHC0NMGb1rp6jC2YIl3GnCYA0NSMJM4eOICuXiggrtf+JIPOzu8PJ/ 7e1LSEg2vQrxPPqh48dDiiAyCNEwsWHD4B+ECBc2FDShIhmJDifYsTNhoQiHG+1gwHFExBFBLlJi eJBChBlBGzFgmMDmQZQ/IIoE2MMiwRU1E/5YMEDUwM49e/7ocECD6NEAgjDkgUDjKSIEFbJCgSps ig882RRMmPInEAAh+QQFAAB/ACwMAAAACgAnAAAH/4B/goJ6emklg0JdC11dIUyCYAwnJ0OWDYIM WlowXpcZf00MMDCWQw2gTXJDIUlJXU2gZXqDf35dgyVCiLV/a00wTRK8giGUlV46uH9gJ0aVCwtN QaFG1kPRSCt/DFxcFwtgCwwq3BERXGDiWiN/El5erUleWr2DXUiCG2trG2UhDRaQ+ZNhxYogDRog kSCo4EGFSDbYUhEjxgqFCxQMDEKBQgwkPCT4EbSi40ceC5i8+LNCiRIKPGL+EEThgMuYPNr9iXHA po2fMxVYGTDgwE8b7dAMLWpDypAqf5QSNYpjggJBVsaMaSGCjQI7f+zM0driSBQ0GBD8oXJDgIAj KU/UYAhrxweLFDWOPJj7J4sGEjJ87MFb4Y+Bwxb2KC4i6LABCIorMP5DozLkPWKKdPjTA0IHGlBC F3kj6AyUIni+YIHiRhAZNXxInPFxx0MgACH5BAUAAH8ALA8AAAALACcAAAf/gH9/aWllZUB6goJg TQwnMCEhXV2CRkZcERdgDUwvQYInl0YLTGAvFH+hXFyjYKYxf15eQ1qtpqiKJSGkCw0jiopCYEN+ ggwLG4I6TBKKRhcnDV69ZaDPEZlMXomCF5gZF8x/QoKYESpcyMDYGSoRIYlMqLNeRhnNCiWUijwR 1QoKZghKYmPFDz8Aua1YGKPBH4BkBDGMkQShnoh/YsSg8EMPQAUTMlKgoKSBAkEIBY1U0kbKhy46 qtj5o6TmACU2pPD4gevAgQEUeNiw0UaQzwE3hfJ4IggpUgpDRTwZ88fpjz9UbIiYI2jMmDlqZugQ sbVrCw0zXEzQsFXAHwFjZY7QqTNBDQsQigRYSOACAwY2ARSBEJBChou+CRTtMWAhAIkrCBL/MUDZ AIQKYioUgTCZhufLeyo4EOT5cwUoYuK8+dOhdQcIUDxAidNBkIMePeJgwZOFg4k/PvBAQX2GRB0M fwIBACH5BAUAAH8ALBMAAAALACcAAAf/gH9/JUCChoYnLzAMXmV+hlwRKkExEQtDEoUXEREZQRdM SA0vTH+Rnj9MDQ1tgpyeXKGsB0ALkio8IUwLP4YhKhcKwgqHQyoNfnrKE39MYJJJfwrKdoIZKidp f37crp4Lf2Vd46HXGTp/OjzrQQN/Ky9AQENLSEhBfycxDX9kZWtJJCARpEJCP2nCDk0jQ0YPmQkY Dj2c4BCiIQUT9Uyw2A/Nxn4bXRySNmOiyD8jpCBZoEPBjAkiDwyYOSAIkw9s1PyRSTMGDxsijmT5 Q3PAChFIrQjYOWDMGCtIRYBYqsOKU6giUoAwhEPA0xR7tBpyYkYACLApHPxB8adOAgsWYdA66NB2 ypShFfbsceCGxZ8pCRJc4aPhDBZBRfKYOEOizhQEJgQZoEHZAZYvX3q8+UOZRoceYqCI6SGocwc3 oaEAyPGnQ4c3byDk+FKA2Z8ePeIA+IKAmCEoUPCQcOFbUCAAIfkEBQAAfwAsFwABAAwAJgAAB/+A fwsSCn+Gh4YrMSo/TCWIhipBMRRKf0mFh5KKSj9IQ2WaijGdSDZIOoYZLy8ZKyMNPDwxC4doaCgY azoSI22GChMTdn9oZGiQZMPCwwiICtDQM2gyh0lIPDaDEjofPoZDSgcDGaY8K4Z+SJQHGTxSNi2H GxIfPEsL2fKGyDMzfxiqdLFySJgdDH8moJjwwBCZhHZc/LFz0NkhihIpYphy8aALDB6n8DmEwYWa iS5cXDkkAQWKjCmvFPhzQMkKKVE+pgxzaMCAMWP+IHCihsQhoEBBpPDhYqShMQKi/kmRIgGfO4ai Sk2xJwsfDn+0CjDwp0LXM4fGGiBrNssZAoZb1q4tWyGMCUMaHKzt8AdPgStg/1zhUyFAEcEy4/z5 VqCxiTMmvohxg8cQBDdutjgQ4yEHn0I0aHTo8AYOFDwnDYkm/SbOlYeI3mxxkwMhpD9Qzui5fUgN bN6BAAAh+QQFAAB/ACwbAAMACwAhAAAH/4AUQQtAf4aHfxRKBz9JiIaKSgMUEo9BK4oDP0KIaEQP CzZICyWIdhhOTihOagqGExguagguGFM6eoYzMyh0GHZXS448PEtLVA91DyJmfwfPAwMjSyIiFn+S 0QNPIkciN39IUlYH29UiiAgfUlLnBoYuTnR1bDjV138udQhTLi4a1uDtm1JHnwYLHf7MQnAFwT4E AvklcIgAoqGBCabwm5LDUMUrYTROuYLljwAQGqbwmTLyyheTAiykIHGlpRhDAgxYwMMyQYJDBoIW GZmABABDQQ04SHCFRAEProLSKHKlKJ6ffwzQgICFTwI8JgzRoNEjx50CeL7YMRQACoc7HiKgiLH4 5wweD246AJiCCEKHDm8gFPCD6O+bOFceGeK6VnEgACH5BAUAAH8ALB8ABQAIAB0AAAeygH9df4SF fwdDhn8ibU9VinRTCWSFdVNTPjVplXUaNzqFOA8pAkuEB0otNwJHaoQDY2MCZlGEsQKzNYQtsrMp rj5muAF7OghTV0ezew9/CWFhRcQ+ziR8JikBPldhfGdnHNp/1mcmZ3skCXwFJncFYgkkBeUcZxV1 f+x3HCZYevkmOBDgR6jAHTwECBAhFJCAGA5+GCKMQ4LQQAJxPBjCE6cHgkJQ3GwpoKgDB0V/TKAM BAAh+QQF6AN/ACwjAAoABAATAAAHPoB/UX+EIIR/Ag+EAkeLhogWCX8GBlmTBnmXFX8WHZtFnn9i HXkmXzRZdzkQJH9QPRN4Hh6EDnx/OUWHPoSBADs= --_004_4B18A8F75A6384449755BC7784073E935F6AB05D35exch11olympus_-- --===============0301313527== 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 --===============0301313527==-- From ipsec-bounces@ietf.org Tue Nov 18 00:36: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 913103A6AA9; Tue, 18 Nov 2008 00:36:35 -0800 (PST) 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 D95B63A6AA9 for ; Tue, 18 Nov 2008 00:36:34 -0800 (PST) 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 MGtKN--SteaT for ; Tue, 18 Nov 2008 00:36:34 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id A28F53A67EF for ; Tue, 18 Nov 2008 00:36:33 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 20A0B294005; Tue, 18 Nov 2008 10:36:32 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 14EB2294003; Tue, 18 Nov 2008 10:36:31 +0200 (IST) 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 mAI8aUQC015211; Tue, 18 Nov 2008 10:36:30 +0200 (IST) Message-Id: <3EB07ACE-3428-4C63-BA7A-9DC1F9A5A296@checkpoint.com> From: Yoav Nir To: James Goodwin In-Reply-To: <4B18A8F75A6384449755BC7784073E935F6AB05D35@exch11.olympus.f5net.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 18 Nov 2008 10:36:30 +0200 References: <4B18A8F75A6384449755BC7784073E935F6AB05D35@exch11.olympus.f5net.com> X-Mailer: Apple Mail (2.929.2) Cc: "ipsec@ietf.org" , Jeff Bellamy , Ryan Korock , Amit Jain Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-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="===============1489592819==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1489592819== Content-Type: multipart/alternative; boundary=Apple-Mail-3--417912891 --Apple-Mail-3--417912891 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi James, On Nov 18, 2008, at 9:38 AM, James Goodwin wrote: > A couple questions/concerns: > - Why not include an =93integrity-only=94 bit in the header =20= > (flags octet) so that the wrapper may be used to handle both =20 > integrity-only and encryption + integrity modes for ESP? I believe =20 > Yaron has also asked this question. At the previous IETF meeting, there was considerable opposition to the =20= idea of making a "next-generation" ESP. Some participants did not want =20= this extension to affect encrypted traffic. For one reason, see below > - How much change to silicon (cost to chip vendors) is =20 > required to support the additional XESP header and new protocol =20 > number? This must be widely supported by IPSec silicon vendors for =20 > this proposal to succeed. It's not a lot of change to silicon, and the chip vendors should have =20= no problem doing this for the next release. The problem is with =20 already deployed devices such as routers and firewalls, that would not =20= recognize this new protocol. Support can still be added with software =20= or rulebase, but it does mean that such traffic may go on the slow =20 path on intermediary devices. That is one reason why some participants =20= don't want a "new ESP" --Apple-Mail-3--417912891 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi James,

On = Nov 18, 2008, at 9:38 AM, James Goodwin wrote:
A couple = questions/concerns:
          Why not = include an =93integrity-only=94 bit in the header (flags octet) so that = the wrapper may be used to handle both integrity-only and encryption + = integrity modes for ESP? I believe Yaron has also asked this = question.

At the = previous IETF meeting, there was considerable opposition to the idea of = making a "next-generation" ESP. Some participants did not want this = extension to affect encrypted traffic.  For one reason, see = below

          How much = change to silicon (cost to chip vendors) is required to support the = additional XESP header and new protocol number? This must be widely = supported by IPSec silicon vendors for this proposal to = succeed.

It's not a = lot of change to silicon, and the chip vendors should have no problem = doing this for the next release. The problem is with already deployed = devices such as routers and firewalls, that would not recognize this new = protocol. Support can still be added with software or rulebase, but it = does mean that such traffic may go on the slow path on intermediary = devices. That is one reason why some participants don't want a "new = ESP"

= --Apple-Mail-3--417912891-- --===============1489592819== 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 --===============1489592819==-- From ipsec-bounces@ietf.org Tue Nov 18 00:52:25 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 D874A3A6AB7; Tue, 18 Nov 2008 00:52:25 -0800 (PST) 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 5B4ED3A6AB7 for ; Tue, 18 Nov 2008 00:52:25 -0800 (PST) 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 VPV6MOBkggAu for ; Tue, 18 Nov 2008 00:52:24 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 3B3143A6AB4 for ; Tue, 18 Nov 2008 00:52:24 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 17FD4294005; Tue, 18 Nov 2008 10:52:23 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 2B05A294003; Tue, 18 Nov 2008 10:52:22 +0200 (IST) 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 mAI8qLQC020667; Tue, 18 Nov 2008 10:52:21 +0200 (IST) Message-Id: <7C69DECB-BB75-43BA-ABED-6DB5DB648791@checkpoint.com> From: Yoav Nir To: Hui Deng In-Reply-To: <1d38a3350811172207m1801bf77ra4518f06deb61207@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 18 Nov 2008 10:52:20 +0200 References: <1d38a3350811172207m1801bf77ra4518f06deb61207@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-resumption-00.txt ticket location 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 Hui, On Nov 18, 2008, at 8:07 AM, Hui Deng wrote: > Hello, authors, > > After reading your draft and rethinking of the main issues, I would > like to raise one issue about ticket location issue: > there have two problems on sending tickets with all the information > to the client > > a) If the session resumption solution is deployed in mobile network, > it will consume a lot of air-interface cost to request/present/update > the ticket. As the mobile operators, we prefer not do that. The draft does not specify the ticket format. This could be very compact, down to 16-24 bytes, including notification payload header. > b) As discussed in the list, the packet to send the ticket may be > fragmented. When session resumption happened, a large number of the > client may try to present the ticket at the same time. In this case, a > bunch of fragmented IP packets will be sent to the gateway. Some > equipments (such as mobile network GW, firewalls, etc) between clients > and gateway may be overloaded to handle the IP fragment. And, some > equipments may treat it as DoS attack and simply drop all the > fragmented packets. the most important issue, the wireless base > station > will be chunked and died. I understand that resumption may have severe implications for the core network - lots of simultaneous IKE traffic, but aren't the clients supposed to be spread out among very many base stations? I didn't think there should be congestion at the base stations. > > thanks for your consideration. under this consideration, we would > like to > recommend the solution which could store the ticket information > purely on > the network side. > thanks for your consideration. The "ticket" could be a 64- or 128-bit index into a database table, giving a total payload size of 16 or 24 bytes respectively. I believe a payload this small should not overload the "air". Does a solution such as this address your concerns? Hope this helps Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 18 04:30: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 84A3E28C176; Tue, 18 Nov 2008 04:30:41 -0800 (PST) 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 6E17E28C176 for ; Tue, 18 Nov 2008 04:30:40 -0800 (PST) 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 GyFT50ak3xfY for ; Tue, 18 Nov 2008 04:30:39 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 9919928C10B for ; Tue, 18 Nov 2008 04:30:39 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so3259222wfd.31 for ; Tue, 18 Nov 2008 04:30:39 -0800 (PST) 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:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=wMlHaJHMfyR4BCVB/dyjCPJUPx0GQ0TnU+yyF0TtwsA=; b=uZK5o/EBPjtcjYeozPIafSIy78rRdSP0azyJ5eDIAXw5ZS/rOABlCR4W0LnSTZYGAe 5eT2w+Y26VmPy2lcZMUq70iMgdTJfomtlcZjZQCuRNLDM/g2ZnpiITCcGIifmPITFY/1 kz816O5Ah29Ap/roKt6TxNGbPnhi60wm9oEsQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=QD+cT7XTF/VaJdDZHwb3Z19e+Cbe1VqpwHfZB3zMTBHZpA3TqQRYKUc0kKHoIdrhaZ yGzPJOQmoz0jq/640JJQcx6wggtNAQ1utGovFJebo+JJFNDPcxCxeeuHcjeBHnGRVRG5 2mFQL6SusHtHDmHTPGvJ0LrtA4OaZFF4XQX6E= Received: by 10.143.155.7 with SMTP id h7mr2570027wfo.153.1227011439160; Tue, 18 Nov 2008 04:30:39 -0800 (PST) Received: by 10.142.211.4 with HTTP; Tue, 18 Nov 2008 04:30:39 -0800 (PST) Message-ID: <4c5c7a6d0811180430v1eebd5f4v4aa8072b3ad9b309@mail.gmail.com> Date: Tue, 18 Nov 2008 20:30:39 +0800 From: "Peny Yang" To: ipsec@ietf.org In-Reply-To: <4c5c7a6d0811172219j96ce787qd265ded48f4c60b6@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <4c5c7a6d0811172219j96ce787qd265ded48f4c60b6@mail.gmail.com> Subject: [IPsec] Comment on draft-ietf-ipsecme-ikev2-resumption-00 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 just went through the updated WG draft and RFC5077 as well. In the draft, the new IKE_SESSION_RESUME is defined to present ticket from client gateway for session resumption. However, this need to modify IKEv2 base protocol by new messages and related protection of them. From the implementation point of view, we do not think this modification is small. And, when we consider the case that the session resumption can not be continued by the gateway, gateway will reject this message. Then, the regular IKEv2 procedure will be done afterwards. In this case, at least one round trip is wasted. Also, I checked RFC 5077 as a reference indicated in the charter. It just added a SessionTicket extension to the ClientHello message for ticket presenting from client during session resumption. Solution: Add a payload in the IKE INIT message for client to present the index of ticket to GW. Then if GW can not do the session resumption for some reason, it just sends the IKE INIT response to clients and starts the regular IKEv2 initiation procedure. IMHO, this way is more efficient and flexible. Peny _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 18 07:13:33 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 652FA3A68A5; Tue, 18 Nov 2008 07:13:33 -0800 (PST) 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 0EE543A68A5 for ; Tue, 18 Nov 2008 07:13:32 -0800 (PST) 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 qem44-mtbSOn for ; Tue, 18 Nov 2008 07:13:31 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by core3.amsl.com (Postfix) with ESMTP id 8FB013A687E for ; Tue, 18 Nov 2008 07:13:30 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id b11so1498173nfh.39 for ; Tue, 18 Nov 2008 07:13:28 -0800 (PST) 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=lD3N0sXsu3wQVmV2nBY5q0qDQ2ZQWCMaGj7gnAQmRro=; b=KuTUZnCucXV4Zd+hjE70vqk2guicsteIzGdC/JFnAIu9mrR/wn2ZoEGkzP8rSJP1YP +Q5809N3JfpK7/u/3MMjM5trB1NEGxoNvcuwYEB72VUVmnPcuhIRfb1Udn9OQzSKXoQJ QDb4dAei19omo3BpnueeP+n9hSUzIyePOvtak= 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=CfNo0IjE7/lw7vMNCqi8uKk5XMZ+ISMdA7GgYpQC+imIdj0ZXGQKIzVqp6x2MaaVtY uTEqCaXrSglFXxoeRV/2CBN3ig+XpdcyVJdyjuADEu/NtMebeXJK5tg0k6b0Rif6B4p4 tGRnxcOlqb1biQz1RfNWF8dQ71CSenbPbO6q0= Received: by 10.210.121.8 with SMTP id t8mr5006200ebc.143.1227021208793; Tue, 18 Nov 2008 07:13:28 -0800 (PST) Received: by 10.210.109.14 with HTTP; Tue, 18 Nov 2008 07:13:28 -0800 (PST) Message-ID: <1d38a3350811180713p3e1b7849g9f50e0a6e66cf709@mail.gmail.com> Date: Tue, 18 Nov 2008 23:13:28 +0800 From: "Hui Deng" To: "Yoav Nir" In-Reply-To: <7C69DECB-BB75-43BA-ABED-6DB5DB648791@checkpoint.com> MIME-Version: 1.0 References: <1d38a3350811172207m1801bf77ra4518f06deb61207@mail.gmail.com> <7C69DECB-BB75-43BA-ABED-6DB5DB648791@checkpoint.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-resumption-00.txt ticket location 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="===============2024501148==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============2024501148== Content-Type: multipart/alternative; boundary="----=_Part_56250_1338422.1227021208787" ------=_Part_56250_1338422.1227021208787 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 2008/11/18 Yoav Nir > Hi Hui, > On Nov 18, 2008, at 8:07 AM, Hui Deng wrote: > > Hello, authors, >> >> After reading your draft and rethinking of the main issues, I would like >> to raise one issue about ticket location issue: >> there have two problems on sending tickets with all the information to the >> client >> >> a) If the session resumption solution is deployed in mobile network, >> it will consume a lot of air-interface cost to request/present/update >> the ticket. As the mobile operators, we prefer not do that. > > The draft does not specify the ticket format. This could be very compact, > down to 16-24 bytes, including notification payload header. > > > b) As discussed in the list, the packet to send the ticket may be >> fragmented. When session resumption happened, a large number of the >> client may try to present the ticket at the same time. In this case, a >> bunch of fragmented IP packets will be sent to the gateway. Some >> equipments (such as mobile network GW, firewalls, etc) between clients >> and gateway may be overloaded to handle the IP fragment. And, some >> equipments may treat it as DoS attack and simply drop all the >> fragmented packets. the most important issue, the wireless base station >> will be chunked and died. >> > > I understand that resumption may have severe implications for the core > network - lots of simultaneous IKE traffic, but aren't the clients supposed > to be spread out among very many base stations? I didn't think there should > be congestion at the base stations. it depends on how to express it, mostly congestion will happen in security gateway or firewall, sometime it also lead to the congestion at the base station. it depends on how many subscribers under this base station, how could the signaling channel of this base station to handle this. Anyway, I think this issue exists. > > >> thanks for your consideration. under this consideration, we would like to >> recommend the solution which could store the ticket information purely on >> the network side. >> thanks for your consideration. >> > > The "ticket" could be a 64- or 128-bit index into a database table, giving > a total payload size of 16 or 24 bytes respectively. I believe a payload > this small should not overload the "air". Does a solution such as this > address your concerns? this working group doc already refer to our input, so we are fine with this. -Hui > > Hope this helps > > Yoav > > ------=_Part_56250_1338422.1227021208787 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
2008/11/18 Yoav Nir <ynir@checkpoint.com>
Hi Hui,
On Nov 18, 2008, at 8:07 AM, Hui Deng wrote:

Hello, authors,

After reading your draft and rethinking of the main issues, I would like to raise one issue about ticket location issue:
there have two problems on sending tickets with all the information to the client

a) If the session resumption solution is deployed in mobile network,
it will consume a lot of air-interface cost to request/present/update
the ticket. As the mobile operators, we prefer not do that.
The draft does not specify the ticket format. This could be very compact, down to 16-24 bytes, including notification payload header.
 
 


b) As discussed in the list, the packet to send the ticket may be
fragmented. When session resumption happened, a large number of the
client may try to present the ticket at the same time. In this case, a
bunch of fragmented IP packets will be sent to the gateway. Some
equipments (such as mobile network GW, firewalls, etc) between clients
and gateway may be overloaded to handle the IP fragment. And, some
equipments may treat it as DoS attack and simply drop all the
fragmented packets. the most important issue, the wireless base station
will be chunked and died.

I understand that resumption may have severe implications for the core network - lots of simultaneous IKE traffic, but aren't the clients supposed to be spread out among very many base stations?  I didn't think there should be congestion at the base stations.
it depends on how to express it, mostly congestion will happen in security gateway or firewall, sometime it also lead to the congestion at the base station. it depends on how many subscribers under this base station, how could the signaling channel of this base station to handle this. Anyway, I think this issue exists.
 


thanks for your consideration. under this consideration, we would like to
recommend the solution which could store the ticket information purely on
the network side.
thanks for your consideration.

The "ticket" could be a 64- or 128-bit index into a database table, giving a total payload size of 16 or 24 bytes respectively. I believe a payload this small should not overload the "air". Does a solution such as this address your concerns?
this working group doc already refer to our input, so we are fine with this.
 
-Hui 
 

Hope this helps

Yoav


------=_Part_56250_1338422.1227021208787-- --===============2024501148== 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 --===============2024501148==-- From ipsec-bounces@ietf.org Tue Nov 18 07:18:52 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 3463A3A69B0; Tue, 18 Nov 2008 07:18:52 -0800 (PST) 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 A90693A6784 for ; Tue, 18 Nov 2008 07:18:50 -0800 (PST) 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 mvoZkxFwaKy7 for ; Tue, 18 Nov 2008 07:18:49 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 9DBF73A699E for ; Tue, 18 Nov 2008 07:18:49 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so1175451eyd.31 for ; Tue, 18 Nov 2008 07:18:47 -0800 (PST) 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=KQujMXryMGSa5trj8wmq4aFDP6GHCF0vJ/UgnhTe39w=; b=J/baCpIvT2yirR8eMpWpG0sfmXntVxTxPj4H5KkDPKR0LBUkLmSZ1p0pK+zdRAWr8v Zb/Q/rZBp6arxhGq4ll/2GVX/0IZsGoCgGRVrCBdZxkfYp50qVLylJeRedKs13nyMiNp NYDltZGFhP0GUNRI/vqy2ih9bdaTwbcvnwV6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=vJ3jf9GSuZTXs7TUqtZibf4EurdoQSww6y+fhuUAVDqYF41Ptmsly/eID8kvqTzfYj w8VfD7CNl0no7RE7Shh17LSwCvQCciUPNfHmzZJM7NpmUTQ2kkljci6JroooHdHsW6Y4 +1a6CwrqsTrB4276Po2Rr7ZmQpq4tusecWdVw= Received: by 10.210.30.10 with SMTP id d10mr5032707ebd.80.1227021527514; Tue, 18 Nov 2008 07:18:47 -0800 (PST) Received: by 10.210.109.14 with HTTP; Tue, 18 Nov 2008 07:18:47 -0800 (PST) Message-ID: <1d38a3350811180718h7dcd5f2ew4a912f568e633ab3@mail.gmail.com> Date: Tue, 18 Nov 2008 23:18:47 +0800 From: "Hui Deng" To: ipsec@ietf.org MIME-Version: 1.0 Subject: [IPsec] draft-ietf-ipsecme-ikev2-resumption-00.txt fragmentation 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="===============1267306647==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1267306647== Content-Type: multipart/alternative; boundary="----=_Part_56326_2013118.1227021527498" ------=_Part_56326_2013118.1227021527498 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline As discussed in the list, the packet to send the ticket may be fragmented. When session resumption happened, a large number of the client may try to present the ticket at the same time. In this case, a bunch of fragmented IP packets will be sent to the gateway. Some equipments (such as mobile network GW, firewalls, etc) between clients and gateway may be overloaded to handle the IP fragment. And, some equipments may treat it as DoS attack and simply drop all the fragmented packets. solution suggest: put the index mandatory, the full IKE sa ticket is optional. ------=_Part_56326_2013118.1227021527498 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
As discussed in the list, the packet to send the ticket may be
fragmented. When session resumption happened, a large number of the
client may try to present the ticket at the same time. In this case, a
bunch of fragmented IP packets will be sent to the gateway. Some
equipments (such as mobile network GW, firewalls, etc) between clients
and gateway may be overloaded to handle the IP fragment. And, some
equipments may treat it as DoS attack and simply drop all the
fragmented packets.
 
solution suggest: put the index mandatory, the full IKE sa ticket is optional.
------=_Part_56326_2013118.1227021527498-- --===============1267306647== 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 --===============1267306647==-- From ipsec-bounces@ietf.org Tue Nov 18 07:49: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 222933A6A53; Tue, 18 Nov 2008 07:49:13 -0800 (PST) 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 2A61E3A68F6 for ; Tue, 18 Nov 2008 07:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, 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 A5ct+AbGHYOo for ; Tue, 18 Nov 2008 07:49:11 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 2C5F03A68F9 for ; Tue, 18 Nov 2008 07:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1227023350; x=1258559350; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding:x-ironport-av; z=Message-ID:=20<4922E3F4.2050805@qualcomm.com>|Date:=20Tu e,=2018=20Nov=202008=2007:49:08=20-0800|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Thun derbird=202.0.0.17=20(Windows/20080914)|MIME-Version:=201 .0|To:=20ipsec@ietf.org|Subject:=20For=20Ahmad's=20benefi t|Content-Type:=20text/plain=3B=20charset=3DISO-8859-15 =3B=20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,5437"=3B=20a =3D"13235071"; bh=9SBkNK4NwOUFrVVgsgX+4JVeeRFU2OAdrImDN/ZU8Wg=; b=nos12M0fv4S1sD5yjAz9kn51diOyKDnnw7G27IWUg3xFmrfqLZuAXQ5w C+Rjm7NWpBzNquUrg61uHY7nZr5JnR6WjQ4YjAQsAtiup2Dd6Z88zuIlq dPnRPID6atJGi8t4rLYOYChIfCgiw6xgVesklyrciFy8K4aYpM54ElNAP k=; X-IronPort-AV: E=McAfee;i="5100,188,5437"; a="13235071" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Nov 2008 07:49:10 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAIFnAJH016646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 18 Nov 2008 07:49:10 -0800 Received: from [10.50.76.222] (qconnect-10-50-76-222.qualcomm.com [10.50.76.222]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAIFn9T1013454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 18 Nov 2008 07:49:10 -0800 Message-ID: <4922E3F4.2050805@qualcomm.com> Date: Tue, 18 Nov 2008 07:49:08 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ipsec@ietf.org Subject: [IPsec] For Ahmad's benefit 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 It's still possible that I haven't read my own draft. I just wrote it :). So, for Ahmad's benefit, here are some excerpts: "This document specifies a new IKEv2 exchange type called IKE_SESSION_RESUME whose value is TBA by IANA. This exchange is somewhat similar to the IKE_AUTH exchange, and results in the creation of a Child SA. " Here is how it looks like and you might notice the similarity to IKE_AUTH: "HDR, Ni, N(TICKET_OPAQUE), [N+,] SK {IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} -->" "4.2.1. Protection of the IKE_SESSION_RESUME Exchange The two messages of this exchange are protected by a "subset" IKE SA. The key material is derived from the ticket, as follows:" So, at this point, I wonder whether the question was about how the Session resumption exchange is protected. best, Lakshminath _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 18 07:53: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 B76303A6851; Tue, 18 Nov 2008 07:53:35 -0800 (PST) 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 28DA23A6851 for ; Tue, 18 Nov 2008 07:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.406 X-Spam-Level: X-Spam-Status: No, score=-6.406 tagged_above=-999 required=5 tests=[AWL=0.193, 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 zcxwi3Uhj-GK for ; Tue, 18 Nov 2008 07:53:33 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 689D53A6808 for ; Tue, 18 Nov 2008 07:53:33 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mAIFqBo6000342 for ; Tue, 18 Nov 2008 09:53:30 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 17:53:28 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 17:53:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 17:53:27 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB720251410F@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ticket-by-reference and protecting the exchange Thread-Index: AclJlcvQh/bLY3mxSneX3JjE8IsQuw== From: To: X-OriginalArrivalTime: 18 Nov 2008 15:53:28.0648 (UTC) FILETIME=[CC7D2C80:01C94995] X-Nokia-AV: Clean Subject: [IPsec] Ticket-by-reference and protecting the exchange 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 Tough chairs! Here's the answer I was going to say at the microphone: The client does not (and cannot) know whether it's using "ticket-by-value" (where the ticket contains the gateway's state, in encrypted form) or "ticket-by-reference" (where the ticket contains only a pointer to state stored locally by the gateway), or even a combination (some state is in the ticket, some is stored locally). In *addition* to storing the ticket blob, the client has to store the keys from the old IKE_SA (and this is done even if ticket-by-reference is used -- since the client cannot know that). The client uses these keys to protect the resumption exchange. The gateway also needs these keys; it gets them from the ticket, or from its local storage (using the ticket as a pointer). If the gateway is using ticket-by-reference, and there's a cluster of multiple gateways, the cluster members need to communicate somehow (and obviously this communication needs to be secured somehow). This protocol is explicitly beyond the scope of the charter. (BTW, if the gateway uses ticket-by-reference, things work pretty much the same way as draft-xu-ike-sa-sync, except that the terminology is slightly different, and this document doesn't say anything about how multiple gateways communicate, possibly via some database server, called "stub bank" in draft-xu-...). Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 18 07:58: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 5D32728C14C; Tue, 18 Nov 2008 07:58:07 -0800 (PST) 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 E2E0428C149 for ; Tue, 18 Nov 2008 07:58:06 -0800 (PST) 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 hNPQJnKjZrzv for ; Tue, 18 Nov 2008 07:58:06 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 4C68C28C13D for ; Tue, 18 Nov 2008 07:58:06 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 9700A102241C6; Tue, 18 Nov 2008 07:58:05 -0800 (PST) Received: from 130.129.30.34 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 18 Nov 2008 07:58:05 -0800 (PST) Message-ID: <9722bf5f8d04560abcd678625e398c42.squirrel@www.trepanning.net> In-Reply-To: <1d38a3350811180713p3e1b7849g9f50e0a6e66cf709@mail.gmail.com> References: <1d38a3350811172207m1801bf77ra4518f06deb61207@mail.gmail.com> <7C69DECB-BB75-43BA-ABED-6DB5DB648791@checkpoint.com> <1d38a3350811180713p3e1b7849g9f50e0a6e66cf709@mail.gmail.com> Date: Tue, 18 Nov 2008 07:58:05 -0800 (PST) From: "Dan Harkins" To: "Hui Deng" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-resumption-00.txt ticket location 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, On Tue, November 18, 2008 7:13 am, Hui Deng wrote: > 2008/11/18 Yoav Nir > [snip] >> I understand that resumption may have severe implications for the core >> network - lots of simultaneous IKE traffic, but aren't the clients >> supposed >> to be spread out among very many base stations? I didn't think there >> should >> be congestion at the base stations. > > it depends on how to express it, mostly congestion will happen in security > gateway or firewall, sometime it also lead to the congestion at the base > station. it depends on how many subscribers under this base station, how > could the signaling channel of this base station to handle this. Anyway, I > think this issue exists. It should not matter what traffic the subscribers are sending. If the base station does not have trouble supporting them while they send random data traffic then it will not have trouble supporting them when they initiate IKE session resumption. If it is having trouble supporting them when they initiate IKE session resumption then you have problems at your base station that have nothing to do with IKE session resumption. Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 18 07:59:26 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 5440528C13E; Tue, 18 Nov 2008 07:59:26 -0800 (PST) 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 B7E9D28C13E for ; Tue, 18 Nov 2008 07:59:24 -0800 (PST) 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 s7woNE-dPH9g for ; Tue, 18 Nov 2008 07:59:23 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id A25213A699E for ; Tue, 18 Nov 2008 07:59:23 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mAIFxIu12369; Tue, 18 Nov 2008 15:59:19 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 09:59:14 -0600 Message-ID: In-Reply-To: <1696498986EFEC4D9153717DA325CB720251410F@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Ticket-by-reference and protecting the exchange Thread-Index: AclJlcvQh/bLY3mxSneX3JjE8IsQuwAABKxw References: <1696498986EFEC4D9153717DA325CB720251410F@vaebe104.NOE.Nokia.com> From: "Ahmad Muhanna" To: , Subject: Re: [IPsec] Ticket-by-reference and protecting the exchange 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 Thanks Pasi for the explanation. On the other hand, can you point to the normative text in the draft where it captures what you just said. Also, the draft include the following text, just as an example: " 4.2.1. Protection of the IKE_SESSION_RESUME Exchange The key material is derived from the ticket, as follows: {SK_d2 | SK_ai | SK_ar | SK_ei | SK_er} = prf+(SK_d_old, Ni) where SK_d_old is the SK_d value of the original IKE SA, as retrieved from the ticket. Ni guarantees freshness of the key material. SK_d2 is used later to derive the new IKE SA, see Section 4.5. " How does that fit with what you just mentioned? Thanks! Regards, Ahmad > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Pasi.Eronen@nokia.com > Sent: Tuesday, November 18, 2008 9:53 AM > To: ipsec@ietf.org > Subject: [IPsec] Ticket-by-reference and protecting the exchange > > Tough chairs! Here's the answer I was going to say at the > microphone: > > The client does not (and cannot) know whether it's using > "ticket-by-value" (where the ticket contains the gateway's > state, in encrypted form) or "ticket-by-reference" (where the > ticket contains only a pointer to state stored locally by the > gateway), or even a combination (some state is in the ticket, > some is stored locally). > > In *addition* to storing the ticket blob, the client has to > store the keys from the old IKE_SA (and this is done even if > ticket-by-reference is used -- since the client cannot know > that). The client uses these keys to protect the resumption > exchange. The gateway also needs these keys; it gets them > from the ticket, or from its local storage (using the ticket > as a pointer). > > If the gateway is using ticket-by-reference, and there's a > cluster of multiple gateways, the cluster members need to > communicate somehow (and obviously this communication needs > to be secured somehow). > This protocol is explicitly beyond the scope of the charter. > > > (BTW, if the gateway uses ticket-by-reference, things work > pretty much the same way as draft-xu-ike-sa-sync, except that > the terminology is slightly different, and this document > doesn't say anything about how multiple gateways communicate, > possibly via some database server, called "stub bank" in > draft-xu-...). > > Best regards, > Pasi > _______________________________________________ > 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 Nov 18 08:09: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 A31213A69CF; Tue, 18 Nov 2008 08:09:27 -0800 (PST) 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 A067A28C101 for ; Tue, 18 Nov 2008 08:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.417 X-Spam-Level: X-Spam-Status: No, score=-6.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 7K10btaqR-lg for ; Tue, 18 Nov 2008 08:09:24 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 675D23A6916 for ; Tue, 18 Nov 2008 08:09:24 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mAIG91Rh025653; Tue, 18 Nov 2008 18:09:21 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 18:09:15 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 18:09:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 18:09:13 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB7202514133@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Ticket-by-reference and protecting the exchange Thread-Index: AclJlcvQh/bLY3mxSneX3JjE8IsQuwAABKxwAABSo0A= References: <1696498986EFEC4D9153717DA325CB720251410F@vaebe104.NOE.Nokia.com> From: To: , X-OriginalArrivalTime: 18 Nov 2008 16:09:15.0030 (UTC) FILETIME=[00939B60:01C94998] X-Nokia-AV: Clean Subject: Re: [IPsec] Ticket-by-reference and protecting the exchange 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 Ahmed, Ah, now I see where the confusion comes from! The text should say something like "The key material is derived from old SK_d as follows: [...] The client has stored the old SK_d together with the ticket itself. The gateway obtains SK_d either from the ticket, or from locally stored state." The draft doesn't actually say what the client has to store. I guess the authors assumed it's obvious that the client stores both the ticket, and it's own IKE_SA state (SK_d, algorithms, etc.) -- but the draft should of course explicitly say that. Best regards, Pasi > -----Original Message----- > From: ext Ahmad Muhanna [mailto:amuhanna@nortel.com] > Sent: 18 November, 2008 17:59 > To: Eronen Pasi (Nokia-NRC/Helsinki); ipsec@ietf.org > Subject: RE: [IPsec] Ticket-by-reference and protecting the exchange > > Thanks Pasi for the explanation. > > On the other hand, can you point to the normative text in the draft > where it captures what you just said. > Also, the draft include the following text, just as an example: > > " > 4.2.1. Protection of the IKE_SESSION_RESUME Exchange > > The key material is derived from the ticket, as follows: > > {SK_d2 | SK_ai | SK_ar | SK_ei | SK_er} = prf+(SK_d_old, Ni) > > where SK_d_old is the SK_d value of the original IKE SA, > as retrieved > from the ticket. Ni guarantees freshness of the key > material. SK_d2 > is used later to derive the new IKE SA, see Section 4.5. > " > > How does that fit with what you just mentioned? > > Thanks! > > Regards, > Ahmad > > > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > > On Behalf Of Pasi.Eronen@nokia.com > > Sent: Tuesday, November 18, 2008 9:53 AM > > To: ipsec@ietf.org > > Subject: [IPsec] Ticket-by-reference and protecting the exchange > > > > Tough chairs! Here's the answer I was going to say at the > > microphone: > > > > The client does not (and cannot) know whether it's using > > "ticket-by-value" (where the ticket contains the gateway's > > state, in encrypted form) or "ticket-by-reference" (where the > > ticket contains only a pointer to state stored locally by the > > gateway), or even a combination (some state is in the ticket, > > some is stored locally). > > > > In *addition* to storing the ticket blob, the client has to > > store the keys from the old IKE_SA (and this is done even if > > ticket-by-reference is used -- since the client cannot know > > that). The client uses these keys to protect the resumption > > exchange. The gateway also needs these keys; it gets them > > from the ticket, or from its local storage (using the ticket > > as a pointer). > > > > If the gateway is using ticket-by-reference, and there's a > > cluster of multiple gateways, the cluster members need to > > communicate somehow (and obviously this communication needs > > to be secured somehow). > > This protocol is explicitly beyond the scope of the charter. > > > > > > (BTW, if the gateway uses ticket-by-reference, things work > > pretty much the same way as draft-xu-ike-sa-sync, except that > > the terminology is slightly different, and this document > > doesn't say anything about how multiple gateways communicate, > > possibly via some database server, called "stub bank" in > > draft-xu-...). > > > > Best regards, > > Pasi > > _______________________________________________ > > 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 Nov 18 08:10: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 686A93A6916; Tue, 18 Nov 2008 08:10:51 -0800 (PST) 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 1D3843A69CF for ; Tue, 18 Nov 2008 08:10:50 -0800 (PST) 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 YbdICuszfAee for ; Tue, 18 Nov 2008 08:10:49 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id CA7CF3A68E7 for ; Tue, 18 Nov 2008 08:10:48 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mAIGAhu15498; Tue, 18 Nov 2008 16:10:43 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 10:10:39 -0600 Message-ID: In-Reply-To: <4922E3F4.2050805@qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] For Ahmad's benefit Thread-Index: AclJlYMOYqEaNIbySbaQC5HZfjNEEAAAcvMQ References: <4922E3F4.2050805@qualcomm.com> From: "Ahmad Muhanna" To: "Lakshminath Dondeti" , Subject: Re: [IPsec] For Ahmad's benefit 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 Lakshminath, As I said, all the text you captured assumed the ticket contain a value NOT a reference. Please take a look at Pasi's posting and my reply. Basically in order to be clear enough and reduce a lot of exchange, the draft is written with one type of ticket is in mind. "TICKET with VALUE" I suggest that the draft be rewritten with both types of tickets in mind as the draft itself ALLOWS. Cheers! Regards, Ahmad > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Lakshminath Dondeti > Sent: Tuesday, November 18, 2008 9:49 AM > To: ipsec@ietf.org > Subject: [IPsec] For Ahmad's benefit > > It's still possible that I haven't read my own draft. I just > wrote it :). So, for Ahmad's benefit, here are some excerpts: > > "This document specifies a new IKEv2 exchange type called > IKE_SESSION_RESUME whose value is TBA by IANA. This exchange is > somewhat similar to the IKE_AUTH exchange, and results in the > creation of a Child SA. " > > Here is how it looks like and you might notice the similarity > to IKE_AUTH: > > "HDR, Ni, N(TICKET_OPAQUE), [N+,] > SK {IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} -->" > > > "4.2.1. Protection of the IKE_SESSION_RESUME Exchange > > > The two messages of this exchange are protected by a > "subset" IKE SA. > The key material is derived from the ticket, as follows:" > > > So, at this point, I wonder whether the question was about > how the Session resumption exchange is protected. > > best, > Lakshminath > _______________________________________________ > 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 Nov 18 08:19:09 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 118423A6A86; Tue, 18 Nov 2008 08:19:09 -0800 (PST) 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 515503A6A30 for ; Tue, 18 Nov 2008 08:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=0.540, 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 DKk+hZFcPDun for ; Tue, 18 Nov 2008 08:19:03 -0800 (PST) Received: from mail.f5.com (mail.f5.com [65.197.145.96]) by core3.amsl.com (Postfix) with ESMTP id 4FF683A68E7 for ; Tue, 18 Nov 2008 08:19:03 -0800 (PST) Received: from exch11.olympus.f5net.com ([192.168.16.104]) by e2k7ca1.olympus.f5net.com ([192.168.16.101]) with mapi; Tue, 18 Nov 2008 08:19:02 -0800 From: James Goodwin To: Yoav Nir Date: Tue, 18 Nov 2008 08:19:00 -0800 Thread-Topic: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-00.txt Thread-Index: AclJWMRg4Oo2KpZzQIqn5YYca7Zs1wAP9z1A Message-ID: <4B18A8F75A6384449755BC7784073E935F6AB05FC4@exch11.olympus.f5net.com> References: <4B18A8F75A6384449755BC7784073E935F6AB05D35@exch11.olympus.f5net.com> <3EB07ACE-3428-4C63-BA7A-9DC1F9A5A296@checkpoint.com> In-Reply-To: <3EB07ACE-3428-4C63-BA7A-9DC1F9A5A296@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Jeff Bellamy , Ryan Korock , Jain , Amit@core3.amsl.com Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-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="===============1840096849==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1840096849== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_4B18A8F75A6384449755BC7784073E935F6AB05FC4exch11olympus_" --_000_4B18A8F75A6384449755BC7784073E935F6AB05FC4exch11olympus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yoav, Thanks very much for the response and context. Makes sense. Yes, thinking about this more, understand why slow path (e.g. software) is = not so bad if focus is only on unencrypted traffic. Still might argue that = keeping some flexibility here (via flags octet) may save having to do anoth= er UDP wrapper in the future. Cheers, --James From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Tuesday, November 18, 2008 12:37 AM To: James Goodwin Cc: ipsec@ietf.org; Jeff Bellamy; Amit Jain; Ryan Korock Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-00.tx= t Hi James, On Nov 18, 2008, at 9:38 AM, James Goodwin wrote: A couple questions/concerns: - Why not include an "integrity-only" bit in the header (flags oct= et) so that the wrapper may be used to handle both integrity-only and encry= ption + integrity modes for ESP? I believe Yaron has also asked this questi= on. At the previous IETF meeting, there was considerable opposition to the idea= of making a "next-generation" ESP. Some participants did not want this ext= ension to affect encrypted traffic. For one reason, see below - How much change to silicon (cost to chip vendors) is required to= support the additional XESP header and new protocol number? This must be w= idely supported by IPSec silicon vendors for this proposal to succeed. It's not a lot of change to silicon, and the chip vendors should have no pr= oblem doing this for the next release. The problem is with already deployed= devices such as routers and firewalls, that would not recognize this new p= rotocol. Support can still be added with software or rulebase, but it does = mean that such traffic may go on the slow path on intermediary devices. Tha= t is one reason why some participants don't want a "new ESP" --_000_4B18A8F75A6384449755BC7784073E935F6AB05FC4exch11olympus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Yoav,

 

Thanks very much for the response and context. Makes sense.<= o:p>

 

Yes, thinking about this more, understand why slow path (e.g= . software) is not so bad if focus is only on unencrypted traffic. Still migh= t argue that keeping some flexibility here (via flags octet) may save having = to do another UDP wrapper in the future.

 

Cheers,

--James

 

From: Yoav Nir [mailto:ynir@checkpoint.com]
Sent: Tuesday, November 18, 2008 12:37 AM
To: James Goodwin
Cc: ipsec@ietf.org; Jeff Bellamy; Amit Jain; Ryan Korock
Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-00.txt

 

Hi James,

 

On Nov 18, 2008, at 9:38 AM, James Goodwin wrote:=

A couple questions/concerns:

-          Why not include an “integrity-only” bit in the header (flags octet) so that the wrapper may be used to handle both integrity-only and encryption + integrit= y modes for ESP? I believe Yaron has also asked this question.

 

At the previous IETF meeting, there was considerable opposition to the idea of making a "next-generation" ESP. Some participants did not want this extension to affect encrypted traffic.  = ;For one reason, see below



-          How much change to silicon (cost to chip vendors) is required to support the additional XESP header an= d new protocol number? This must be widely supported by IPSec silicon vendors= for this proposal to succeed.

 

It's not a lot of change to silicon, and the chip vend= ors should have no problem doing this for the next release. The problem is with already deployed devices such as routers and firewalls, that would not recognize this new protocol. Support can still be added with software or rulebase, but it does mean that such traffic may go on the slow path on intermediary devices. That is one reason why some participants don't want a "new ESP"

 

--_000_4B18A8F75A6384449755BC7784073E935F6AB05FC4exch11olympus_-- --===============1840096849== 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 --===============1840096849==-- From ipsec-bounces@ietf.org Tue Nov 18 08:19:33 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 E5C1E3A6AA9; Tue, 18 Nov 2008 08:19:32 -0800 (PST) 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 0448C3A6AEA for ; Tue, 18 Nov 2008 08:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.099 X-Spam-Level: X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=1.500, 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 HYu79Rdma5c4 for ; Tue, 18 Nov 2008 08:19:30 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id E10BA3A69CF for ; Tue, 18 Nov 2008 08:19:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1227025169; x=1258561169; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<4922EB0E.8070800@qualcomm.com>|Date:=20Tu e,=2018=20Nov=202008=2008:19:26=20-0800|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Thun derbird=202.0.0.17=20(Windows/20080914)|MIME-Version:=201 .0|To:=20Ahmad=20Muhanna=20|CC:=20ip sec@ietf.org|Subject:=20Re:=20[IPsec]=20For=20Ahmad's=20b enefit|References:=20<4922E3F4.2050805@qualcomm.com>=20|In-Reply-To:=20|Content-Type:=20text/p lain=3B=20charset=3DISO-8859-15=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-IronPort-AV:=20E=3DM cAfee=3Bi=3D"5300,2777,5437"=3B=20a=3D"13261450"; bh=1PiTcJXibiJL+R47mbx5r2nKMpWrJzXXVNm4oPWLWOU=; b=u6R0G6BJdcE7/A27vlM/M8SvhV8igJC8mtkt9Zfuns2c7XewlQVw9RLP DVkW0Hq4qeizDg4T+WT5giH23JrSgkx4gabF+tAnpZFihqGak/sZSuoT1 hLn4VkaFwbBvJtMd4Sm0f3V0hQ7cPc8QRUPwCKQHH8gDSn9avNXbVj2aF 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5437"; a="13261450" 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; 18 Nov 2008 08:19:29 -0800 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAIGJSon010342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Nov 2008 08:19:29 -0800 Received: from [10.50.76.222] (qconnect-10-50-76-222.qualcomm.com [10.50.76.222]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAIGJR6C006306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Nov 2008 08:19:28 -0800 Message-ID: <4922EB0E.8070800@qualcomm.com> Date: Tue, 18 Nov 2008 08:19:26 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Ahmad Muhanna References: <4922E3F4.2050805@qualcomm.com> In-Reply-To: Cc: ipsec@ietf.org Subject: Re: [IPsec] For Ahmad's benefit 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 But, the contents of the ticket are not necessarily privy to the client. Pasi's explanation works for you perhaps? best, Lakshminath On 11/18/2008 8:10 AM, Ahmad Muhanna wrote: > Hi Lakshminath, > > As I said, all the text you captured assumed the ticket contain a value > NOT a reference. Please take a look at Pasi's posting and my reply. > Basically in order to be clear enough and reduce a lot of exchange, the > draft is written with one type of ticket is in mind. "TICKET with VALUE" > > > I suggest that the draft be rewritten with both types of tickets in mind > as the draft itself ALLOWS. > > Cheers! > > Regards, > Ahmad > > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] >> On Behalf Of Lakshminath Dondeti >> Sent: Tuesday, November 18, 2008 9:49 AM >> To: ipsec@ietf.org >> Subject: [IPsec] For Ahmad's benefit >> >> It's still possible that I haven't read my own draft. I just >> wrote it :). So, for Ahmad's benefit, here are some excerpts: >> >> "This document specifies a new IKEv2 exchange type called >> IKE_SESSION_RESUME whose value is TBA by IANA. This exchange is >> somewhat similar to the IKE_AUTH exchange, and results in the >> creation of a Child SA. " >> >> Here is how it looks like and you might notice the similarity >> to IKE_AUTH: >> >> "HDR, Ni, N(TICKET_OPAQUE), [N+,] >> SK {IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} -->" >> >> >> "4.2.1. Protection of the IKE_SESSION_RESUME Exchange >> >> >> The two messages of this exchange are protected by a >> "subset" IKE SA. >> The key material is derived from the ticket, as follows:" >> >> >> So, at this point, I wonder whether the question was about >> how the Session resumption exchange is protected. >> >> best, >> Lakshminath >> _______________________________________________ >> 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 Nov 18 08:20: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 D5E993A6B04; Tue, 18 Nov 2008 08:20:13 -0800 (PST) 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 62EFF3A6B04 for ; Tue, 18 Nov 2008 08:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.427 X-Spam-Level: X-Spam-Status: No, score=-6.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 pvI9aizUAu5H for ; Tue, 18 Nov 2008 08:20:11 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 19ABF3A6AFF for ; Tue, 18 Nov 2008 08:20:08 -0800 (PST) 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 mAIGK4wE032192; Tue, 18 Nov 2008 18:20:05 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 18:20:04 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 18:20:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 18:20:02 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB7202514149@vaebe104.NOE.Nokia.com> In-Reply-To: <1d38a3350811180718h7dcd5f2ew4a912f568e633ab3@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] draft-ietf-ipsecme-ikev2-resumption-00.txt fragmentation Thread-Index: AclJkQNUAnZFAMiuSiKyHGQtyW0YiwAB7+MA References: <1d38a3350811180718h7dcd5f2ew4a912f568e633ab3@mail.gmail.com> From: To: , X-OriginalArrivalTime: 18 Nov 2008 16:20:04.0001 (UTC) FILETIME=[8364B910:01C94999] X-Nokia-AV: Clean Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-resumption-00.txt fragmentation 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 During the meeting I mentioned there's a paper explaining why keeping the first IKE_SA_INIT small (=small enough not to require fragmentation) is useful. Tero found the link and posted it to Jabber: Kaufman, C., Perlman, R., and Sommerfeld, B., "DoS protection for UDP-based protocols", ACM Conference on Computer and Communications Security, October 2003. Google found this PDF version: http://www.eecis.udel.edu/~mills/teaching/eleg867b/dos/p2-kaufman.pdf (However, currently the document allows the gateway to construct tickets any way it wishes -- neither "ticket-by-reference" nor "ticket-by-value" is mandatory. I think we should keep it this way -- but some parts of the draft probably need some clarification how it works if "ticket-by-reference" is used.) Best regards, Pasi > -----Original Message----- > From: Hui Deng > Sent: 18 November, 2008 17:19 > To: ipsec@ietf.org > Subject: [IPsec] draft-ietf-ipsecme-ikev2-resumption-00.txt fragmentation > > > As discussed in the list, the packet to send the ticket may be > fragmented. When session resumption happened, a large number of the > client may try to present the ticket at the same time. In this case, > a bunch of fragmented IP packets will be sent to the gateway. Some > equipments (such as mobile network GW, firewalls, etc) between > clients and gateway may be overloaded to handle the IP > fragment. And, some equipments may treat it as DoS attack and simply > drop all the fragmented packets. > > solution suggest: put the index mandatory, the full IKE sa ticket is > optional. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 18 08:24: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 05D7E28C123; Tue, 18 Nov 2008 08:24:15 -0800 (PST) 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 ACADA28C123 for ; Tue, 18 Nov 2008 08:24:13 -0800 (PST) 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 qCwlKkmekNKm for ; Tue, 18 Nov 2008 08:24:12 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 60F423A68E7 for ; Tue, 18 Nov 2008 08:24:12 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so1187542eyd.31 for ; Tue, 18 Nov 2008 08:24:10 -0800 (PST) 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=cxO3Tp0R2TFbeWNvnwS+jjX0eQmKXiNdLP130zT+GQc=; b=bxFeMowcqlO19NTcoh/ipfyxjL4UP65jjdfLIpBTfhImx6hUq+yWpZM/WwTEWW+MZM Stgz7z0nkdfUwJaQL6BgIQxXWEJxfo6OiNhDC5avn4WdcH//qOYVAHkwXYh3HAmrcL86 l4lcw63SaleOKAWmD+BJ78tmPMh03dcTYFMfU= 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=kZ6hnC23kIism0udQa4eTmySEdG8yb4qK8J93tRX17oakENusIxbkeVLOnM3PNTMvy M8kckDi4cXrkE2e7SB/7SgrATStuUHrhEcp/OveX2oOvqS5B1O3xggUEFPcFoMi+mIM4 D6OeTSi/oBnwwyizq7S9v0JA0k3L1vtj5lNSg= Received: by 10.210.119.5 with SMTP id r5mr30819ebc.89.1227025450053; Tue, 18 Nov 2008 08:24:10 -0800 (PST) Received: by 10.210.109.14 with HTTP; Tue, 18 Nov 2008 08:24:10 -0800 (PST) Message-ID: <1d38a3350811180824o25d87148n2b882bcec433dcd9@mail.gmail.com> Date: Wed, 19 Nov 2008 00:24:10 +0800 From: "Hui Deng" To: Pasi.Eronen@nokia.com In-Reply-To: <1696498986EFEC4D9153717DA325CB7202514149@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 References: <1d38a3350811180718h7dcd5f2ew4a912f568e633ab3@mail.gmail.com> <1696498986EFEC4D9153717DA325CB7202514149@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-resumption-00.txt fragmentation 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="===============1858526836==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1858526836== Content-Type: multipart/alternative; boundary="----=_Part_57185_24210649.1227025450047" ------=_Part_57185_24210649.1227025450047 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline thanks Pasi and Tero pointing the document. we will bring more text about how reference could work in this document. -Hui 2008/11/19 > During the meeting I mentioned there's a paper explaining why > keeping the first IKE_SA_INIT small (=small enough not to require > fragmentation) is useful. Tero found the link and posted it to Jabber: > > Kaufman, C., Perlman, R., and Sommerfeld, B., "DoS protection for > UDP-based protocols", ACM Conference on Computer and > Communications Security, October 2003. > > Google found this PDF version: > http://www.eecis.udel.edu/~mills/teaching/eleg867b/dos/p2-kaufman.pdf > > (However, currently the document allows the gateway to construct > tickets any way it wishes -- neither "ticket-by-reference" nor > "ticket-by-value" is mandatory. I think we should keep it this > way -- but some parts of the draft probably need some clarification > how it works if "ticket-by-reference" is used.) > > Best regards, > Pasi > > > -----Original Message----- > > From: Hui Deng > > Sent: 18 November, 2008 17:19 > > To: ipsec@ietf.org > > Subject: [IPsec] draft-ietf-ipsecme-ikev2-resumption-00.txt fragmentation > > > > > > As discussed in the list, the packet to send the ticket may be > > fragmented. When session resumption happened, a large number of the > > client may try to present the ticket at the same time. In this case, > > a bunch of fragmented IP packets will be sent to the gateway. Some > > equipments (such as mobile network GW, firewalls, etc) between > > clients and gateway may be overloaded to handle the IP > > fragment. And, some equipments may treat it as DoS attack and simply > > drop all the fragmented packets. > > > > solution suggest: put the index mandatory, the full IKE sa ticket is > > optional. > ------=_Part_57185_24210649.1227025450047 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
thanks Pasi and Tero pointing the document.
 
we will bring more text about how reference could work in this document.
 
-Hui

2008/11/19 <Pasi.Eronen@nokia.com>
During the meeting I mentioned there's a paper explaining why
keeping the first IKE_SA_INIT small (=small enough not to require
fragmentation) is useful. Tero found the link and posted it to Jabber:

   Kaufman, C., Perlman, R., and Sommerfeld, B., "DoS protection for
   UDP-based protocols", ACM Conference on Computer and
   Communications Security, October 2003.

Google found this PDF version:
http://www.eecis.udel.edu/~mills/teaching/eleg867b/dos/p2-kaufman.pdf

(However, currently the document allows the gateway to construct
tickets any way it wishes -- neither "ticket-by-reference" nor
"ticket-by-value" is mandatory. I think we should keep it this
way -- but some parts of the draft probably need some clarification
how it works if "ticket-by-reference" is used.)

Best regards,
Pasi

> -----Original Message-----
> From:  Hui Deng
> Sent: 18 November, 2008 17:19
> To: ipsec@ietf.org
> Subject: [IPsec] draft-ietf-ipsecme-ikev2-resumption-00.txt fragmentation
>
>
> As discussed in the list, the packet to send the ticket may be
> fragmented. When session resumption happened, a large number of the
> client may try to present the ticket at the same time. In this case,
> a bunch of fragmented IP packets will be sent to the gateway. Some
> equipments (such as mobile network GW, firewalls, etc) between
> clients and gateway may be overloaded to handle the IP
> fragment. And, some equipments may treat it as DoS attack and simply
> drop all the fragmented packets.
>
> solution suggest: put the index mandatory, the full IKE sa ticket is
> optional.

------=_Part_57185_24210649.1227025450047-- --===============1858526836== 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 --===============1858526836==-- From ipsec-bounces@ietf.org Tue Nov 18 08:26: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 2086928C1A7; Tue, 18 Nov 2008 08:26:15 -0800 (PST) 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 2F5FD28C1A7 for ; Tue, 18 Nov 2008 08:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.399 X-Spam-Level: X-Spam-Status: No, score=-105.399 tagged_above=-999 required=5 tests=[AWL=1.200, 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 opgPaKHCBE7q for ; Tue, 18 Nov 2008 08:26:13 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 25A9428C17E for ; Tue, 18 Nov 2008 08:26:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1227025572; x=1258561572; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<4922ECA0.3050102@qualcomm.com>|Date:=20Tu e,=2018=20Nov=202008=2008:26:08=20-0800|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Thun derbird=202.0.0.17=20(Windows/20080914)|MIME-Version:=201 .0|To:=20Pasi.Eronen@nokia.com|CC:=20amuhanna@nortel.com, =20ipsec@ietf.org|Subject:=20Re:=20[IPsec]=20Ticket-by-re ference=20and=20protecting=20the=20exchange|References: =20<1696498986EFEC4D9153717DA325CB720251410F@vaebe104.NOE .Nokia.com>=09=20<1696498986EFEC4D9153717DA325C B7202514133@vaebe104.NOE.Nokia.com>|In-Reply-To:=20<16964 98986EFEC4D9153717DA325CB7202514133@vaebe104.NOE.Nokia.co m>|Content-Type:=20text/plain=3B=20charset=3DISO-8859-15 =3B=20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5437"=3B=20 a=3D"13261672"; bh=rAIeMvEAOe7/izT5bhnODRf8mdbOPqxVCvkjhLhgaHI=; b=SKFd+aynKV/UFQtspXpfQ3eec+5ipcM5gtyFHwBcZaj9R8xEanI/dA02 2pl4d1AcOiofiP64qt2OYQvWpLdr61Oae0bDN3Vo2JSPvtVN5TXY6+lfg wkbeklBk081673re2cKt/weYStl6Ogf6NYy1lh+u2rqCjcaMpYbRVwsYS Y=; X-IronPort-AV: E=McAfee;i="5300,2777,5437"; a="13261672" 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; 18 Nov 2008 08:26:12 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAIGQCRt011337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Nov 2008 08:26:12 -0800 Received: from [10.50.76.222] (qconnect-10-50-76-222.qualcomm.com [10.50.76.222]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAIGQ923021333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Nov 2008 08:26:11 -0800 Message-ID: <4922ECA0.3050102@qualcomm.com> Date: Tue, 18 Nov 2008 08:26:08 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <1696498986EFEC4D9153717DA325CB720251410F@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB7202514133@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB7202514133@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org, amuhanna@nortel.com Subject: Re: [IPsec] Ticket-by-reference and protecting the exchange 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 Ok, I see the 'offending' text now: "where SK_d_old is the SK_d value of the original IKE SA, as retrieved from the ticket. " That's true for the gateway (as clarified later in the draft); the client has that state without having to retrieve from the ticket. That's the entire premise. cheers, Lakshminath On 11/18/2008 8:09 AM, Pasi.Eronen@nokia.com wrote: > Hi Ahmed, > > Ah, now I see where the confusion comes from! > > The text should say something like "The key material is derived from > old SK_d as follows: [...] The client has stored the old SK_d > together with the ticket itself. The gateway obtains SK_d either > from the ticket, or from locally stored state." > > The draft doesn't actually say what the client has to store. > I guess the authors assumed it's obvious that the client stores > both the ticket, and it's own IKE_SA state (SK_d, algorithms, > etc.) -- but the draft should of course explicitly say that. > > Best regards, > Pasi > >> -----Original Message----- >> From: ext Ahmad Muhanna [mailto:amuhanna@nortel.com] >> Sent: 18 November, 2008 17:59 >> To: Eronen Pasi (Nokia-NRC/Helsinki); ipsec@ietf.org >> Subject: RE: [IPsec] Ticket-by-reference and protecting the exchange >> >> Thanks Pasi for the explanation. >> >> On the other hand, can you point to the normative text in the draft >> where it captures what you just said. >> Also, the draft include the following text, just as an example: >> >> " >> 4.2.1. Protection of the IKE_SESSION_RESUME Exchange >> >> The key material is derived from the ticket, as follows: >> >> {SK_d2 | SK_ai | SK_ar | SK_ei | SK_er} = prf+(SK_d_old, Ni) >> >> where SK_d_old is the SK_d value of the original IKE SA, >> as retrieved >> from the ticket. Ni guarantees freshness of the key >> material. SK_d2 >> is used later to derive the new IKE SA, see Section 4.5. >> " >> >> How does that fit with what you just mentioned? >> >> Thanks! >> >> Regards, >> Ahmad >> >> >>> -----Original Message----- >>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] >>> On Behalf Of Pasi.Eronen@nokia.com >>> Sent: Tuesday, November 18, 2008 9:53 AM >>> To: ipsec@ietf.org >>> Subject: [IPsec] Ticket-by-reference and protecting the exchange >>> >>> Tough chairs! Here's the answer I was going to say at the >>> microphone: >>> >>> The client does not (and cannot) know whether it's using >>> "ticket-by-value" (where the ticket contains the gateway's >>> state, in encrypted form) or "ticket-by-reference" (where the >>> ticket contains only a pointer to state stored locally by the >>> gateway), or even a combination (some state is in the ticket, >>> some is stored locally). >>> >>> In *addition* to storing the ticket blob, the client has to >>> store the keys from the old IKE_SA (and this is done even if >>> ticket-by-reference is used -- since the client cannot know >>> that). The client uses these keys to protect the resumption >>> exchange. The gateway also needs these keys; it gets them >>> from the ticket, or from its local storage (using the ticket >>> as a pointer). >>> >>> If the gateway is using ticket-by-reference, and there's a >>> cluster of multiple gateways, the cluster members need to >>> communicate somehow (and obviously this communication needs >>> to be secured somehow). >>> This protocol is explicitly beyond the scope of the charter. >>> >>> >>> (BTW, if the gateway uses ticket-by-reference, things work >>> pretty much the same way as draft-xu-ike-sa-sync, except that >>> the terminology is slightly different, and this document >>> doesn't say anything about how multiple gateways communicate, >>> possibly via some database server, called "stub bank" in >>> draft-xu-...). >>> >>> Best regards, >>> Pasi >>> _______________________________________________ >>> 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 > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 18 08:27:52 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 C23B628C1D1; Tue, 18 Nov 2008 08:27:52 -0800 (PST) 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 579C528C1D7 for ; Tue, 18 Nov 2008 08:27:51 -0800 (PST) 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 0SiOI5-VH2SY for ; Tue, 18 Nov 2008 08:27:49 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 7EB7B3A6A30 for ; Tue, 18 Nov 2008 08:27:49 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mAIGRjq27305; Tue, 18 Nov 2008 16:27:45 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 10:27:31 -0600 Message-ID: In-Reply-To: <1696498986EFEC4D9153717DA325CB7202514133@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Ticket-by-reference and protecting the exchange Thread-Index: AclJlcvQh/bLY3mxSneX3JjE8IsQuwAABKxwAABSo0AAAF1IQA== References: <1696498986EFEC4D9153717DA325CB720251410F@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB7202514133@vaebe104.NOE.Nokia.com> From: "Ahmad Muhanna" To: , Subject: Re: [IPsec] Ticket-by-reference and protecting the exchange 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 Pasi, Comments inline. > Subject: RE: [IPsec] Ticket-by-reference and protecting the exchange > > Hi Ahmed, > > Ah, now I see where the confusion comes from! > > The text should say something like "The key material is > derived from old SK_d as follows: [...] The client has > stored the old SK_d together with the ticket itself. The > gateway obtains SK_d either from the ticket, or from locally > stored state." > > The draft doesn't actually say what the client has to store. > I guess the authors assumed it's obvious that the client > stores both the ticket, and it's own IKE_SA state (SK_d, algorithms, > etc.) -- but the draft should of course explicitly say that. [Ahmad] Yes, the whole draft is written with "Ticket with Value" in mind. I believe it needs to have both types in mind. IMO, the changes will be considerable, although mainly clarification of how it works with "Ticket by Reference". BUT, it will introduce new normative text on the client, for example. Because currently the draft allows the client to basically use session resumption at any time. What does this mean to the client? Where the client needs to save the IKE_SA state? In a non-volatile memory? How the lifetime will be saved? etc. Thanks again! Best Regards, Ahmad > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Ahmad Muhanna [mailto:amuhanna@nortel.com] > > Sent: 18 November, 2008 17:59 > > To: Eronen Pasi (Nokia-NRC/Helsinki); ipsec@ietf.org > > Subject: RE: [IPsec] Ticket-by-reference and protecting the exchange > > > > Thanks Pasi for the explanation. > > > > On the other hand, can you point to the normative text in the draft > > where it captures what you just said. > > Also, the draft include the following text, just as an example: > > > > " > > 4.2.1. Protection of the IKE_SESSION_RESUME Exchange > > > > The key material is derived from the ticket, as follows: > > > > {SK_d2 | SK_ai | SK_ar | SK_ei | SK_er} = prf+(SK_d_old, Ni) > > > > where SK_d_old is the SK_d value of the original IKE SA, as > > retrieved > > from the ticket. Ni guarantees freshness of the key material. > > SK_d2 > > is used later to derive the new IKE SA, see Section 4.5. > > " > > > > How does that fit with what you just mentioned? > > > > Thanks! > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > > > Behalf Of Pasi.Eronen@nokia.com > > > Sent: Tuesday, November 18, 2008 9:53 AM > > > To: ipsec@ietf.org > > > Subject: [IPsec] Ticket-by-reference and protecting the exchange > > > > > > Tough chairs! Here's the answer I was going to say at the > > > microphone: > > > > > > The client does not (and cannot) know whether it's using > > > "ticket-by-value" (where the ticket contains the > gateway's state, in > > > encrypted form) or "ticket-by-reference" (where the > ticket contains > > > only a pointer to state stored locally by the gateway), or even a > > > combination (some state is in the ticket, some is stored locally). > > > > > > In *addition* to storing the ticket blob, the client has to store > > > the keys from the old IKE_SA (and this is done even if > > > ticket-by-reference is used -- since the client cannot > know that). > > > The client uses these keys to protect the resumption > exchange. The > > > gateway also needs these keys; it gets them from the > ticket, or from > > > its local storage (using the ticket as a pointer). > > > > > > If the gateway is using ticket-by-reference, and there's > a cluster > > > of multiple gateways, the cluster members need to communicate > > > somehow (and obviously this communication needs to be secured > > > somehow). > > > This protocol is explicitly beyond the scope of the charter. > > > > > > > > > (BTW, if the gateway uses ticket-by-reference, things work pretty > > > much the same way as draft-xu-ike-sa-sync, except that the > > > terminology is slightly different, and this document doesn't say > > > anything about how multiple gateways communicate, > possibly via some > > > database server, called "stub bank" in draft-xu-...). > > > > > > Best regards, > > > Pasi > > > _______________________________________________ > > > 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 Nov 18 08:33: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 806653A69E5; Tue, 18 Nov 2008 08:33:14 -0800 (PST) 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 AD5DC3A69E5 for ; Tue, 18 Nov 2008 08:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, 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 75RcQ9m72mX4 for ; Tue, 18 Nov 2008 08:33:11 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 486853A6808 for ; Tue, 18 Nov 2008 08:33:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1227025991; x=1258561991; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<4922EE3F.4070708@qualcomm.com>|Date:=20Tu e,=2018=20Nov=202008=2008:33:03=20-0800|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Thun derbird=202.0.0.17=20(Windows/20080914)|MIME-Version:=201 .0|To:=20Ahmad=20Muhanna=20|CC:=20Pa si.Eronen@nokia.com,=20ipsec@ietf.org|Subject:=20Re:=20[I Psec]=20Ticket-by-reference=20and=20protecting=20the=20ex change|References:=20<1696498986EFEC4D9153717DA325CB72025 1410F@vaebe104.NOE.Nokia.com>=09=09<1696498986E FEC4D9153717DA325CB7202514133@vaebe104.NOE.Nokia.com>=20< C5A96676FCD00745B64AE42D5FCC9B6E1BC0FA1C@zrc2hxm0.corp.no rtel.com>|In-Reply-To:=20|Content-Type:=20text/ plain=3B=20charset=3DISO-8859-15=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-IronPort-AV:=20E=3DM cAfee=3Bi=3D"5100,188,5437"=3B=20a=3D"13236391"; bh=a7kU0aMpJFgB1QVcHnWXc2Eb+pMckgV9CXiam47ayeA=; b=Vlw+tvaSVoRwEBDauuHDFznP+PNNf6WLUfU3sP3QiYAreZUAOUP/orGc XBqxFz/uPGxTO/DyQlKlo5c5Eqn49zCoqwLPxq/xf+BpmSyAC1ZFZJ8JP SmNCUFD3ZBBYTWz6XIYnjjw2470rhfx+Gmz+ilq8u3waJ1olo3kKavuwK M=; X-IronPort-AV: E=McAfee;i="5100,188,5437"; a="13236391" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Nov 2008 08:33:10 -0800 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAIGXA2o023471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Nov 2008 08:33:10 -0800 Received: from [10.50.76.222] (qconnect-10-50-76-222.qualcomm.com [10.50.76.222]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAIGX3fJ009792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Nov 2008 08:33:09 -0800 Message-ID: <4922EE3F.4070708@qualcomm.com> Date: Tue, 18 Nov 2008 08:33:03 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Ahmad Muhanna References: <1696498986EFEC4D9153717DA325CB720251410F@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB7202514133@vaebe104.NOE.Nokia.com> In-Reply-To: Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com Subject: Re: [IPsec] Ticket-by-reference and protecting the exchange 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 Actually, I am not so sure whether we need to write all that, if indeed the consensus is that we need to be agnostic. How the client manages its IKEv2 and IPsec state is none of the IETF's business really. As Tero pointed out, we made a mistake in saying stuff about lifetime. The current plan is to delete the lifetime stuff to be consistent with 4306. regards, Lakshminath On 11/18/2008 8:27 AM, Ahmad Muhanna wrote: > Hi Pasi, > Comments inline. > >> Subject: RE: [IPsec] Ticket-by-reference and protecting the exchange >> >> Hi Ahmed, >> >> Ah, now I see where the confusion comes from! >> >> The text should say something like "The key material is >> derived from old SK_d as follows: [...] The client has >> stored the old SK_d together with the ticket itself. The >> gateway obtains SK_d either from the ticket, or from locally >> stored state." >> >> The draft doesn't actually say what the client has to store. >> I guess the authors assumed it's obvious that the client >> stores both the ticket, and it's own IKE_SA state (SK_d, algorithms, >> etc.) -- but the draft should of course explicitly say that. > > [Ahmad] > Yes, the whole draft is written with "Ticket with Value" in mind. I > believe it needs to have both types in mind. IMO, the changes will be > considerable, although mainly clarification of how it works with "Ticket > by Reference". BUT, it will introduce new normative text on the client, > for example. > > Because currently the draft allows the client to basically use session > resumption at any time. What does this mean to the client? > > Where the client needs to save the IKE_SA state? In a non-volatile > memory? How the lifetime will be saved? etc. > > Thanks again! > > Best Regards, > Ahmad >> Best regards, >> Pasi >> >>> -----Original Message----- >>> From: ext Ahmad Muhanna [mailto:amuhanna@nortel.com] >>> Sent: 18 November, 2008 17:59 >>> To: Eronen Pasi (Nokia-NRC/Helsinki); ipsec@ietf.org >>> Subject: RE: [IPsec] Ticket-by-reference and protecting the exchange >>> >>> Thanks Pasi for the explanation. >>> >>> On the other hand, can you point to the normative text in the draft >>> where it captures what you just said. >>> Also, the draft include the following text, just as an example: >>> >>> " >>> 4.2.1. Protection of the IKE_SESSION_RESUME Exchange >>> >>> The key material is derived from the ticket, as follows: >>> >>> {SK_d2 | SK_ai | SK_ar | SK_ei | SK_er} = prf+(SK_d_old, Ni) >>> >>> where SK_d_old is the SK_d value of the original IKE SA, as >>> retrieved >>> from the ticket. Ni guarantees freshness of the key material. >>> SK_d2 >>> is used later to derive the new IKE SA, see Section 4.5. >>> " >>> >>> How does that fit with what you just mentioned? >>> >>> Thanks! >>> >>> Regards, >>> Ahmad >>> >>> >>>> -----Original Message----- >>>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >>>> Behalf Of Pasi.Eronen@nokia.com >>>> Sent: Tuesday, November 18, 2008 9:53 AM >>>> To: ipsec@ietf.org >>>> Subject: [IPsec] Ticket-by-reference and protecting the exchange >>>> >>>> Tough chairs! Here's the answer I was going to say at the >>>> microphone: >>>> >>>> The client does not (and cannot) know whether it's using >>>> "ticket-by-value" (where the ticket contains the >> gateway's state, in >>>> encrypted form) or "ticket-by-reference" (where the >> ticket contains >>>> only a pointer to state stored locally by the gateway), or even a >>>> combination (some state is in the ticket, some is stored locally). >>>> >>>> In *addition* to storing the ticket blob, the client has to store >>>> the keys from the old IKE_SA (and this is done even if >>>> ticket-by-reference is used -- since the client cannot >> know that). >>>> The client uses these keys to protect the resumption >> exchange. The >>>> gateway also needs these keys; it gets them from the >> ticket, or from >>>> its local storage (using the ticket as a pointer). >>>> >>>> If the gateway is using ticket-by-reference, and there's >> a cluster >>>> of multiple gateways, the cluster members need to communicate >>>> somehow (and obviously this communication needs to be secured >>>> somehow). >>>> This protocol is explicitly beyond the scope of the charter. >>>> >>>> >>>> (BTW, if the gateway uses ticket-by-reference, things work pretty >>>> much the same way as draft-xu-ike-sa-sync, except that the >>>> terminology is slightly different, and this document doesn't say >>>> anything about how multiple gateways communicate, >> possibly via some >>>> database server, called "stub bank" in draft-xu-...). >>>> >>>> Best regards, >>>> Pasi >>>> _______________________________________________ >>>> 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 > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 18 08:33:56 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 178E13A6AEE; Tue, 18 Nov 2008 08:33:56 -0800 (PST) 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 7AB9E3A6AA9 for ; Tue, 18 Nov 2008 08:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.435 X-Spam-Level: X-Spam-Status: No, score=-6.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 yFIod9Tr+r-b for ; Tue, 18 Nov 2008 08:33:53 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id C2BA73A6AB7 for ; Tue, 18 Nov 2008 08:33:52 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mAIGXcUu017506; Tue, 18 Nov 2008 18:33:49 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 18:33:46 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 18:33:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 18:33:45 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB720251415D@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Ticket-by-reference and protecting the exchange Thread-Index: AclJlcvQh/bLY3mxSneX3JjE8IsQuwAABKxwAABSo0AAAF1IQAAAlO6A References: <1696498986EFEC4D9153717DA325CB720251410F@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB7202514133@vaebe104.NOE.Nokia.com> From: To: , X-OriginalArrivalTime: 18 Nov 2008 16:33:45.0898 (UTC) FILETIME=[6D4840A0:01C9499B] X-Nokia-AV: Clean Subject: Re: [IPsec] Ticket-by-reference and protecting the exchange 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 Ahmad Muhanna wrote: > Yes, the whole draft is written with "Ticket with Value" in mind. I > believe it needs to have both types in mind. IMO, the changes will > be considerable, although mainly clarification of how it works with > "Ticket by Reference". BUT, it will introduce new normative text on > the client, for example. > > Because currently the draft allows the client to basically use session > resumption at any time. What does this mean to the client? > > Where the client needs to save the IKE_SA state? In a non-volatile > memory? How the lifetime will be saved? etc. I agree that more text and clarifications is needed, but I don't think it's related to ticket-with-value vs. ticket-by-reference. The client does not know whether the gateway is using ticket-with-value or ticket-by-reference, so it behaves exactly the same way in both cases. For example, the client needs to save its own IKE_SA state in both cases. Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 18 08:37:56 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 AD3EB3A69E5; Tue, 18 Nov 2008 08:37:56 -0800 (PST) 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 B4E3A3A68D0 for ; Tue, 18 Nov 2008 08:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.443 X-Spam-Level: X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 9fIdH1hj2jW9 for ; Tue, 18 Nov 2008 08:37:54 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 2C5F93A68A9 for ; Tue, 18 Nov 2008 08:37:54 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mAIGbZdH018702; Tue, 18 Nov 2008 18:37:51 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 18:37:46 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 18:37:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 18:37:46 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB7202514164@vaebe104.NOE.Nokia.com> In-Reply-To: <4922EE3F.4070708@qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Ticket-by-reference and protecting the exchange Thread-Index: AclJm1twauY+Oro0RF2sC1OrMPH63wAABz/Q References: <1696498986EFEC4D9153717DA325CB720251410F@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB7202514133@vaebe104.NOE.Nokia.com> <4922EE3F.4070708@qualcomm.com> From: To: , X-OriginalArrivalTime: 18 Nov 2008 16:37:46.0517 (UTC) FILETIME=[FCB3CC50:01C9499B] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] Ticket-by-reference and protecting the exchange 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 Hmm... I think we probably need some text clarifying what the client stores (the ticket and its own IKE_SA state) and advice saying this shouldn't be stored forever, and such. But much of that text wouldn't be normative in nature. Best regards, Pasi > -----Original Message----- > From: ext Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > Sent: 18 November, 2008 18:33 > To: Ahmad Muhanna > Cc: Eronen Pasi (Nokia-NRC/Helsinki); ipsec@ietf.org > Subject: Re: [IPsec] Ticket-by-reference and protecting the exchange > > Actually, I am not so sure whether we need to write all that, if > indeed the consensus is that we need to be agnostic. > > How the client manages its IKEv2 and IPsec state is none of the > IETF's business really. As Tero pointed out, we made a mistake in > saying stuff about lifetime. The current plan is to delete the > lifetime stuff to be consistent with 4306. > > regards, > Lakshminath > > On 11/18/2008 8:27 AM, Ahmad Muhanna wrote: > > Hi Pasi, > > Comments inline. > > > >> Subject: RE: [IPsec] Ticket-by-reference and protecting > the exchange > >> > >> Hi Ahmed, > >> > >> Ah, now I see where the confusion comes from! > >> > >> The text should say something like "The key material is > >> derived from old SK_d as follows: [...] The client has > >> stored the old SK_d together with the ticket itself. The > >> gateway obtains SK_d either from the ticket, or from locally > >> stored state." > >> > >> The draft doesn't actually say what the client has to store. > >> I guess the authors assumed it's obvious that the client > >> stores both the ticket, and it's own IKE_SA state (SK_d, > algorithms, > >> etc.) -- but the draft should of course explicitly say that. > > > > [Ahmad] > > Yes, the whole draft is written with "Ticket with Value" in mind. I > > believe it needs to have both types in mind. IMO, the > changes will be > > considerable, although mainly clarification of how it works > with "Ticket > > by Reference". BUT, it will introduce new normative text on > the client, > > for example. > > > > Because currently the draft allows the client to basically > use session > > resumption at any time. What does this mean to the client? > > > > Where the client needs to save the IKE_SA state? In a non-volatile > > memory? How the lifetime will be saved? etc. > > > > Thanks again! > > > > Best Regards, > > Ahmad > >> Best regards, > >> Pasi > >> > >>> -----Original Message----- > >>> From: ext Ahmad Muhanna [mailto:amuhanna@nortel.com] > >>> Sent: 18 November, 2008 17:59 > >>> To: Eronen Pasi (Nokia-NRC/Helsinki); ipsec@ietf.org > >>> Subject: RE: [IPsec] Ticket-by-reference and protecting > the exchange > >>> > >>> Thanks Pasi for the explanation. > >>> > >>> On the other hand, can you point to the normative text in > the draft > >>> where it captures what you just said. > >>> Also, the draft include the following text, just as an example: > >>> > >>> " > >>> 4.2.1. Protection of the IKE_SESSION_RESUME Exchange > >>> > >>> The key material is derived from the ticket, as follows: > >>> > >>> {SK_d2 | SK_ai | SK_ar | SK_ei | SK_er} = > prf+(SK_d_old, Ni) > >>> > >>> where SK_d_old is the SK_d value of the original IKE SA, as > >>> retrieved > >>> from the ticket. Ni guarantees freshness of the key > material. > >>> SK_d2 > >>> is used later to derive the new IKE SA, see Section 4.5. > >>> " > >>> > >>> How does that fit with what you just mentioned? > >>> > >>> Thanks! > >>> > >>> Regards, > >>> Ahmad > >>> > >>> > >>>> -----Original Message----- > >>>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > >>>> Behalf Of Pasi.Eronen@nokia.com > >>>> Sent: Tuesday, November 18, 2008 9:53 AM > >>>> To: ipsec@ietf.org > >>>> Subject: [IPsec] Ticket-by-reference and protecting the exchange > >>>> > >>>> Tough chairs! Here's the answer I was going to say at the > >>>> microphone: > >>>> > >>>> The client does not (and cannot) know whether it's using > >>>> "ticket-by-value" (where the ticket contains the > >> gateway's state, in > >>>> encrypted form) or "ticket-by-reference" (where the > >> ticket contains > >>>> only a pointer to state stored locally by the gateway), > or even a > >>>> combination (some state is in the ticket, some is stored > locally). > >>>> > >>>> In *addition* to storing the ticket blob, the client has > to store > >>>> the keys from the old IKE_SA (and this is done even if > >>>> ticket-by-reference is used -- since the client cannot > >> know that). > >>>> The client uses these keys to protect the resumption > >> exchange. The > >>>> gateway also needs these keys; it gets them from the > >> ticket, or from > >>>> its local storage (using the ticket as a pointer). > >>>> > >>>> If the gateway is using ticket-by-reference, and there's > >> a cluster > >>>> of multiple gateways, the cluster members need to communicate > >>>> somehow (and obviously this communication needs to be secured > >>>> somehow). > >>>> This protocol is explicitly beyond the scope of the charter. > >>>> > >>>> > >>>> (BTW, if the gateway uses ticket-by-reference, things > work pretty > >>>> much the same way as draft-xu-ike-sa-sync, except that the > >>>> terminology is slightly different, and this document doesn't say > >>>> anything about how multiple gateways communicate, > >> possibly via some > >>>> database server, called "stub bank" in draft-xu-...). > >>>> > >>>> Best regards, > >>>> Pasi > >>>> _______________________________________________ > >>>> 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 > > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 18 08:41: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 05AA43A6B01; Tue, 18 Nov 2008 08:41:46 -0800 (PST) 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 D89B328C163 for ; Tue, 18 Nov 2008 08:41:44 -0800 (PST) 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=[AWL=0.000, 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 LajtE6iFmPyg for ; Tue, 18 Nov 2008 08:41:44 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id CBFB128C13D for ; Tue, 18 Nov 2008 08:41:43 -0800 (PST) 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 mAIGfcY07190; Tue, 18 Nov 2008 16:41:38 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 10:41:27 -0600 Message-ID: In-Reply-To: <1696498986EFEC4D9153717DA325CB720251415D@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Ticket-by-reference and protecting the exchange Thread-Index: AclJlcvQh/bLY3mxSneX3JjE8IsQuwAABKxwAABSo0AAAF1IQAAAlO6AAAAegwA= References: <1696498986EFEC4D9153717DA325CB720251410F@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB7202514133@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB720251415D@vaebe104.NOE.Nokia.com> From: "Ahmad Muhanna" To: , Subject: Re: [IPsec] Ticket-by-reference and protecting the exchange 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 > > Ahmad Muhanna wrote: > > > Yes, the whole draft is written with "Ticket with Value" in mind. I > > believe it needs to have both types in mind. IMO, the > changes will be > > considerable, although mainly clarification of how it works with > > "Ticket by Reference". BUT, it will introduce new normative text on > > the client, for example. > > > > Because currently the draft allows the client to basically > use session > > resumption at any time. What does this mean to the client? > > > > Where the client needs to save the IKE_SA state? In a non-volatile > > memory? How the lifetime will be saved? etc. > > I agree that more text and clarifications is needed, but I > don't think it's related to ticket-with-value vs. ticket-by-reference. > > The client does not know whether the gateway is using > ticket-with-value or ticket-by-reference, so it behaves > exactly the same way in both cases. For example, the client > needs to save its own IKE_SA state in both cases. [Ahmad] Agreed; I am using this to clarify my point:) But seems that we are in agreement that at least the draft needs to be clarified and most importantly be consistent throughout. I will share my rest of the comments when I have a chance. > > Best regards, > Pasi > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 18 08:49: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 6AE9728C232; Tue, 18 Nov 2008 08:49:16 -0800 (PST) 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 DCA5528C1F1 for ; Tue, 18 Nov 2008 08:49:14 -0800 (PST) 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 LWb+j4XGw9zk for ; Tue, 18 Nov 2008 08:49:14 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by core3.amsl.com (Postfix) with ESMTP id 7D60B3A6808 for ; Tue, 18 Nov 2008 08:49:13 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id b11so1521423nfh.39 for ; Tue, 18 Nov 2008 08:49:12 -0800 (PST) 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=7uFWaZlhTsO0bJpoijfYp0hDwd/j5SK86TgTBSvUwP4=; b=ln2JSzYpuir88g1ZZ5Xp0wy9QWT3l1GktBDSDed2BUYmrc1NcVaqPAu0ylUHVvDlm6 4ejgKp0IGgonbj2958qqd7HRIYz9AghwEDaTbpKzSbjiDXQiscoTme0r6+JR+LLmFoCN Km2dmv7j6h8tIh7U5hriWTAuBZ1aeAbmBXexw= 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=Dgo0gN6B94GClvgwufVxU0WIOrZQIFUsZCM9CeUBGU1dzGnDNBwVnV7bXc/q+anPjI PHpbE7Rst7aRFwidSS26iDhrVohBkjjjoWrBL1HNou2I8DTNnY4GhGMy/xn8J/R/XsAM /WIkv1cALRgMyg432DCmGIvad3AI4LHCmHyUQ= Received: by 10.210.41.1 with SMTP id o1mr27752ebo.169.1227026952090; Tue, 18 Nov 2008 08:49:12 -0800 (PST) Received: by 10.210.109.14 with HTTP; Tue, 18 Nov 2008 08:49:12 -0800 (PST) Message-ID: <1d38a3350811180849ja11ec49g6507cfc72f9d10b0@mail.gmail.com> Date: Wed, 19 Nov 2008 00:49:12 +0800 From: "Hui Deng" To: "Dan Harkins" In-Reply-To: <9722bf5f8d04560abcd678625e398c42.squirrel@www.trepanning.net> MIME-Version: 1.0 References: <1d38a3350811172207m1801bf77ra4518f06deb61207@mail.gmail.com> <7C69DECB-BB75-43BA-ABED-6DB5DB648791@checkpoint.com> <1d38a3350811180713p3e1b7849g9f50e0a6e66cf709@mail.gmail.com> <9722bf5f8d04560abcd678625e398c42.squirrel@www.trepanning.net> Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-resumption-00.txt ticket location 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="===============1159598083==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1159598083== Content-Type: multipart/alternative; boundary="----=_Part_57482_30207123.1227026952102" ------=_Part_57482_30207123.1227026952102 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline see below inline. 2008/11/18 Dan Harkins > > Hello, > > On Tue, November 18, 2008 7:13 am, Hui Deng wrote: > > 2008/11/18 Yoav Nir > > > [snip] > >> I understand that resumption may have severe implications for the core > >> network - lots of simultaneous IKE traffic, but aren't the clients > >> supposed > >> to be spread out among very many base stations? I didn't think there > >> should > >> be congestion at the base stations. > > > > it depends on how to express it, mostly congestion will happen in > security > > gateway or firewall, sometime it also lead to the congestion at the base > > station. it depends on how many subscribers under this base station, how > > could the signaling channel of this base station to handle this. Anyway, > I > > think this issue exists. > > It should not matter what traffic the subscribers are sending. If the > base station does not have trouble supporting them while they send random > data traffic then it will not have trouble supporting them when they > initiate IKE session resumption. If it is having trouble supporting them > when they initiate IKE session resumption then you have problems at your > base station that have nothing to do with IKE session resumption. Current base station are handling fragmentation as a critical issue. during the session resumption, fragmentition could ead it to die. -Hui > > Dan. > > ------=_Part_57482_30207123.1227026952102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline see below inline.

2008/11/18 Dan Harkins <dharkins@lounge.org>

 Hello,

On Tue, November 18, 2008 7:13 am, Hui Deng wrote:
> 2008/11/18 Yoav Nir <ynir@checkpoint.com>
>
[snip]
>> I understand that resumption may have severe implications for the core
>> network - lots of simultaneous IKE traffic, but aren't the clients
>> supposed
>> to be spread out among very many base stations?  I didn't think there
>> should
>> be congestion at the base stations.
>
> it depends on how to express it, mostly congestion will happen in security
> gateway or firewall, sometime it also lead to the congestion at the base
> station. it depends on how many subscribers under this base station, how
> could the signaling channel of this base station to handle this. Anyway, I
> think this issue exists.

 It should not matter what traffic the subscribers are sending. If the
base station does not have trouble supporting them while they send random
data traffic then it will not have trouble supporting them when they
initiate IKE session resumption. If it is having trouble supporting them
when they initiate IKE session resumption then you have problems at your
base station that have nothing to do with IKE session resumption.
Current base station are handling fragmentation as a critical issue.
during the session resumption, fragmentition could ead it to die.
 
-Hui
 
 

 Dan.


------=_Part_57482_30207123.1227026952102-- --===============1159598083== 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 --===============1159598083==-- From ipsec-bounces@ietf.org Tue Nov 18 11:15: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 2D7563A6B0B; Tue, 18 Nov 2008 11:15:05 -0800 (PST) X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EE07F3A6407; Tue, 18 Nov 2008 11:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081118191501.EE07F3A6407@core3.amsl.com> Date: Tue, 18 Nov 2008 11:15:01 -0800 (PST) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-ipv6-config-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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : IPv6 Configuration in IKEv2 Author(s) : P. Eronen, et al. Filename : draft-ietf-ipsecme-ikev2-ipv6-config-00.txt Pages : 36 Date : 2008-11-18 When IKEv2 is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC 4306 work well for IPv4, but make it difficult to use certain features of IPv6. This document describes the limitations of current IKEv2 configuration payloads for IPv6, and explores possible solutions that would allow IKEv2 to set up full- featured virtual IPv6 interfaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-ipv6-config-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. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2-ipv6-config-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-18111154.I-D@ietf.org> --NextPart 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 --NextPart-- From ipsec-bounces@ietf.org Tue Nov 18 12:15: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 A22DB3A69E5; Tue, 18 Nov 2008 12:15:21 -0800 (PST) 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 7AE283A67D6 for ; Tue, 18 Nov 2008 12:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 tRbdI-VHXo7r for ; Tue, 18 Nov 2008 12:15:19 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 397C73A69E5 for ; Tue, 18 Nov 2008 12:15:17 -0800 (PST) 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 mAIKF9Y6029110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 22:15:09 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mAIKF9Tb004698; Tue, 18 Nov 2008 22:15:09 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18723.8781.499111.51370@fireball.kivinen.iki.fi> Date: Tue, 18 Nov 2008 22:15:09 +0200 From: Tero Kivinen To: "Peny Yang" In-Reply-To: <4c5c7a6d0811172219j96ce787qd265ded48f4c60b6@mail.gmail.com> References: <4c5c7a6d0811172219j96ce787qd265ded48f4c60b6@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 19 min X-Total-Time: 20 min Cc: ipsec@ietf.org Subject: [IPsec] Comment on draft-ietf-ipsecme-ikev2-resumption-00 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 Peny Yang writes: > In the draft, the new IKE_SESSION_RESUME is defined to present ticket > from client gateway for session resumption. > However, this need to modify IKEv2 base protocol by new messages and > related protection of them. From the implementation point of view, we > do not think this modification is small. As an IKEv2 implementor I think having separate IKE_SESSION_RESUME exchange actually makes the changes easier to do, than to go and modify the existing IKE_SA_INIT AND IKE_SA_AUTH state machines. The state machines of the IKE_SA_INIT and especially IKE_SA_AUTH are already quite complicated because of the EAP, and other options and especially even more when someone starts to implement things like RFC4739 in which case the state machine and especially the policy gets extremely complicated... > And, when we consider the case that the session resumption can not be > continued by the gateway, gateway will reject this message. Then, the > regular IKEv2 procedure will be done afterwards. In this case, at > least one round trip is wasted. Yes, but I do not think that case is that common case. I think the most common case will be the case when gateway still has the ticket and will accept it, thus we need to optimize for it. If the gateway do not have ticket anymore, that means we need to do Diffie-Hellman, which quite often takes more time than the one round trip. > Add a payload in the IKE INIT message for client to present the index > of ticket to GW. Then if GW can not do the session resumption for some > reason, it just sends the IKE INIT response to clients and starts the > regular IKEv2 initiation procedure. IMHO, this way is more efficient > and flexible. Note, that in this case the client needs to do Diffie-Hellman setup before it can even see if the server has ticket still valid or not. This will waste resources on the client, and will consume power and so on in the mobile devices. Also the packets gets quite big, as they need to include all things that can be in the IKE_SA_INIT (i.e. KE payload etc), and the ticket itself, and also some encrypted information to proof that client do have the keying material still. So the minimum version of that packet would look like: HDR, SAi1, KEi, Ni, N(TICKET_OPAQUE), SK { IDi } -> Hmm... the draft does not actually say, but I think the current idea is that all IPsec SAs are removed when resumption happens, and they need to be rekeyed, which is why the current IKE_SESSION_RESUME exchange has payloads required for the one child sa creation, i.e. where the first packet would be: HDR, SAi1, KEi, Ni, N(TICKET_OPAQUE), SK { IDi, [IDr,] SAi2, TSi, TSr, CP(...) } so its starts to get quite large. Note, that it now also has two SA payloads and so on, which will again add more complications as implementations must keep in mind which SA payload was outside the encryption and which inside etc. Now if the ticket is still valid, then client has wasted its cpu resources by calculating the Diffie-Hellman value it sent in as KEi, the bandwidth between the peers was wasted by sending SAi1, and KEi payloads (KEi is the largest payload in normal exchange). I think the current approach in the draft is better and simplier. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 18 12:18:33 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 CE2C43A6AFE; Tue, 18 Nov 2008 12:18:33 -0800 (PST) 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 299423A6AFE for ; Tue, 18 Nov 2008 12:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 p-rp+D80MB7H for ; Tue, 18 Nov 2008 12:18:31 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 011203A68C4 for ; Tue, 18 Nov 2008 12:18:30 -0800 (PST) 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 mAIKISRb026440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 22:18:28 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mAIKISo2025455; Tue, 18 Nov 2008 22:18:28 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18723.8980.618823.932016@fireball.kivinen.iki.fi> Date: Tue, 18 Nov 2008 22:18:28 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Subject: [IPsec] Identities in the draft-ietf-ipsecme-ikev2-resumption 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 Why does the resumption has the IDi and IDr payloads? I think it would be easier to take them directly from the ticket, thus why are they transmitted in the IKE_SESSION_RESUME case? What happens if the IDi sent does not match the one in the ticket? Changing the IDr on the fly for existing IKE SA requires the responder side to redo all policy lookups, i.e. it can not just assume that policy lookup done when the IKE SA was originally created is ok, and reuse those. I would remove both of them from the IKE_SESSION_RESUME exchange. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 18 12:23:43 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 696A528C23C; Tue, 18 Nov 2008 12:23:43 -0800 (PST) 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 8E8E728C23C for ; Tue, 18 Nov 2008 12:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 KoihOp0YKTEC for ; Tue, 18 Nov 2008 12:23:41 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 8423728C0E8 for ; Tue, 18 Nov 2008 12:23:41 -0800 (PST) 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 mAIKNduH000894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Nov 2008 22:23:39 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mAIKNdAB024687; Tue, 18 Nov 2008 22:23:39 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18723.9291.347037.490192@fireball.kivinen.iki.fi> Date: Tue, 18 Nov 2008 22:23:39 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 5 min Subject: [IPsec] IPsec child SAs and draft-ietf-ipsecme-ikev2-resumption-00 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 The current document does not say what happens to the old IPsec child SAs that might still be there for the old IKE SA. I.e. if the IKE SA i still valid in the server when client does IKE_SESSION_RESUME the draft says the old IKE SA is deleted without sending delete notification. So I assume no old IPsec child SAs are valid on the responder end regardless whether the old IKE SA was valid or not. I think we also need text explictly mentioning this, i.e. saying that as IKE_SESSION_RESUME is started only AFTER the IKE SA has already been destroyed because of the timeouts, all the IPsec child SAs are already deleted before IKE_SESSION_RESUME is started, which means all IPsec child SAs needs to be recreated for the new IKE SA (i.e. first IPsec child SA can be done inside the IKE_SESSION_RESUME, rest are created with separete CREATE_CHILD_SA exchanges in the new IKE SA). -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 18 12:56: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 52D0F3A6B1C; Tue, 18 Nov 2008 12:56:32 -0800 (PST) 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 9D3B53A6B1C for ; Tue, 18 Nov 2008 12:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 tWEoUDMB60B2 for ; Tue, 18 Nov 2008 12:56:30 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id BD2313A6A24 for ; Tue, 18 Nov 2008 12:56:29 -0800 (PST) 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 mAIKuDQ0021714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 22:56:13 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mAIKuCM1028005; Tue, 18 Nov 2008 22:56:12 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18723.11244.118192.514010@fireball.kivinen.iki.fi> Date: Tue, 18 Nov 2008 22:56:12 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: <3EB07ACE-3428-4C63-BA7A-9DC1F9A5A296@checkpoint.com> References: <4B18A8F75A6384449755BC7784073E935F6AB05D35@exch11.olympus.f5net.com> <3EB07ACE-3428-4C63-BA7A-9DC1F9A5A296@checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 18 min X-Total-Time: 20 min Cc: "ipsec@ietf.org" , Jeff Bellamy , Amit Jain , Ryan Korock , James Goodwin Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-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 Yoav Nir writes: > > - How much change to silicon (cost to chip vendors) is > > required to support the additional XESP header and new protocol > > number? This must be widely supported by IPSec silicon vendors for > > this proposal to succeed. > > It's not a lot of change to silicon, and the chip vendors should have > no problem doing this for the next release. The problem is with > already deployed devices such as routers and firewalls, that would not > recognize this new protocol. Support can still be added with software > or rulebase, but it does mean that such traffic may go on the slow > path on intermediary devices. That is one reason why some participants > don't want a "new ESP" One of the problems is that updating all the end nodes is EXTREMELY costly. We can see that from IPv6. IPv6 was change in the IP that did require updating all end-nodes and all intermediate nodes to work. NAT on the other hand was solution to the same problem (running out of IP-numbers) that only required updating/adding middle boxes. I assume we all (unfortunately) can see which one of those was much faster to spread out. New esp or XESP or WESP do require end nodes and some middle boxes (which want to do those deep inspections) updated. It does not require all middle boxes which do not do anything for the ESP traffic to be changed (i.e. routers do not need to be updated, so it is cheaper to implement than IPv6). Anyways the cost is really in the end node updates. It is really hard when you need to update few million end node devices in the network in addition to updating few dozen deep inspection boxes in the network. Heuristics methods are something that can be implemented and taken in use now, only box that needs to be updated is the middle box doing the deep inspection, and that is not really a box requiring updating, but a box that needs to be added, as there is no way to do that now... People complain that heuristics are just probabilistics, but so is MAC in the ESP header. It has probability of 2^96 that it will detect errors in the packet. If your deep inspection box checks the actual http url / and headers in the http requiest, you are checking much more than 96 bits of the packet, which means that random encrypted packet to pass that check will have much smaller probability than the 1 out of 2^96 that message authentication code in the ESP gives... The ESP header has self-describing padding that will immediately give you from 1 out of 2^16 up to 1 out of 2^64 probability that you can detect packet is ESP NULL compared to the encrypted ESP packet (the probability depends how many bytes of padding you have from 1 to 7 + the padding length). After that you can start checking other things like TCP header fields, UDP port numbers etc (you might not be able to the TCP or UDP checksums as if the packet went through NAT those checksums are wrong, but on the other hand they only give 16 checked bits more). If the packet happens to be tunnel mode IP packet you have full IP-header inside, which has lots of bits you can check. If you are talking about stateful filtering or deep inspection there is lots of bits you are checking. Also as each packet has SPI you can run the heuristics ones and then store information about the SPI (i.e. encrypted data or ESP-NULL) to that SPI. I wrote this pseudocode for the heuristics methods earlier, but run out of time to finish it (it still needs to be checked if it needs any changes for IPv6, and write some most common stateful firewall checking things (i.e. tcp flows, UDP flows etc)): ---------------------------------------------------------------------- Process IPv4 packet: * If IP protocol is ESP * Set SPI_offset to 0 bytes * Goto Process ESP * If IP protocol is UDP * Goto Process UDP * Continue Non-ESP processing Process UDP: * If dst port != 4500 * Continue Non-ESP processing * Set SPI_offset to 8 bytes * If UDP_len > 4 and first 4 bytes of UDP packet are 0x000000 * Continue Non-ESP processing (pass IKE-packet) * If UDP_len == 1 and first byte is 0xff * Continue Non-ESP processing (pass NAT-Keepalive Packet) * Goto Process ESP Process ESP: * If packet is fragment * Do full reassembly before processing * If IP_total_len < IP_hdr_len + SPI_offset + 4 * Drop invalid packet * Load SPI from IP_hdr_len + SPI_offset * Find Dst IP + SPI from SPI cache * If SPI found * Load IV_len, ICV_len from cache * If SPI not found * Goto Autodetect ESP parameters (drop to slowpath) * Goto Check ESP-NULL packet Check ESP-NULL packet: * If IP_total_len < IP_hdr_len + SPI_offset + IV_len + ICV_len + 4 (spi) + 4 (seq no) + 4 (protocol + padding) * Drop invalid packet * Load Protocol from IP_total_len - ICV_len - 1 * Set Protocol_start_offset to IP_hdr_len + SPI_offset + IV_len + 4 (spi) + 4 (seq no) * Do normal deep inspection on packet. Autodetect ESP parameters * Goto Try standard algorithms * If Success * Goto Store SPI cache info * Goto Try 128bit algorithms * If Success * Goto Store SPI cache info * Goto Try 192bit algorithms * If Success * Goto Store SPI cache info * Goto Try 256bit algorithms * If Success * Goto Store SPI cache info * Goto Try 160bit algorithms * If Success * Goto Store SPI cache info # No idea how to test AUTH_DES_MAC and AUTH_KPDK_MD5 as they are # not defined anywhere * Drop invalid ESP-NULL packet Store SPI cache info: * Store IV_len, ICV_len to SPI cache using Dst IP + SPI as key * Goto Check ESP-NULL packet Try standard algorithms: # AUTH_HMAC_MD5_96, AUTH_HMAC_SHA1_96, AUTH_AES_XCBC_96, # AUTH_AES_CMAC_96 * Set ICV_len to 12, IV_len to 0 * Goto Check packet Try 128bit algorithms: # AUTH_HMAC_MD5_128, AUTH_HMAC_SHA2_256_128 # AUTH_AES_128_GMAC, AUTH_AES_192_GMAC, AUTH_AES_256_GMAC * Set ICV_len to 16, IV_len to 0 * If verify padding fails * Return Failure * If verify packet fails * Goto Try GMAC * Return Success Try GMAC: # AUTH_AES_128_GMAC, AUTH_AES_192_GMAC, AUTH_AES_256_GMAC * Set IV_len to 8 * If verify packet fails * Return Failure * Return Success Try 192bit algorithms: # AUTH_HMAC_SHA2_384_192 * Set ICV_len to 24, IV_len to 0 * Goto Check packet Try 256bit algorithms: # AUTH_HMAC_SHA2_512_256 * Set ICV_len to 32, IV_len to 0 * Goto Check packet Try 160bit algorithms: # AUTH_HMAC_SHA1_160 * Set ICV_len to 20, IV_len to 0 * Goto Check packet Check packet: * If IP_total_len < IP_hdr_len + SPI_offset + IV_len + ICV_len + 4 (spi) + 4 (seq no) + 4 (protocol + padding) * Return Failure * If Verify padding fails * Return Failure * If Verify packet fails * Return Failure * Return Success Verify padding: * Load Pad_len from IP_total_len - ICV_len - 2 * Verify padding bytes at IP_total_len - ICV_len - 1 - Pad_len .. IP_total_len - ICV_len - 2 are 1, 2, ..., Pad_len * If Success * Return Success * Return Failure Verify packet: # We can be quite conservative here, i.e. if packet looks any bit of # suspicious we can simply return failure, and wait for better # packet for heuristics, i.e. for example we might refuse # heuristic based on ICMP or UDP packets, and wait for the # TCP packet to existing connection, or any packet where we can do # bit more deeper inspection. # Normally this thing is only run once at startup, thus some packets # have already been lost and most likely all flow information # is already lost too, thus if we do not allow for example TCP # packets without existing flows to go through, we can simply wait # here either for TCP packet to existing flow or new TCP connection # attempt. # Other case when this is called is when SA is rekeyed, i.e. gets # new SPI, but in that case the TCP flows etc are intact, thus # packets going through should match existing flows. * Load Protocol From IP_total_len - ICV_len - 1 * If Protocol TCP * Goto Verify TCP * If Protocol UDP * Goto Verify UDP * If Protocol ICMP * Goto Verify ICMP # Other protocols can be added here as needed, most likely same # protocols as deep inspection does Verify TCP: # Note, we cannot verify TCP checksum as it might be incorrect after # NAT. # Do normal deep TCP inspection here, but do not drop the packet on # failure, just return failure. On success update state and return # success. * If this is new TCP connection * Verify port numbers, window size, tcp header length, reserved bits, flags, urgent pointer * If everything ok * Add half open connection to TCP state table, return success * If this is existing TCP connection * Find src/dst IP/port from TCP flows table * Verify TCP header data * If everything ok * Return Success * Return failure Verify UDP: # Note, we cannot verify UDP checksum as it might be incorrect after # NAT. # Do normal deep UDP inspection here, but do not drop the packet on # failure, just return failure. On success update state and return # success. * Find src/dst IP/port from UDP flows table * If UDP connection is found * Verify packet based on the existing flow * If everything ok * Return Success * If no UDP connection found * Verify new connection creation * If everything ok * Return Success * Return failure Verify ICMP: # Do similar ICMP verification here. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 18 13: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 A4D6A3A6B27; Tue, 18 Nov 2008 13:00:49 -0800 (PST) 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 58FC83A682A for ; Tue, 18 Nov 2008 13:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.312 X-Spam-Level: X-Spam-Status: No, score=-1.312 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] 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 XfBPROxUjFNc for ; Tue, 18 Nov 2008 13:00:47 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 875573A6B26 for ; Tue, 18 Nov 2008 13:00:37 -0800 (PST) Received: (qmail invoked by alias); 18 Nov 2008 21:00:34 -0000 Received: from unknown (EHLO 4FIL42860) [130.129.31.217] by mail.gmx.net (mp011) with SMTP; 18 Nov 2008 22:00:34 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18O3IUN+aYOJEMM2NktZnbgWYlP+m7qFLJoitbpsk QPl6tKumY/VaoX From: "Hannes Tschofenig" To: "'Hui Deng'" , "'Yoav Nir'" References: <1d38a3350811172207m1801bf77ra4518f06deb61207@mail.gmail.com><7C69DECB-BB75-43BA-ABED-6DB5DB648791@checkpoint.com> <1d38a3350811180713p3e1b7849g9f50e0a6e66cf709@mail.gmail.com> Date: Tue, 18 Nov 2008 15:00:30 +0200 Message-ID: <014901c9497d$a50ad520$d91f8182@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclJkDnDIzx8lJs4Tz2nshOejfZDTQAE05Mg In-Reply-To: <1d38a3350811180713p3e1b7849g9f50e0a6e66cf709@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.77 Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-resumption-00.txt ticketlocation 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 I am a bit confused about the performance restrictions of cellular systems that are being described. Given that the IKEv2 exchanges are infrequent and that the ticket size is indeed small I was wondering what type of environment we are talking about where it comes to overload situations at base stations with a ticket. I guess in such an environment it would be difficult to download a webpage or anything else. I would like to learn a bit more about the environments we are talking about. Irrespectively of that question I am wondering why this is an issue at all given that the draft does not mandate a specific format (neither ticket nor reference). Nothing additional needs to be standardized from that point of view. Ciao Hannes ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Hui Deng Sent: 18 November, 2008 17:13 To: Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-resumption-00.txt ticketlocation 2008/11/18 Yoav Nir Hi Hui, On Nov 18, 2008, at 8:07 AM, Hui Deng wrote: Hello, authors, After reading your draft and rethinking of the main issues, I would like to raise one issue about ticket location issue: there have two problems on sending tickets with all the information to the client a) If the session resumption solution is deployed in mobile network, it will consume a lot of air-interface cost to request/present/update the ticket. As the mobile operators, we prefer not do that. The draft does not specify the ticket format. This could be very compact, down to 16-24 bytes, including notification payload header. b) As discussed in the list, the packet to send the ticket may be fragmented. When session resumption happened, a large number of the client may try to present the ticket at the same time. In this case, a bunch of fragmented IP packets will be sent to the gateway. Some equipments (such as mobile network GW, firewalls, etc) between clients and gateway may be overloaded to handle the IP fragment. And, some equipments may treat it as DoS attack and simply drop all the fragmented packets. the most important issue, the wireless base station will be chunked and died. I understand that resumption may have severe implications for the core network - lots of simultaneous IKE traffic, but aren't the clients supposed to be spread out among very many base stations? I didn't think there should be congestion at the base stations. it depends on how to express it, mostly congestion will happen in security gateway or firewall, sometime it also lead to the congestion at the base station. it depends on how many subscribers under this base station, how could the signaling channel of this base station to handle this. Anyway, I think this issue exists. thanks for your consideration. under this consideration, we would like to recommend the solution which could store the ticket information purely on the network side. thanks for your consideration. The "ticket" could be a 64- or 128-bit index into a database table, giving a total payload size of 16 or 24 bytes respectively. I believe a payload this small should not overload the "air". Does a solution such as this address your concerns? this working group doc already refer to our input, so we are fine with this. -Hui Hope this helps Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 18 14:16:42 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 4D49628C291; Tue, 18 Nov 2008 14:16:42 -0800 (PST) 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 894AD28C291 for ; Tue, 18 Nov 2008 14:16:40 -0800 (PST) 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 p9n1-OHxB0ya for ; Tue, 18 Nov 2008 14:16:39 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 5315828C28A for ; Tue, 18 Nov 2008 14:16:39 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so3477103wfd.31 for ; Tue, 18 Nov 2008 14:16:38 -0800 (PST) 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=4J5vSarpVSw9l1rOBd7YAKSMDxo+BIAO9Re15dsSVyw=; b=NEw8yAQ15UodVdAe+bRRX1CxWpAzWjMlUpMpnFiP/W2415kNBsB7HickCtTB1y7Bca 4BEIPiPIlTYrHenI5Ky7aigtOz+Spz7KqTtrGFOn4zfAHkPgdmGIVYIb7dsmTtJztOlO ej8vpdSne7ZPd2JqYrLKls0Kh/NH5gOLBOZHQ= 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=MHEmGoHGixXbE1ZNzcxUVfWLTFj4BL2clsiVF22qzn3lP10tbaybvx0MmBzLItB1ut hUO2Y1tRFjTkV312xfmAPddh+5MD/lVkD55cx9XPZ620ThINTiHRr6q0PvTY7v19A9Id YRY/EHxWiBgvg6b44NbOYDgvpqYx+kHsUKGo0= Received: by 10.143.4.16 with SMTP id g16mr152614wfi.124.1227046598527; Tue, 18 Nov 2008 14:16:38 -0800 (PST) Received: by 10.142.211.4 with HTTP; Tue, 18 Nov 2008 14:16:38 -0800 (PST) Message-ID: <4c5c7a6d0811181416h4ec9f7bew9579dbcf56f424bf@mail.gmail.com> Date: Wed, 19 Nov 2008 06:16:38 +0800 From: "Peny Yang" To: "Tero Kivinen" In-Reply-To: <18723.8781.499111.51370@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline References: <4c5c7a6d0811172219j96ce787qd265ded48f4c60b6@mail.gmail.com> <18723.8781.499111.51370@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org Subject: Re: [IPsec] Comment on draft-ietf-ipsecme-ikev2-resumption-00 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 Hey, Tero: Please check the lines below: > As an IKEv2 implementor I think having separate IKE_SESSION_RESUME > exchange actually makes the changes easier to do, than to go and > modify the existing IKE_SA_INIT AND IKE_SA_AUTH state machines. The > state machines of the IKE_SA_INIT and especially IKE_SA_AUTH are > already quite complicated because of the EAP, and other options and > especially even more when someone starts to implement things like > RFC4739 in which case the state machine and especially the policy gets > extremely complicated... [Peny] Basically, I don't think extending IKE_SA_INIT is more complicated than IKE_SESSION_RESUME. One thing for sure, IKE_SESSION_RESUME also need to add new states in the state machine of IKEv2. And, to implement the IKE_SESSION_RESUME, I must make more codes to protect these messages. And, If the extensions of IKEv2-EAP and RFC4739 are supported, these procedure will be done right after the IKE_SA_INIT procedure has been finished. So, the extension of IKE_SA_INIT in my mind will not be interleaved with IKEv2-EAP/RFC4739 procedures at all. And by extending the IKE_SA_INIT, we don't need to design new way to protect the messages. So, I am in favor of using IKE_SA_INIT extension to support session resumption, which IMHO is easier to implement. > Yes, but I do not think that case is that common case. I think the > most common case will be the case when gateway still has the ticket > and will accept it, thus we need to optimize for it. If the gateway do > not have ticket anymore, that means we need to do Diffie-Hellman, > which quite often takes more time than the one round trip. [Peny] Well, it seems you assume the case of ticket-by-reference. Basically, I agree that the time of one round trip may be shorter than DH. But, we have the solution to save that round trip in this case. Why don't we just do it. > Note, that in this case the client needs to do Diffie-Hellman setup > before it can even see if the server has ticket still valid or not. [Peny] I am confused here. Are you talking about the case of ticket-by-reference or the one of ticket-by-value. For the former one, ticket is on server side. But I don't think the client need to do DH, if the ticket is valid. KEi can be retrieved from client local IKE_SA before session resumption. If ticket on server is not valid in this case, server just fall back to the regular IKEv2 procedure with DH. For the latter one, server does not have the ticket before the session resumption. > Also the packets gets quite big, as they > need to include all things that can be in the IKE_SA_INIT (i.e. KE > payload etc), and the ticket itself, and also some encrypted > information to proof that client do have the keying material still. So > the minimum version of that packet would look like: > > HDR, SAi1, KEi, Ni, N(TICKET_OPAQUE), SK { IDi } -> > > Hmm... the draft does not actually say, but I think the current idea > is that all IPsec SAs are removed when resumption happens, and they > need to be rekeyed, which is why the current IKE_SESSION_RESUME > exchange has payloads required for the one child sa creation, i.e. > where the first packet would be: > > HDR, SAi1, KEi, Ni, N(TICKET_OPAQUE), > SK { IDi, [IDr,] SAi2, TSi, TSr, CP(...) } > > so its starts to get quite large. [Peny] Agree. I think the ticket should be very small. > Note, that it now also has two SA > payloads and so on, which will again add more complications as > implementations must keep in mind which SA payload was outside the > encryption and which inside etc. [Peny] Yeah. I asked this question this morning. > Now if the ticket is still valid, then client has wasted its cpu > resources by calculating the Diffie-Hellman value it sent in as KEi, > the bandwidth between the peers was wasted by sending SAi1, and KEi > payloads (KEi is the largest payload in normal exchange). [Peny] Client can retrieve the KEi from local storage. Regards, Peny _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 18 14:35:11 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 9E82428C283; Tue, 18 Nov 2008 14:35:11 -0800 (PST) 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 572CF3A6990 for ; Tue, 18 Nov 2008 14:35:10 -0800 (PST) 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 2n5eup+-QYr6 for ; Tue, 18 Nov 2008 14:35:09 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 3B92B3A68A0 for ; Tue, 18 Nov 2008 14:35:09 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so3483994wfd.31 for ; Tue, 18 Nov 2008 14:35:08 -0800 (PST) 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=w7qE1j8saw3xFa8m98FsjO/GqgkAWgHdTuzn4+5xO1M=; b=PS2Y9/9NMnZpb+nb8noXMQ+rbQWzVd5q4KTqb91pbfyzak/lXaOgyc7vBBRp6gxovE 1nAJvH2Eg+4HTkxZEFDKQ8M26sLPrIdkoV7ObJZDdiRcAq0ioGBewN+csmLlGyQjQqdG TlmmRmPl+npDVOMHt04xtw6/19gS4SmzKPLnQ= 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=bT//RnWgnilPjqceotb8qaaJP0j30V5GzM9FlFhjlGOP6fMZa/BrokE4NqHb/KCf9X eIIReRO9iomm5E4sykxjjpo6gGzoINK8gT6XbIpASiUXDCG5tCt5EHGUXHyfJmiKglLk kvR0rX+4xqBWuPxmArcWaXeA/7ryg2i/83Zso= Received: by 10.142.115.20 with SMTP id n20mr144649wfc.344.1227047708139; Tue, 18 Nov 2008 14:35:08 -0800 (PST) Received: by 10.142.211.4 with HTTP; Tue, 18 Nov 2008 14:35:08 -0800 (PST) Message-ID: <4c5c7a6d0811181435q70a6a524o96350b2c83ad1a5c@mail.gmail.com> Date: Wed, 19 Nov 2008 06:35:08 +0800 From: "Peny Yang" To: "Hannes Tschofenig" In-Reply-To: <014901c9497d$a50ad520$d91f8182@nsnintra.net> MIME-Version: 1.0 Content-Disposition: inline References: <1d38a3350811172207m1801bf77ra4518f06deb61207@mail.gmail.com> <7C69DECB-BB75-43BA-ABED-6DB5DB648791@checkpoint.com> <1d38a3350811180713p3e1b7849g9f50e0a6e66cf709@mail.gmail.com> <014901c9497d$a50ad520$d91f8182@nsnintra.net> Cc: Hui Deng , ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-resumption-00.txt ticketlocation 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, Hannes: Please check inline: On Tue, Nov 18, 2008 at 9:00 PM, Hannes Tschofenig wrote: > I am a bit confused about the performance restrictions of cellular systems > that are being described. > Given that the IKEv2 exchanges are infrequent and that the ticket size is > indeed small [Peny] In the case of ticket-by-reference, it's small. In case of ticket-by-value, there is the possibility. > I was wondering what type of environment we are talking about > where it comes to overload situations at base stations with a ticket. I > guess in such an environment it would be difficult to download a webpage or > anything else. [Peny] what's in my mind is that all the clients under one base station will try to present the tickets at the same time during session resumption. At this time, the reverse link of the BS may be fully occupied for a while depends on the reserver link capacity and traffic status.If the ticket is fragmented, more air-resources will be consumed. And if fragmented, BS need to reassemble the packets to do some work required by access network. In this case, most of CPU resources of BS may be consumed, which could even make the BS down. Another possibility is that BS just simply drops all the fragmented messages (with ticket inside) to be on the safe side based on the local policy. > Irrespectively of that question I am wondering why this is an issue at all > given that the draft does not mandate a specific format (neither ticket nor > reference). Nothing additional needs to be standardized from that point of > view. [Peny] Well, in case of ticket-by-value, there is the possibility that message of presenting ticket is fragmented. Peny > > > ________________________________ > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > Behalf Of Hui Deng > Sent: 18 November, 2008 17:13 > To: Yoav Nir > Cc: ipsec@ietf.org > Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-resumption-00.txt > ticketlocation > > > 2008/11/18 Yoav Nir > > > Hi Hui, > On Nov 18, 2008, at 8:07 AM, Hui Deng wrote: > > > > Hello, authors, > > After reading your draft and rethinking of the main > issues, I would like to raise one issue about ticket location issue: > there have two problems on sending tickets with all > the information to the client > > a) If the session resumption solution is deployed in > mobile network, > it will consume a lot of air-interface cost to > request/present/update > the ticket. As the mobile operators, we prefer not > do that. > > The draft does not specify the ticket format. This could be > very compact, down to 16-24 bytes, including notification payload header. > > > > > > > > > b) As discussed in the list, the packet to send the > ticket may be > fragmented. When session resumption happened, a > large number of the > client may try to present the ticket at the same > time. In this case, a > bunch of fragmented IP packets will be sent to the > gateway. Some > equipments (such as mobile network GW, firewalls, > etc) between clients > and gateway may be overloaded to handle the IP > fragment. And, some > equipments may treat it as DoS attack and simply > drop all the > fragmented packets. the most important issue, the > wireless base station > will be chunked and died. > > > > I understand that resumption may have severe implications > for the core network - lots of simultaneous IKE traffic, but aren't the > clients supposed to be spread out among very many base stations? I didn't > think there should be congestion at the base stations. > > it depends on how to express it, mostly congestion will happen in > security gateway or firewall, sometime it also lead to the congestion at the > base station. it depends on how many subscribers under this base station, > how could the signaling channel of this base station to handle this. Anyway, > I think this issue exists. > > > > > thanks for your consideration. under this > consideration, we would like to > recommend the solution which could store the ticket > information purely on > the network side. > thanks for your consideration. > > > > The "ticket" could be a 64- or 128-bit index into a database > table, giving a total payload size of 16 or 24 bytes respectively. I believe > a payload this small should not overload the "air". Does a solution such as > this address your concerns? > > this working group doc already refer to our input, so we are fine > with this. > > -Hui > > > > Hope this helps > > Yoav > > > > > > _______________________________________________ > 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 Nov 18 23:47: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 D30CC3A694A; Tue, 18 Nov 2008 23:47:49 -0800 (PST) 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 E15BA3A694A for ; Tue, 18 Nov 2008 23:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, 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 NZUUgsb2tlz4 for ; Tue, 18 Nov 2008 23:47:48 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id ABB7F3A6863 for ; Tue, 18 Nov 2008 23:47:47 -0800 (PST) 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 mAJ7ljQC018638; Wed, 19 Nov 2008 09:47:45 +0200 (IST) Message-Id: <830232CB-6C18-46A2-9254-E95677C1FB21@checkpoint.com> From: Yoav Nir To: Lakshminath Dondeti In-Reply-To: <4922ECA0.3050102@qualcomm.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 09:47:44 +0200 References: <1696498986EFEC4D9153717DA325CB720251410F@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB7202514133@vaebe104.NOE.Nokia.com> <4922ECA0.3050102@qualcomm.com> X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, amuhanna@nortel.com Subject: Re: [IPsec] Ticket-by-reference and protecting the exchange 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 On Nov 18, 2008, at 6:26 PM, Lakshminath Dondeti wrote: > Ok, I see the 'offending' text now: "where SK_d_old is the SK_d > value of the original IKE SA, as retrieved > from the ticket. " > > That's true for the gateway (as clarified later in the draft); the > client has that state without having to retrieve from the ticket. > That's the entire premise. > > cheers, > Lakshminath I think it can be fixed by replacing "retrieved from the ticket" with "retrieved using the ticket" and making it refer only to the gateway side. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 19 05:58: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 23A643A6B93; Wed, 19 Nov 2008 05:58:05 -0800 (PST) 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 CC7E13A67B2 for ; Wed, 19 Nov 2008 04:46:07 -0800 (PST) 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=[AWL=-0.001, 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 0vIIpFXd5SI1 for ; Wed, 19 Nov 2008 04:46:06 -0800 (PST) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id CB77F3A6882 for ; Wed, 19 Nov 2008 04:46:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,631,1220227200"; d="scan'208,217";a="34006440" Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-1.cisco.com with ESMTP; 19 Nov 2008 12:46:01 +0000 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAJCjtXs003078 for ; Wed, 19 Nov 2008 20:45:55 +0800 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAJCjsAr021806 for ; Wed, 19 Nov 2008 12:45:55 GMT Received: from XMB-BLR-419.apac.cisco.com ([64.104.140.154]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 18:15:28 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 18:15:28 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on CP payload Thread-Index: AclKRLMjW7CdPZGSQ8OVWAbgJ9UYrA== From: "Raghunandan P (raghup)" To: X-OriginalArrivalTime: 19 Nov 2008 12:45:28.0840 (UTC) FILETIME=[B39CD080:01C94A44] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5333; t=1227098760; x=1227962760; c=relaxed/simple; s=hkgdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=raghup@cisco.com; z=From:=20=22Raghunandan=20P=20(raghup)=22=20 |Subject:=20Question=20on=20CP=20payload |Sender:=20; bh=hUMuL8o7xBdNrmhlGezhFtYwy9yDw0TCXKt7k6sT0MA=; b=S7JTcYAPRE+3CDfjxF2oib78bPahv7hdzuNXRgOTliahe5XISgB/+Ah2Jf lnnTRcc8DZSnwlZtWcji+w2DeXHWv6nSG2xGMkvdq9H5iq/eA/dQoZRegrtQ c1tewILWudtxytZsZt2k8p9jzTKukKPZOW5Ftjb/QWWYVZHNzpn0o=; Authentication-Results: hkg-dkim-1; header.From=raghup@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim1002 verified; ); Subject: [IPsec] Question on CP payload 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="===============1519357136==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1519357136== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C94A44.B374E0FA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C94A44.B374E0FA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I was going through the draft draft-ietf-ipsecme-ikev2bis-01 and have the following questions on CP payload. =20 1. The CP payload can be exchanged as part of the AUTH_EXCHANGE and can also be sent separately as part of informational message. Is that correct? Can we have a scenario where CP payload is sent as part of the AUTH_EXCHANGE and also separately as an informational message (in both the exchanges)? =20 2. Suppose there is a scanario where CP payload has been exchanged as part of XAUTH exchange and suppose the config mode reply has pushed an IP address of 3.3.3.3. Now, suppose Tsi agrred upon is 1.1.1.1 and Tsr agrred upon is 2.2.2.2 which means that any traffic from 1.1.1.1 to 2.2.2.2 needs to be NATed to 3.3.3.3 and protected by the child SA. Hence, a child SA will be setup with 3.3.3.3 to 2.2.2.2. Is that correct?=20 Assuming above is true, both IKE SA and child SA have been set up. Now, suppose a CP payload is exchanged as part of informational exchange and a new IP address is pushed to the client as part of this message. Is this possible? If yes, what would happen to the existing IPsec SA. Will it be deleted and new child SA set up? OR will a new child SA be set up? OR existing child SA modified? =20 3. Suppose we have the normal SA_INIT and AUTH_EXCHANGE which create an IKE SA and a child SA without any configuration messages exchanged during these exchanges. After this is done, now suppose the CP payloads are exchanged as part of the informational exchange and the peer pushes a new IP address to the client. What would happen to the existing child SA? Will it be modified to take into account the new pushed address or will the existing child SA be deleted and a new one set up? =20 Thanks Raghu ------_=_NextPart_001_01C94A44.B374E0FA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
I was = going through=20 the draft draft-ietf-ipsecme-ikev2bis-01 and have the following = questions on CP=20 payload.
 
1. The = CP payload=20 can be exchanged as part of the AUTH_EXCHANGE and can also be sent = separately as=20 part of informational message. Is that correct? Can we have a scenario = where CP=20 payload is sent as part of the AUTH_EXCHANGE and also separately as an=20 informational message (in both the exchanges)?
 
2. = Suppose there is=20 a scanario where CP payload has been exchanged as part of XAUTH exchange = and=20 suppose the config mode reply has pushed an IP address of 3.3.3.3. Now, = suppose=20 Tsi agrred upon is 1.1.1.1 and Tsr agrred upon is 2.2.2.2 which = means that=20 any traffic from 1.1.1.1 to 2.2.2.2 needs to be NATed to 3.3.3.3 = and=20 protected by the child SA. Hence, a child SA will be setup with 3.3.3.3 = to=20 2.2.2.2. Is that correct?
Assuming above is=20 true, both IKE SA and child SA have been set up. Now, suppose a CP = payload is=20 exchanged as part of informational exchange and a new IP address is = pushed to=20 the client as part of this message. Is this possible? If yes, what would = happen=20 to the existing IPsec SA. Will it be deleted and new child SA set = up? OR=20 will a new child SA be set up? OR existing child SA=20 modified?
 
3. = Suppose we have=20 the normal SA_INIT and AUTH_EXCHANGE which create an IKE SA and a child = SA=20 without any configuration messages exchanged during these exchanges. = After this=20 is done, now suppose the CP payloads are exchanged as part of the = informational=20 exchange and the peer pushes a new IP address to the client. What would = happen=20 to the existing child SA? Will it be modified to take into account the = new=20 pushed address or will the existing child SA be deleted and a new one = set=20 up?
 
Thanks
Raghu
------_=_NextPart_001_01C94A44.B374E0FA-- --===============1519357136== 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 --===============1519357136==-- From ipsec-bounces@ietf.org Wed Nov 19 07:59: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 D996E3A6BA4; Wed, 19 Nov 2008 07:59:17 -0800 (PST) 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 031693A6BA3 for ; Wed, 19 Nov 2008 07:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 g7parHmVDqfw for ; Wed, 19 Nov 2008 07:59:16 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 810823A6BA6 for ; Wed, 19 Nov 2008 07:59:15 -0800 (PST) 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 mAJFx8B4022784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Nov 2008 17:59:08 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mAJFx8qt011581; Wed, 19 Nov 2008 17:59:08 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18724.14284.263786.286763@fireball.kivinen.iki.fi> Date: Wed, 19 Nov 2008 17:59:08 +0200 From: Tero Kivinen To: "Peny Yang" In-Reply-To: <4c5c7a6d0811181416h4ec9f7bew9579dbcf56f424bf@mail.gmail.com> References: <4c5c7a6d0811172219j96ce787qd265ded48f4c60b6@mail.gmail.com> <18723.8781.499111.51370@fireball.kivinen.iki.fi> <4c5c7a6d0811181416h4ec9f7bew9579dbcf56f424bf@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 29 min X-Total-Time: 40 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Comment on draft-ietf-ipsecme-ikev2-resumption-00 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 Peny Yang writes: > Hey, Tero: > > Please check the lines below: > > > As an IKEv2 implementor I think having separate IKE_SESSION_RESUME > > exchange actually makes the changes easier to do, than to go and > > modify the existing IKE_SA_INIT AND IKE_SA_AUTH state machines. The > > state machines of the IKE_SA_INIT and especially IKE_SA_AUTH are > > already quite complicated because of the EAP, and other options and > > especially even more when someone starts to implement things like > > RFC4739 in which case the state machine and especially the policy gets > > extremely complicated... > [Peny] Basically, I don't think extending IKE_SA_INIT is more > complicated than IKE_SESSION_RESUME. Then we disagree on this point, but I do not think it is productive to waste too much time for this point. > One thing for sure, IKE_SESSION_RESUME also need to add new states in > the state machine of IKEv2. And, to implement the IKE_SESSION_RESUME, > I must make more codes to protect these messages. > And, If the extensions of IKEv2-EAP and RFC4739 are supported, these > procedure will be done right after the IKE_SA_INIT procedure has been > finished. So, the extension of IKE_SA_INIT in my mind will not be > interleaved with IKEv2-EAP/RFC4739 procedures at all. True, I just wanted to point out that the current state machine is already quite complicated, and I would not like to make it any more complicated than it is now. > And by extending > the IKE_SA_INIT, we don't need to design new way to protect the > messages. Not true, as IKE_SA_INIT does not have any protection as such, the contents of it is protected by the AUTH payload in IKE_AUTH exchange. There is no encrypted part in that, and in normally does not even have crypto context at that point. Adding encrypted SK {} part is designing new way to protect the mssages. > > Yes, but I do not think that case is that common case. I think the > > most common case will be the case when gateway still has the ticket > > and will accept it, thus we need to optimize for it. If the gateway do > > not have ticket anymore, that means we need to do Diffie-Hellman, > > which quite often takes more time than the one round trip. > [Peny] Well, it seems you assume the case of ticket-by-reference. I didn't really assume either one of those, as it does not matter. With ticket-by-reference the ticket would be so small that putting it to IKE_SA_INIT, but for ticket-by-value the actual ticket might be quite large. > Basically, I agree that the time of one round trip may be shorter > than DH. But, we have the solution to save that round trip in this > case. Why don't we just do it. Because DH is much more expensive than round trip, and in most common case there would not be extra round trip at all, as ticket is accepted. > > Note, that in this case the client needs to do Diffie-Hellman setup > > before it can even see if the server has ticket still valid or not. > [Peny] I am confused here. Are you talking about the case of > ticket-by-reference or the one of ticket-by-value. Both. It does not matter whether ticket-by-reference or ticket-by-value is used, if the resumption is done part of IKE_SA_INIT the client MUST do Diffie-Hellman setup and generate the KEi payload which is part of the same message, just in case. > For the former one, ticket is on server side. But I don't think the > client need to do DH, if the ticket is valid. KEi can be retrieved > from client local IKE_SA before session resumption. KEi cannot be retrieved, as it is not present in client anymore, and you do NOT want to reuse the exponential that was used few hours ago when the original IKE SA was created. The KEi would need to be new and client would need to do the calculation. The KEi in the IKE_SA_INIT does not have anything to do with the old IKE SA, it might even be over different Diffie-Hellman group. > > so its starts to get quite large. > [Peny] Agree. I think the ticket should be very small. The minimum ticket-by-value size is around 128, and I guess it will be around 200 bytes normally (assuming ticket format from Appendix A). > > Now if the ticket is still valid, then client has wasted its cpu > > resources by calculating the Diffie-Hellman value it sent in as KEi, > > the bandwidth between the peers was wasted by sending SAi1, and KEi > > payloads (KEi is the largest payload in normal exchange). > [Peny] Client can retrieve the KEi from local storage. You do assume that crypto library allows exponent reuse. Some crypto libraries do not allow that, they will erase all information about the Diffie-Hellman pieces when the Diffie-Hellman calculation is finished. Actually security considerations section of RFC 4306 does assume that: It is assumed that all Diffie-Hellman exponents are erased from memory after use. In particular, these exponents MUST NOT be derived from long-lived secrets like the seed to a pseudo-random generator that is not erased after use. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 19 12:07: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 2D8C53A6AC1; Wed, 19 Nov 2008 12:07:53 -0800 (PST) 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 BE3E43A6AC1 for ; Wed, 19 Nov 2008 12:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 Jr60m7-ZbyLU for ; Wed, 19 Nov 2008 12:07:50 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 7D1983A697D for ; Wed, 19 Nov 2008 12:07:50 -0800 (PST) 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 mAJK7PRh010066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Nov 2008 22:07:25 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mAJK7PxN016617; Wed, 19 Nov 2008 22:07:25 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18724.29181.897230.111045@fireball.kivinen.iki.fi> Date: Wed, 19 Nov 2008 22:07:25 +0200 From: Tero Kivinen To: "Raghunandan P (raghup)" In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 8 min Cc: ipsec@ietf.org Subject: [IPsec] Question on CP payload 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 Raghunandan P (raghup) writes: > 1. The CP payload can be exchanged as part of the AUTH_EXCHANGE and can > also be sent separately as part of informational message. Is that > correct? Can we have a scenario where CP payload is sent as part of the > AUTH_EXCHANGE and also separately as an informational message (in both > the exchanges)? Yes, Configuration payloads can be sent as separate INFORMATIONAL exchange after the IKE_AUTH. Some reason to do it after IKE_AUTH as INFORMATIONAL exchange is if the client wants to get another address, for example it originally only requirested IPv4 address, and now wants to get IPv6 address too. > 2. Suppose there is a scanario where CP payload has been exchanged as > part of XAUTH exchange and suppose the config mode reply has pushed an ^^^^^ XAUTH? I assume you mean IKE_AUTH? > IP address of 3.3.3.3. Now, suppose Tsi agrred upon is 1.1.1.1 and Tsr > agrred upon is 2.2.2.2 which means that any traffic from 1.1.1.1 to > 2.2.2.2 needs to be NATed to 3.3.3.3 and protected by the child SA. > Hence, a child SA will be setup with 3.3.3.3 to 2.2.2.2. Is that > correct? I am not sure what you are asking here. There isn't any NATs there in general case. Normally the client proposes the TSi of any to the responder and responder will then assign the address (3.3.3.3 in this case), and it will then narrow down the proposal initiator make to that. > Assuming above is true, both IKE SA and child SA have been set up. Now, > suppose a CP payload is exchanged as part of informational exchange and > a new IP address is pushed to the client as part of this message. Is > this possible? Yes. > If yes, what would happen to the existing IPsec SA. Will > it be deleted and new child SA set up? OR will a new child SA be set up? > OR existing child SA modified? Nothing will happen to the existing IPsec SAs. The original addresses assigned to the client are still valid, so there is no point of doing anything to them. Existing SAs are not deleted and they are not modified. > 3. Suppose we have the normal SA_INIT and AUTH_EXCHANGE which create an > IKE SA and a child SA without any configuration messages exchanged > during these exchanges. After this is done, now suppose the CP payloads > are exchanged as part of the informational exchange and the peer pushes > a new IP address to the client. What would happen to the existing child > SA? Nothing will happen to them. They stay there and can be used as before. > Will it be modified to take into account the new pushed address or > will the existing child SA be deleted and a new one set up? They are not modified, and are not automatically deleted. If the client wants to use the new IP-address it has been pushed to it most likely needs to create new IPsec SA that allows that traffic also, as the SAs created before most likely do not allow that traffic. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 19 16:35: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 5DC9C3A6BD2; Wed, 19 Nov 2008 16:35:41 -0800 (PST) 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 788C528C17A for ; Wed, 19 Nov 2008 16:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 ZAWxa8Z8qWgI for ; Wed, 19 Nov 2008 16:35:37 -0800 (PST) Received: from g5t0006.atlanta.hp.com (g5t0006.atlanta.hp.com [15.192.0.43]) by core3.amsl.com (Postfix) with ESMTP id A2A193A6782 for ; Wed, 19 Nov 2008 16:35:37 -0800 (PST) Received: from G3W0630.americas.hpqcorp.net (g3w0630.americas.hpqcorp.net [16.233.58.74]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0006.atlanta.hp.com (Postfix) with ESMTPS id 19250C753 for ; Thu, 20 Nov 2008 00:35:33 +0000 (UTC) Received: from G5W0325.americas.hpqcorp.net (16.228.8.67) by G3W0630.americas.hpqcorp.net (16.233.58.74) with Microsoft SMTP Server (TLS) id 8.1.263.0; Thu, 20 Nov 2008 00:34:43 +0000 Received: from GVW0538EXC.americas.hpqcorp.net ([16.228.8.55]) by G5W0325.americas.hpqcorp.net ([16.228.8.67]) with mapi; Thu, 20 Nov 2008 00:34:43 +0000 From: "He, Wenxiao" To: "ipsec@ietf.org" Date: Thu, 20 Nov 2008 00:34:42 +0000 Thread-Topic: [Ipsec] RFC 4301 and ICMP processing Thread-Index: AclKX85vysvDk/5XQn6cRulbzoddVwAQXMVw Message-ID: <769907F0D19EFA45BD6F04FC6E896D6D1EBF8468A7@GVW0538EXC.americas.hpqcorp.net> References: <4c5c7a6d0811172219j96ce787qd265ded48f4c60b6@mail.gmail.com> <18723.8781.499111.51370@fireball.kivinen.iki.fi> <4c5c7a6d0811181416h4ec9f7bew9579dbcf56f424bf@mail.gmail.com> <18724.14284.263786.286763@fireball.kivinen.iki.fi> In-Reply-To: <18724.14284.263786.286763@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [IPsec] [Ipsec] RFC 4301 and ICMP processing 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, I am trying to figure out the requirements of processing ICMP error message as an IPsec end host. Just googled and noticed that there was a discussion (took place on Tue, 31 Jul 2007) on ICMP topic but focusing on gateway. The original discussion is copied at the end of this message. Now, consider a simple end-to-end case between host A and host B. The SPD between A and B only specifies a SA for UDP, and there is no SPD to cover ICMP traffic. When host A sends a UDP message to host B, a SA pair is negotiated. And the A->B UDP message triggers host B to send back an ICMP error message. A) If I apply section 6.2 "Processing Protected, Transit ICMP Error Messages" to the B->A ICMP error message, the icmp error message will be carried by the extant SA pair generated by UDP message. B) If I donot apply the process specified in section 6.2, then the ICMP ERROR message will be discarded because no SPD is found. Which of the above two approaches is the expected behavior for an IPsec end host? Does section 6 apply to IPsec end host? Thanks, Wenxiao He ========================================== [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Ipsec] RFC 4301 and ICMP processing * To: Stephen Kent * Subject: Re: [Ipsec] RFC 4301 and ICMP processing * From: Scott C Moonen * Date: Tue, 31 Jul 2007 16:08:18 -0400 * Cc: ipsec at ietf.org * In-reply-to: * List-help: * List-id: IP Security * List-post: * List-subscribe: , * List-unsubscribe: , Thanks for the very quick response, Stephen! Scott Moonen (smoonen at us.ibm.com) http://scott.andstuff.org/ Stephen Kent 07/31/2007 03:44 PM To Scott C Moonen/Raleigh/IBM at IBMUS cc ipsec at ietf.org Subject Re: [Ipsec] RFC 4301 and ICMP processing At 11:52 AM -0600 7/31/07, Scott C Moonen wrote: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z66_boundary_sign In section 6.2, RFC 4301 requires the use of additional checks to verify whether an ICMP packet is consistent with an SA's selectors. When sending or receiving an ICMP packet, if there is no existing SA or SPD entry to match the ICMP error, then the ICMP packet is allowed to traverse the same SA that its embedded packet would have traversed. It is reasonably clear what is to be done for an end-to-end SA, but the RFC's language is unclear as to whether this is required for a gateway SA. Consider the following setup: H1 ----- GW1 ===== GW2 ----- RTR1 ----- H2 Host H1 sends a UDP packet to H2 that is encapsulated in an IPsec tunnel between gateways GW1 and GW2. My question is this: If RTR1 originates an ICMP error for this packet that traverses the same path in reverse, should GW2 encapsulate the ICMP packet in the original UDP SA (in the absence of other rules for carrying the ICMP packet), and should GW1 allow the encapsulated ICMP packet to arrive over that UDP SA? 4301 allows GW1 and GW2 to handle this situation in either of two ways. An SPD can say that the SA for the H1/H2 traffic ALSO can carry ICMP messages, or the SPD can call for creating a separate SA between the two GWs to carry only ICMP messages. So, the answer to your question depends on the contents of the SPDs at GW1 and GW2. In the case of GW1 allowing the ICMP packet to exit the tunnel and be forwarded, the RFC hints strongly that this should be the case. The last sentence of section 6.2 speaks of cases where the ICMP must not be forwarded, The intent of the last sentence in 6.2 is to emphasize that if an ICMP packet is received on an inbound SA and cannot be verified via the procedure outlined in 6.2, then it MUST be discarded, not forwarded. Section 6.2 does not express a strong preference for either of the approaches to carriage of ICMP traffic defined in this section. Compliant implementations MUST support both approaches, e.g., the text says "To accommodate both policies, ..." . strongly implying that GW1 is normally expected to forward in this case. But it is less clear that GW2 should encapsulate ICMP errors in non-ICMP SAs for errors that it has not originated. Section 6.2 speaks only of performing this encapsulation for "outbound" ICMP errors, and of ICMP errors "sent and received via SAs." What if GW2 is doing forwarding but not sending? The ICMP errors are outbound whether they are generated by the security gateway or by a host or router behind the SG. So whether the GW is generating the ICMP error message itself, or forwarding it, the treatment is the same at this stage of processing. I'm inclined to think that GW2 should encapsulate any ICMP error according to these rules, even routed ICMP errors which it did not itself originate. That's controlled by the SPD. This is parallel with the fact that GW1 seems to be expected to behave in the reverse manner, and also aligns with the use of "outbound" at other points in the RFC to be inclusive of forwarded traffic. The one concern I can see is that ICMP errors that GW2 did not originate are considered less trustworthy and we may not wish to apply this processing to them. However, it is possible to prevent this by creating additional SPD entries at GW2 to prevent untrustworthy ICMP errors from entering the gateway in the first place. yes, the GW could elect to not forward ICMP traffic from routers behind it, for security reasons. Am I correct in assuming that section 6.2 of RFC 4301 is intended to address both local and forwarded ICMP traffic? Or is the treatment of forwarded traffic left to the discretion of each implementation? As I noted above, the intent of 6.2 is to accommodate both locally generated and forwarded ICMP traffic. Steve _______________________________________________ Ipsec mailing list Ipsec at ietf.org https://www1.ietf.org/mailman/listinfo/ipsec * References: o Re: [Ipsec] RFC 4301 and ICMP processing + From: Stephen Kent * Prev by Date: Re: [Ipsec] RFC 4301 and ICMP processing * Next by Date: Re: Re: [Ipsec] RFC 4301 and ICMP processing * Previous by thread: Re: [Ipsec] RFC 4301 and ICMP processing * Next by thread: Re: Re: [Ipsec] RFC 4301 and ICMP processing * Index(es): o Date o Thread Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 20 01:43:33 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 38C5D3A6888; Thu, 20 Nov 2008 01:43:33 -0800 (PST) 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 A9FBB3A684C for ; Wed, 19 Nov 2008 20:10:09 -0800 (PST) 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 ejz8GKaBZILT for ; Wed, 19 Nov 2008 20:10:08 -0800 (PST) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id 4D6DD3A6810 for ; Wed, 19 Nov 2008 20:10:08 -0800 (PST) Received: from de01smr02.am.mot.com (de01smr02.freescale.net [10.208.0.151]) by az33egw02.freescale.net (8.12.11/az33egw02) with ESMTP id mAK49O2m020980 for ; Wed, 19 Nov 2008 21:09:34 -0700 (MST) Received: from zin33exm29.fsl.freescale.net (zin33exm29.ap.freescale.net [10.232.192.28]) by de01smr02.am.mot.com (8.13.1/8.13.0) with ESMTP id mAK49KG0011781 for ; Wed, 19 Nov 2008 22:09:21 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 09:39:19 +0530 Message-ID: <402621A7D69DDA458D0E12F070D1E55F06EB40@zin33exm29.fsl.freescale.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Question on CP payload Thread-Index: AclKgos9QWCsoMYGQOS9wuROayEzfgAQDSCU References: <18724.29181.897230.111045@fireball.kivinen.iki.fi> From: "V Jyothi" To: "Tero Kivinen" , "Raghunandan P (raghup)" Cc: ipsec@ietf.org Subject: Re: [IPsec] Question on CP payload 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="===============0653572765==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0653572765== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C94AC5.C2DDF90C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C94AC5.C2DDF90C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, In IKEv2 RFC, there was an INTERNAL_ADDRESS_EXPIRY attribute to specify = the expiry life time of address issue. Client can send CP payload in informational exchanges after address = expiry. INTERNAL_ADDRESS_EXPIRY attribute is removed in = draft-ietf-ipsecme-ikev2bis-01. thanks jyothi -----Original Message----- From: ipsec-bounces@ietf.org on behalf of Tero Kivinen Sent: Thu 11/20/2008 1:37 AM To: Raghunandan P (raghup) Cc: ipsec@ietf.org Subject: [IPsec] Question on CP payload =20 Raghunandan P (raghup) writes: > 1. The CP payload can be exchanged as part of the AUTH_EXCHANGE and = can > also be sent separately as part of informational message. Is that > correct? Can we have a scenario where CP payload is sent as part of = the > AUTH_EXCHANGE and also separately as an informational message (in both > the exchanges)? Yes, Configuration payloads can be sent as separate INFORMATIONAL exchange after the IKE_AUTH. Some reason to do it after IKE_AUTH as INFORMATIONAL exchange is if the client wants to get another address, for example it originally only requirested IPv4 address, and now wants to get IPv6 address too. > 2. Suppose there is a scanario where CP payload has been exchanged as > part of XAUTH exchange and suppose the config mode reply has pushed an ^^^^^ XAUTH? I assume you mean IKE_AUTH? > IP address of 3.3.3.3. Now, suppose Tsi agrred upon is 1.1.1.1 and Tsr > agrred upon is 2.2.2.2 which means that any traffic from 1.1.1.1 to > 2.2.2.2 needs to be NATed to 3.3.3.3 and protected by the child SA. > Hence, a child SA will be setup with 3.3.3.3 to 2.2.2.2. Is that > correct? I am not sure what you are asking here. There isn't any NATs there in general case. Normally the client proposes the TSi of any to the responder and responder will then assign the address (3.3.3.3 in this case), and it will then narrow down the proposal initiator make to that. > Assuming above is true, both IKE SA and child SA have been set up. = Now, > suppose a CP payload is exchanged as part of informational exchange = and > a new IP address is pushed to the client as part of this message. Is > this possible? Yes. > If yes, what would happen to the existing IPsec SA. Will > it be deleted and new child SA set up? OR will a new child SA be set = up? > OR existing child SA modified? Nothing will happen to the existing IPsec SAs. The original addresses assigned to the client are still valid, so there is no point of doing anything to them. Existing SAs are not deleted and they are not modified. > 3. Suppose we have the normal SA_INIT and AUTH_EXCHANGE which create = an > IKE SA and a child SA without any configuration messages exchanged > during these exchanges. After this is done, now suppose the CP = payloads > are exchanged as part of the informational exchange and the peer = pushes > a new IP address to the client. What would happen to the existing = child > SA? Nothing will happen to them. They stay there and can be used as before.=20 > Will it be modified to take into account the new pushed address or > will the existing child SA be deleted and a new one set up? They are not modified, and are not automatically deleted. If the client wants to use the new IP-address it has been pushed to it most likely needs to create new IPsec SA that allows that traffic also, as the SAs created before most likely do not allow that traffic. --=20 kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------_=_NextPart_001_01C94AC5.C2DDF90C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [IPsec] Question on CP payload

Hi,

In IKEv2 RFC, there was an INTERNAL_ADDRESS_EXPIRY attribute to specify = the expiry life time of address issue.
Client can send CP payload in informational exchanges after address = expiry.
 INTERNAL_ADDRESS_EXPIRY  attribute is removed in = draft-ietf-ipsecme-ikev2bis-01.

thanks
jyothi

-----Original Message-----
From: ipsec-bounces@ietf.org on behalf of Tero Kivinen
Sent: Thu 11/20/2008 1:37 AM
To: Raghunandan P (raghup)
Cc: ipsec@ietf.org
Subject: [IPsec]  Question on CP payload

Raghunandan P (raghup) writes:
> 1. The CP payload can be exchanged as part of the AUTH_EXCHANGE and = can
> also be sent separately as part of informational message. Is = that
> correct? Can we have a scenario where CP payload is sent as part of = the
> AUTH_EXCHANGE and also separately as an informational message (in = both
> the exchanges)?

Yes, Configuration payloads can be sent as separate INFORMATIONAL
exchange after the IKE_AUTH. Some reason to do it after IKE_AUTH as
INFORMATIONAL exchange is if the client wants to get another = address,
for example it originally only requirested IPv4 address, and now = wants
to get IPv6 address too.

> 2. Suppose there is a scanario where CP payload has been exchanged = as
> part of XAUTH exchange and suppose the config mode reply has pushed = an
          ^^^^^
XAUTH? I assume you mean IKE_AUTH?

> IP address of 3.3.3.3. Now, suppose Tsi agrred upon is 1.1.1.1 and = Tsr
> agrred upon is 2.2.2.2 which means that any traffic from 1.1.1.1 = to
> 2.2.2.2 needs to be NATed to 3.3.3.3 and protected by the child = SA.
> Hence, a child SA will be setup with 3.3.3.3 to 2.2.2.2. Is = that
> correct?

I am not sure what you are asking here. There isn't any NATs there
in general case. Normally the client proposes the TSi of any to the
responder and responder will then assign the address (3.3.3.3 in = this
case), and it will then narrow down the proposal initiator make to
that.

> Assuming above is true, both IKE SA and child SA have been set up. = Now,
> suppose a CP payload is exchanged as part of informational exchange = and
> a new IP address is pushed to the client as part of this message. = Is
> this possible?

Yes.

> If yes, what would happen to the existing IPsec SA. Will
> it be deleted and new child SA set up? OR will a new child SA be = set up?
> OR existing child SA modified?

Nothing will happen to the existing IPsec SAs. The original = addresses
assigned to the client are still valid, so there is no point of = doing
anything to them. Existing SAs are not deleted and they are not
modified.

> 3. Suppose we have the normal SA_INIT and AUTH_EXCHANGE which = create an
> IKE SA and a child SA without any configuration messages = exchanged
> during these exchanges. After this is done, now suppose the CP = payloads
> are exchanged as part of the informational exchange and the peer = pushes
> a new IP address to the client. What would happen to the existing = child
> SA?

Nothing will happen to them. They stay there and can be used as
before.

> Will it be modified to take into account the new pushed address = or
> will the existing child SA be deleted and a new one set up?

They are not modified, and are not automatically deleted. If the
client wants to use the new IP-address it has been pushed to it most
likely needs to create new IPsec SA that allows that traffic also, = as
the SAs created before most likely do not allow that traffic.
--
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org= /mailman/listinfo/ipsec

------_=_NextPart_001_01C94AC5.C2DDF90C-- --===============0653572765== 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 --===============0653572765==-- From ipsec-bounces@ietf.org Thu Nov 20 07:36: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 C04C13A695F; Thu, 20 Nov 2008 07:36:17 -0800 (PST) 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 C6D783A695F for ; Thu, 20 Nov 2008 07:36:16 -0800 (PST) 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 P56wYbeit-Mz for ; Thu, 20 Nov 2008 07:36:15 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id A0C8A3A67B5 for ; Thu, 20 Nov 2008 07:36:15 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so221755ywj.49 for ; Thu, 20 Nov 2008 07:36:13 -0800 (PST) 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=1/tEMKAoOrX4opSIzZIOzr5v3OaBp6/f69k6Li+yzpk=; b=UAg1PGfdeXBuQvQ56N5n2N9h/v0s61PAeSuoftczzO4P4KOhbqY+DuYYO5z3epMWyW LLTIWBP4j9wdY0vQZUR6qNd3DXlwP93OWLDNwuXXLOVJbMRWh9vWOkCWs7SNGCciO0Bd DVqtmvZM81TQO9Uu0O3xyAa7Cot8CTFWWVVrY= 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=WAMisik1p3RJB6aUrlyualXtKK6e0WWvt66RcWAmZ81E9YWOmmxy/JHKWq4hJhKq8y oDCNJ9IgUktwIuqSTSjz1WNSsXpeJmjG+uHM6f3iUsOhR4cpvPnZi4yHFAt/RWL3VI8o lQYRthMddwJCGOElbaPvNRnR82/zDhPsaZLqA= Received: by 10.142.103.11 with SMTP id a11mr1186455wfc.208.1227195372607; Thu, 20 Nov 2008 07:36:12 -0800 (PST) Received: by 10.142.211.4 with HTTP; Thu, 20 Nov 2008 07:36:12 -0800 (PST) Message-ID: <4c5c7a6d0811200736k4b60968dwdc66d93a8f89532b@mail.gmail.com> Date: Thu, 20 Nov 2008 23:36:12 +0800 From: "Peny Yang" To: "Tero Kivinen" In-Reply-To: <18724.14284.263786.286763@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline References: <4c5c7a6d0811172219j96ce787qd265ded48f4c60b6@mail.gmail.com> <18723.8781.499111.51370@fireball.kivinen.iki.fi> <4c5c7a6d0811181416h4ec9f7bew9579dbcf56f424bf@mail.gmail.com> <18724.14284.263786.286763@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org Subject: Re: [IPsec] Comment on draft-ietf-ipsecme-ikev2-resumption-00 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: Please check the lines: On Wed, Nov 19, 2008 at 11:59 PM, Tero Kivinen wrote: > Peny Yang writes: >> Hey, Tero: >> > Then we disagree on this point, but I do not think it is productive to > waste too much time for this point. [Peny] Fine. > True, I just wanted to point out that the current state machine is > already quite complicated, and I would not like to make it any more > complicated than it is now. [Peny] Yeah. It's already complicated. But, some states need to be added, no matter we add new IKE_SESSION_RESUME or extend the IKE_SA_INIT. Do you have any good idea to avoid the modification of IKEv2 state machine? > Not true, as IKE_SA_INIT does not have any protection as such, the > contents of it is protected by the AUTH payload in IKE_AUTH exchange. > There is no encrypted part in that, and in normally does not even have > crypto context at that point. Adding encrypted SK {} part is designing > new way to protect the mssages. [Peny] You are right. In my opinion, the SK{} part is not necessary to present the ticket. > I didn't really assume either one of those, as it does not matter. > With ticket-by-reference the ticket would be so small that putting it > to IKE_SA_INIT, but for ticket-by-value the actual ticket might be > quite large. [Peny] Thanks. You agree with us. > Because DH is much more expensive than round trip, and in most common > case there would not be extra round trip at all, as ticket is > accepted. [Peny] Firstly, I do not agree that DH is ALWAYS much more expensive than round trip. In some circumstances, such as in the wireless network with limited uplink, a round trip may be longer. > Both. It does not matter whether ticket-by-reference or > ticket-by-value is used, if the resumption is done part of IKE_SA_INIT > the client MUST do Diffie-Hellman setup and generate the KEi payload > which is part of the same message, just in case. [Peny] I don't think it's a MUST to redo DH on client for session resumption. For regular IKEv2 session setup, the DH need to be done every time. For Session resumption, the KEi can be reused. > KEi cannot be retrieved, as it is not present in client anymore, and > you do NOT want to reuse the exponential that was used few hours ago > when the original IKE SA was created. The KEi would need to be new and > client would need to do the calculation. The KEi in the IKE_SA_INIT > does not have anything to do with the old IKE SA, it might even be > over different Diffie-Hellman group. [Peny] For session resumption, it will not be over different DH group. > You do assume that crypto library allows exponent reuse. [Peny] Yes, I do assume reusing KEi on client. > Some crypto libraries do not allow that, they will erase all information > about the > Diffie-Hellman pieces when the Diffie-Hellman calculation is finished. > Actually security considerations section of RFC 4306 does assume that: > It is assumed that all Diffie-Hellman exponents are erased from > memory after use. In particular, these exponents MUST NOT be derived > from long-lived secrets like the seed to a pseudo-random generator > that is not erased after use. [Peny] Well, basically, I agree that DH exponentiations will not be used for a long time according to RFC4306. However, I don't think RFC 4306 assumes to erase the DH exponentiations after the CALCULATION is finished. It just said the DH exponent is assumed to be erased after USE. If we need to USE it in the session resumption, I think RFC4306 does not oppose us from using it before the renewing of DH exponent. And, RFC4306 does not set the limit on reusing the DH exponentiations, as well. The extension of IKE_SA_INIT just uses the renewed DH exponent once during the session resumption. And in session resumption, it will not fall into different DH exchange group of previous DH exchange. Personally, I don't encourage using DH exponents for a long time. But, it's worthy to re-using it for the infrequent session resumption. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 20 08:54:36 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 BF2763A6943; Thu, 20 Nov 2008 08:54:36 -0800 (PST) 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 80C823A6948 for ; Thu, 20 Nov 2008 08:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 SKhAwhOwmVoB for ; Thu, 20 Nov 2008 08:54:34 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 4F7333A67FA for ; Thu, 20 Nov 2008 08:54:31 -0800 (PST) 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 mAKGsPSY010028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 18:54:25 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mAKGsPS7005839; Thu, 20 Nov 2008 18:54:25 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18725.38465.514910.498528@fireball.kivinen.iki.fi> Date: Thu, 20 Nov 2008 18:54:25 +0200 From: Tero Kivinen To: "Peny Yang" In-Reply-To: <4c5c7a6d0811200736k4b60968dwdc66d93a8f89532b@mail.gmail.com> References: <4c5c7a6d0811172219j96ce787qd265ded48f4c60b6@mail.gmail.com> <18723.8781.499111.51370@fireball.kivinen.iki.fi> <4c5c7a6d0811181416h4ec9f7bew9579dbcf56f424bf@mail.gmail.com> <18724.14284.263786.286763@fireball.kivinen.iki.fi> <4c5c7a6d0811200736k4b60968dwdc66d93a8f89532b@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 13 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Comment on draft-ietf-ipsecme-ikev2-resumption-00 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 Peny Yang writes: > [Peny] Yeah. It's already complicated. But, some states need to be > added, no matter we add new IKE_SESSION_RESUME or extend the > IKE_SA_INIT. Do you have any good idea to avoid the modification of > IKEv2 state machine? One of the main points is to keep the implementation separate, so we can easily make version that does not support it if customer wants so. Adding lots of ifdefs around gets code very messy, it is much easier to have separate state machine part for the IKE_SESSION_RESUME. Modular design is good thing... > > Not true, as IKE_SA_INIT does not have any protection as such, the > > contents of it is protected by the AUTH payload in IKE_AUTH exchange. > > There is no encrypted part in that, and in normally does not even have > > crypto context at that point. Adding encrypted SK {} part is designing > > new way to protect the mssages. > [Peny] You are right. In my opinion, the SK{} part is not necessary to > present the ticket. The whole security of the resumption comes from that part, as it is only thing that proofs that the client actually was part of the IKE SA before, and knows the SK_d which used to create the keying material used to protect SK_D. > > You do assume that crypto library allows exponent reuse. > [Peny] Yes, I do assume reusing KEi on client. I do know that our crypto library does not allow doing that (unless we specifically add support for that)... so we would have to recalculate the KEi every time. I think one of the reasons for that was related to FIPS certificate, but don't remember exactly. > as well. The extension of IKE_SA_INIT just uses the renewed DH > exponent once during the session resumption. And in session > resumption, it will not fall into different DH exchange group of > previous DH exchange. Personally, I don't encourage using DH exponents > for a long time. But, it's worthy to re-using it for the infrequent > session resumption. I would still prefer separate IKE_SESSION_RESUME exchange than combining everything to the IKE_SA_INIT. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 20 09:37: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 18BFD3A6A3B; Thu, 20 Nov 2008 09:37:21 -0800 (PST) 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 4384C28C1A4 for ; Thu, 20 Nov 2008 09:37:20 -0800 (PST) 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 O48ySsKHf28U for ; Thu, 20 Nov 2008 09:37:19 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 1FC253A6A34 for ; Thu, 20 Nov 2008 09:37:19 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so250493yxg.49 for ; Thu, 20 Nov 2008 09:37:17 -0800 (PST) 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=1ft562wzlZaMxtdZAzfxKg7SjXPxALn/PbRhElSUOeU=; b=Eptj2ZBw7AdPE3FcbTwBWwwQRVUloII42U+G7M/4UuLI0uRLzZQjThJFPrnTANGd6L YTr1LTIuQ6fYJ1vMrdgoBjG6Y2JUoXCJx3NAlsWoPXymBb+yNE8UQP3CGqpGd0dHJzNL kxBFiMtDV8gWKx4m1p8ZTmZ5boUqxl97SG14c= 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=sxPuPFHJYhWcmshnP2C+O9nnwg+z+wWi9LueqRtyQ6OO53k/CKUzcmCpYoTCq2ZCem I1JuxJDOE2dkpC4SIf7sCV3XlgvCWP0awKJ7LrrlDyHHaFzDN+rU9iSQ6KH2jdLEUSt9 W82wdpbfukf3wDz4LX7BOfDbAzFyO+FiB2zcE= Received: by 10.142.44.11 with SMTP id r11mr1238888wfr.249.1227202637288; Thu, 20 Nov 2008 09:37:17 -0800 (PST) Received: by 10.142.211.4 with HTTP; Thu, 20 Nov 2008 09:37:17 -0800 (PST) Message-ID: <4c5c7a6d0811200937s5e548215ueb64202219abb46f@mail.gmail.com> Date: Fri, 21 Nov 2008 01:37:17 +0800 From: "Peny Yang" To: "Tero Kivinen" In-Reply-To: <18725.38465.514910.498528@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline References: <4c5c7a6d0811172219j96ce787qd265ded48f4c60b6@mail.gmail.com> <18723.8781.499111.51370@fireball.kivinen.iki.fi> <4c5c7a6d0811181416h4ec9f7bew9579dbcf56f424bf@mail.gmail.com> <18724.14284.263786.286763@fireball.kivinen.iki.fi> <4c5c7a6d0811200736k4b60968dwdc66d93a8f89532b@mail.gmail.com> <18725.38465.514910.498528@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org Subject: Re: [IPsec] Comment on draft-ietf-ipsecme-ikev2-resumption-00 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 Fri, Nov 21, 2008 at 12:54 AM, Tero Kivinen wrote: > One of the main points is to keep the implementation separate, so we > can easily make version that does not support it if customer wants so. > Adding lots of ifdefs around gets code very messy, it is much easier > to have separate state machine part for the IKE_SESSION_RESUME. > Modular design is good thing... [Peny] Then we disagree on this point. Well, it's hard to judge at this moment. IMHO, adding 1 (at most two depending on the state operation) state in the state machine is not a big deal at all for the implementation. Anyhow, it's not so productive to debate on this point any more. > The whole security of the resumption comes from that part, as it is > only thing that proofs that the client actually was part of the IKE SA > before, and knows the SK_d which used to create the keying material > used to protect SK_D. [Peny] I don't think the client has to proof to be part of previous IKE SA by this way. SK_d can be found by reference or be inside the ticket. Server side can cross check the information in the IKE_SA_INIT with the content referenced/stored by ticket, as well. > I do know that our crypto library does not allow doing that (unless we > specifically add support for that)... so we would have to recalculate > the KEi every time. I think one of the reasons for that was related to > FIPS certificate, but don't remember exactly. [Peny] At least some open source implementation already can simply store the DH exponent for a while before next renew of DH. > I would still prefer separate IKE_SESSION_RESUME exchange than > combining everything to the IKE_SA_INIT. [Peny] Well, all the implementations have different perspectives. Anyhow, if there are the requirements to extend the existed messages for flexibility and efficiency, IMHO, we would need to support that. Peny _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 20 11:07: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 9DFB83A6898; Thu, 20 Nov 2008 11:07:49 -0800 (PST) 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 5CACE3A6898 for ; Thu, 20 Nov 2008 11:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 h4nL7mApBm4M for ; Thu, 20 Nov 2008 11:07:47 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 2B8193A6835 for ; Thu, 20 Nov 2008 11:07:46 -0800 (PST) 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 mAKJ7cDi003701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 21:07:38 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mAKJ7cZY019156; Thu, 20 Nov 2008 21:07:38 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18725.46458.16633.231340@fireball.kivinen.iki.fi> Date: Thu, 20 Nov 2008 21:07:38 +0200 From: Tero Kivinen To: "Peny Yang" In-Reply-To: <4c5c7a6d0811200937s5e548215ueb64202219abb46f@mail.gmail.com> References: <4c5c7a6d0811172219j96ce787qd265ded48f4c60b6@mail.gmail.com> <18723.8781.499111.51370@fireball.kivinen.iki.fi> <4c5c7a6d0811181416h4ec9f7bew9579dbcf56f424bf@mail.gmail.com> <18724.14284.263786.286763@fireball.kivinen.iki.fi> <4c5c7a6d0811200736k4b60968dwdc66d93a8f89532b@mail.gmail.com> <18725.38465.514910.498528@fireball.kivinen.iki.fi> <4c5c7a6d0811200937s5e548215ueb64202219abb46f@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 6 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Comment on draft-ietf-ipsecme-ikev2-resumption-00 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 Peny Yang writes: > > The whole security of the resumption comes from that part, as it is > > only thing that proofs that the client actually was part of the IKE SA > > before, and knows the SK_d which used to create the keying material > > used to protect SK_D. > [Peny] I don't think the client has to proof to be part of previous > IKE SA by this way. SK_d can be found by reference or be inside the > ticket. Server side can cross check the information in the IKE_SA_INIT > with the content referenced/stored by ticket, as well. It is mandatory to verify that one sending the ticket for resumption actually knows the SK_d too. Otherwise attacker who knows the ticket (for example have seen it sent by legitimate client when it tried to resumption) can send it to server and trigger server to think he has IKE SA up and running, without being part of the previous exchange. This would also cause the server to mark ticket as used and that would remove the original client the ability to use it anymore. I think the SK_d is mandatory there for the security of the protocol. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 20 11:43: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 04D0C3A6AF5; Thu, 20 Nov 2008 11:43:27 -0800 (PST) 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 171073A6BA8 for ; Thu, 20 Nov 2008 11:43:25 -0800 (PST) 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 X0B8DOHPe7eS for ; Thu, 20 Nov 2008 11:43:24 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id 3ACD43A686D for ; Thu, 20 Nov 2008 11:43:24 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so278158yxg.49 for ; Thu, 20 Nov 2008 11:43:22 -0800 (PST) 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=yE1bZjrN//UVqE9RR7kKRaXEcvHtH6IYYGrPrDVScrM=; b=T24A6DQuEjP79nOOHiQ9DO6P8xaHBGPs3bbjyRSYub+VKTVxnXyxk+p3kxOzdZLD/f Y71p0+Y/hYhL3qApmV88UybiHFzvKrNSEsrpTrofQXBR+5HNT6PzZRAQfCm0EKXLHL4O Pd6SizLL2p6mJ3KlQH20qHDJYdPDYQ0tlNmJI= 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=URtvGvGw0P7ByCUoF9jxDbkxvK2kfJVdlsiK68BK6DcdTYJkDa2lWTLqboeY2g9Jxd vB+ErkTIMXVaoY47DAo6g2Q4ZNeyhMhqUOGz9D2HybwojsnHa9+FDCS6ykcbYqxWrf41 eMCROMhgWgBfiqVQk/4B5agqgi2V38pF5xWxc= Received: by 10.142.231.7 with SMTP id d7mr1307831wfh.90.1227210201868; Thu, 20 Nov 2008 11:43:21 -0800 (PST) Received: by 10.142.211.4 with HTTP; Thu, 20 Nov 2008 11:43:21 -0800 (PST) Message-ID: <4c5c7a6d0811201143v154035a8ldab2a1311fd6b6e0@mail.gmail.com> Date: Fri, 21 Nov 2008 03:43:21 +0800 From: "Peny Yang" To: "Tero Kivinen" In-Reply-To: <18725.46458.16633.231340@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline References: <4c5c7a6d0811172219j96ce787qd265ded48f4c60b6@mail.gmail.com> <18723.8781.499111.51370@fireball.kivinen.iki.fi> <4c5c7a6d0811181416h4ec9f7bew9579dbcf56f424bf@mail.gmail.com> <18724.14284.263786.286763@fireball.kivinen.iki.fi> <4c5c7a6d0811200736k4b60968dwdc66d93a8f89532b@mail.gmail.com> <18725.38465.514910.498528@fireball.kivinen.iki.fi> <4c5c7a6d0811200937s5e548215ueb64202219abb46f@mail.gmail.com> <18725.46458.16633.231340@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org Subject: Re: [IPsec] Comment on draft-ietf-ipsecme-ikev2-resumption-00 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 > It is mandatory to verify that one sending the ticket for resumption > actually knows the SK_d too. Otherwise attacker who knows the ticket > (for example have seen it sent by legitimate client when it tried to > resumption) can send it to server and trigger server to think he has > IKE SA up and running, without being part of the previous exchange. > This would also cause the server to mark ticket as used and that would > remove the original client the ability to use it anymore. > > I think the SK_d is mandatory there for the security of the protocol. [Peny] Ticket is only valid for one time use. Some attacker has seen it from the legitimate client, the ticket is no longer useful after resumption. Peny _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 20 12:59: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 087C83A6A65; Thu, 20 Nov 2008 12:59:30 -0800 (PST) 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 5501D3A6A65 for ; Thu, 20 Nov 2008 12:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 JUDLsVeP9P+X for ; Thu, 20 Nov 2008 12:59:28 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 3DFD83A67F0 for ; Thu, 20 Nov 2008 12:59:27 -0800 (PST) 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 mAKKxIRu001212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 22:59:18 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mAKKxIT9024058; Thu, 20 Nov 2008 22:59:18 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18725.53158.748678.843699@fireball.kivinen.iki.fi> Date: Thu, 20 Nov 2008 22:59:18 +0200 From: Tero Kivinen To: "Peny Yang" In-Reply-To: <4c5c7a6d0811201143v154035a8ldab2a1311fd6b6e0@mail.gmail.com> References: <4c5c7a6d0811172219j96ce787qd265ded48f4c60b6@mail.gmail.com> <18723.8781.499111.51370@fireball.kivinen.iki.fi> <4c5c7a6d0811181416h4ec9f7bew9579dbcf56f424bf@mail.gmail.com> <18724.14284.263786.286763@fireball.kivinen.iki.fi> <4c5c7a6d0811200736k4b60968dwdc66d93a8f89532b@mail.gmail.com> <18725.38465.514910.498528@fireball.kivinen.iki.fi> <4c5c7a6d0811200937s5e548215ueb64202219abb46f@mail.gmail.com> <18725.46458.16633.231340@fireball.kivinen.iki.fi> <4c5c7a6d0811201143v154035a8ldab2a1311fd6b6e0@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 4 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Comment on draft-ietf-ipsecme-ikev2-resumption-00 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 Peny Yang writes: > [Peny] Ticket is only valid for one time use. Some attacker has seen > it from the legitimate client, the ticket is no longer useful after > resumption. Attacker might have seen it when the client tried to do resumption but could not because the network was still down, or attacker can take the ticket from the client's valid resumption message, change the SPIi and send it to server before client's message gets there, and that will cause the ticket to be invalid when client's message comes there. Which actually says that the SPIi of the resumption message needs to be authenticated, thus the SK_d is required to cover the whole IKE message. Also attacker can see the ticket if server decides to use cookie requests. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 20 13:17: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 7011328C0FD; Thu, 20 Nov 2008 13:17:07 -0800 (PST) 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 5761D3A6A47; Thu, 20 Nov 2008 13:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=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 NBiaic9Y5Kht; Thu, 20 Nov 2008 13:17:04 -0800 (PST) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 7149A3A6986; Thu, 20 Nov 2008 13:17:04 -0800 (PST) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1L3GtY-0006l8-2O; Thu, 20 Nov 2008 22:17:00 +0100 X-Hashcash: 1:20:081120:mext@ietf.org::LM4XO25YDRtCGlFq:00001l4R X-Hashcash: 1:20:081120:ipsec@ietf.org::oMfs5dZ6DKltxeRW:0000eOQ From: arno@natisbad.org (Arnaud Ebalard) To: IETF MEXT WG ML , IPsec IETF WG ML References: <4924C0CD.4030705@strongswan.org> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 Date: Thu, 20 Nov 2008 13:15:17 -0800 In-Reply-To: <4924C0CD.4030705@strongswan.org> (Andreas Steffen's message of "Thu, 20 Nov 2008 02:43:41 +0100") Message-ID: <87y6ze14m2.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Subject: [IPsec] MIGRATE/KMADDRESS support available in strongSwan 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, just a quick note for those interested by the topic. Andreas Steffen and Martin Willi have added support for MIGRATE/KMADDRESS in strongSwan IKEv2 daemon (Charon) as specified in [1]. > - Mobile IPv6 support > ------------------- > > Basic Mobile IPv6 support has been introduced, securing Binding Update > messages as well as tunneled traffic between Mobile Node and Home > Agent. The installpolicy=no option allows peaceful cooperation with > a dominant mip6d daemon and the new type=transport_proxy implements > the special MIPv6 IPsec transport proxy mode where the IKEv2 daemon > uses the Care-of-Address but the IPsec SA is set up for the Home > Address. > > http://wiki.strongswan.org/wiki/MobileIPv6 > > Fully supports migration of Mobile IPv6 connections making use of the > KMADDRESS field contained in XFRM_MSG_MIGRATE messages sent by the > mip6d daemon via the Linux 2.6.28 (or appropriately patched) kernel. Addition of support in racoon (IKEv1) daemon is ongoing. I will post a quick note on the list when it is completed. Cheers, a+ [1] http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 20 13:18:29 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 BE9763A6A09; Thu, 20 Nov 2008 13:18:29 -0800 (PST) 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 1A21E3A6A09 for ; Thu, 20 Nov 2008 13:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Ewig9qzTsmPU for ; Thu, 20 Nov 2008 13:18:28 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 50A773A677D for ; Thu, 20 Nov 2008 13:18:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1227215907; x=1258751907; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<4925D426.3070302@qualcomm.com>|Date:=20Th u,=2020=20Nov=202008=2013:18:30=20-0800|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Thun derbird=202.0.0.18=20(Windows/20081105)|MIME-Version:=201 .0|To:=20Tero=20Kivinen=20|CC:=20Peny=20Y ang=20,=20ipsec@ietf.org |Subject:=20Re:=20[IPsec]=20Comment=20on=20draft-ietf-ips ecme-ikev2-resumption-00|References:=20<4c5c7a6d081117221 9j96ce787qd265ded48f4c60b6@mail.gmail.com>=09<18723.8781. 499111.51370@fireball.kivinen.iki.fi>=09<4c5c7a6d08111814 16h4ec9f7bew9579dbcf56f424bf@mail.gmail.com>=09<18724.142 84.263786.286763@fireball.kivinen.iki.fi>=09<4c5c7a6d0811 200736k4b60968dwdc66d93a8f89532b@mail.gmail.com>=09<18725 .38465.514910.498528@fireball.kivinen.iki.fi>=09<4c5c7a6d 0811200937s5e548215ueb64202219abb46f@mail.gmail.com>=09<1 8725.46458.16633.231340@fireball.kivinen.iki.fi>=09<4c5c7 a6d0811201143v154035a8ldab2a1311fd6b6e0@mail.gmail.com> =20<18725.53158.748678.843699@fireball.kivinen.iki.fi> |In-Reply-To:=20<18725.53158.748678.843699@fireball.kivin en.iki.fi>|Content-Type:=20text/plain=3B=20charset=3DISO- 8859-15=3B=20format=3Dflowed|Content-Transfer-Encoding: =207bit|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,5440" =3B=20a=3D"13318250"; bh=GBjrvwQJMlt7QHmSi/WpbdF+hSV3vkLur2Ss0VaSPMw=; b=OVZaIoqznsHuh5Q5qBuXGFSZr07714ZUU5/Ye/kgOevMl4qUls5+1J+E pW9viveXND4vHFITua1WHorcP58WleZfsRSPnEeJ4nRwqUMHM6imMVLHa WkjIW6SUjnZwBm1Pp3s9tZjW58wYEeVsgx9LutWyxfaU40jNZCpxCBfRG E=; X-IronPort-AV: E=McAfee;i="5100,188,5440"; a="13318250" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Nov 2008 13:18:27 -0800 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAKLIQ2o013073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Nov 2008 13:18:27 -0800 Received: from [10.50.76.146] (qconnect-10-50-76-146.qualcomm.com [10.50.76.146]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAKLIPQT020800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Nov 2008 13:18:26 -0800 Message-ID: <4925D426.3070302@qualcomm.com> Date: Thu, 20 Nov 2008 13:18:30 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Tero Kivinen References: <4c5c7a6d0811172219j96ce787qd265ded48f4c60b6@mail.gmail.com> <18723.8781.499111.51370@fireball.kivinen.iki.fi> <4c5c7a6d0811181416h4ec9f7bew9579dbcf56f424bf@mail.gmail.com> <18724.14284.263786.286763@fireball.kivinen.iki.fi> <4c5c7a6d0811200736k4b60968dwdc66d93a8f89532b@mail.gmail.com> <18725.38465.514910.498528@fireball.kivinen.iki.fi> <4c5c7a6d0811200937s5e548215ueb64202219abb46f@mail.gmail.com> <18725.46458.16633.231340@fireball.kivinen.iki.fi> <4c5c7a6d0811201143v154035a8ldab2a1311fd6b6e0@mail.gmail.com> <18725.53158.748678.843699@fireball.kivinen.iki.fi> In-Reply-To: <18725.53158.748678.843699@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org, Peny Yang Subject: Re: [IPsec] Comment on draft-ietf-ipsecme-ikev2-resumption-00 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 Indeed! Lakshminath On 11/20/2008 12:59 PM, Tero Kivinen wrote: > Peny Yang writes: >> [Peny] Ticket is only valid for one time use. Some attacker has seen >> it from the legitimate client, the ticket is no longer useful after >> resumption. > > Attacker might have seen it when the client tried to do resumption but > could not because the network was still down, or attacker can take the > ticket from the client's valid resumption message, change the SPIi and > send it to server before client's message gets there, and that will > cause the ticket to be invalid when client's message comes there. > Which actually says that the SPIi of the resumption message needs to > be authenticated, thus the SK_d is required to cover the whole IKE > message. Also attacker can see the ticket if server decides to use > cookie requests. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 20 14:37: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 38CF33A69D8; Thu, 20 Nov 2008 14:37:21 -0800 (PST) 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 2FE8C3A69D8 for ; Thu, 20 Nov 2008 14:37:20 -0800 (PST) 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 TTtAJsnc3QOY for ; Thu, 20 Nov 2008 14:37:19 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id 29F293A6806 for ; Thu, 20 Nov 2008 14:37:19 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so312932ywj.49 for ; Thu, 20 Nov 2008 14:37:17 -0800 (PST) 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=/DxQ6CE6mzfsyDpvPGJJ4gL6lhXFJ5lVjMf7pc7tbZQ=; b=LlMruT/Zymg2EDIRzaIdd3K9N9Wac1pmdlx64MWTCsgIZaBiUDb7B2WbEIBxJXCNBn CG17tPInlj3sRn1nhGlMv3JO53PpkWsc0Iz6ODeJgUGNzlBxxAGiJBitKuk+spC9/mZ5 JmxTItGrYU0AF95Na1i9HS7J5NR+6NU/ZiXj0= 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=Y/S1EuO508Sj23uMGCq+ZrxhW8ci5RzAFKXZz6kpz+nul+NCd4RaZhbLDAtBmq6OxD sbsf+7K0QyTzR1qLfR5NEyptZRbdVWsbkXlXSlz7tS/HY+WJsF99ohKmYEoVkvVGcX6o VTLHJMc6pf30w9Lx1rQHHTAaC9LDcvE3bEGqw= Received: by 10.142.188.4 with SMTP id l4mr1384957wff.51.1227220636357; Thu, 20 Nov 2008 14:37:16 -0800 (PST) Received: by 10.142.211.4 with HTTP; Thu, 20 Nov 2008 14:37:16 -0800 (PST) Message-ID: <4c5c7a6d0811201437y21b830e9r81a6b2c9776c1f6@mail.gmail.com> Date: Fri, 21 Nov 2008 06:37:16 +0800 From: "Peny Yang" To: "Tero Kivinen" In-Reply-To: <18725.53158.748678.843699@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline References: <4c5c7a6d0811172219j96ce787qd265ded48f4c60b6@mail.gmail.com> <18723.8781.499111.51370@fireball.kivinen.iki.fi> <4c5c7a6d0811181416h4ec9f7bew9579dbcf56f424bf@mail.gmail.com> <18724.14284.263786.286763@fireball.kivinen.iki.fi> <4c5c7a6d0811200736k4b60968dwdc66d93a8f89532b@mail.gmail.com> <18725.38465.514910.498528@fireball.kivinen.iki.fi> <4c5c7a6d0811200937s5e548215ueb64202219abb46f@mail.gmail.com> <18725.46458.16633.231340@fireball.kivinen.iki.fi> <4c5c7a6d0811201143v154035a8ldab2a1311fd6b6e0@mail.gmail.com> <18725.53158.748678.843699@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org Subject: Re: [IPsec] Comment on draft-ietf-ipsecme-ikev2-resumption-00 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 > Attacker might have seen it when the client tried to do resumption but > could not because the network was still down, [Peny] Excuse me, what's the meaning of "network was done"? Do you mean the server was still down? > or attacker can take the > ticket from the client's valid resumption message, change the SPIi and > send it to server before client's message gets there, and that will > cause the ticket to be invalid when client's message comes there. > Which actually says that the SPIi of the resumption message needs to > be authenticated, thus the SK_d is required to cover the whole IKE > message. Also attacker can see the ticket if server decides to use > cookie requests. [Peny] Please let me clarify it firstly. In all of the cases above, when attackers can see the ticket, it can get other things (new SPIi in the HDR and SK{}), as well. So, in this sense, how could the server authenticate the SPIi with ticket and SK { IDi } (minimum version as you said)? Peny _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 20 14:45:04 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 429643A6A49; Thu, 20 Nov 2008 14:45:04 -0800 (PST) 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 3DC033A6876 for ; Thu, 20 Nov 2008 14:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 CDfS704SQ0Hx for ; Thu, 20 Nov 2008 14:45:01 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 16D773A677D for ; Thu, 20 Nov 2008 14:45:00 -0800 (PST) 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 mAKMiqZN018956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2008 00:44:52 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mAKMiqHm027406; Fri, 21 Nov 2008 00:44:52 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18725.59492.262348.580607@fireball.kivinen.iki.fi> Date: Fri, 21 Nov 2008 00:44:52 +0200 From: Tero Kivinen To: "Peny Yang" In-Reply-To: <4c5c7a6d0811201437y21b830e9r81a6b2c9776c1f6@mail.gmail.com> References: <4c5c7a6d0811172219j96ce787qd265ded48f4c60b6@mail.gmail.com> <18723.8781.499111.51370@fireball.kivinen.iki.fi> <4c5c7a6d0811181416h4ec9f7bew9579dbcf56f424bf@mail.gmail.com> <18724.14284.263786.286763@fireball.kivinen.iki.fi> <4c5c7a6d0811200736k4b60968dwdc66d93a8f89532b@mail.gmail.com> <18725.38465.514910.498528@fireball.kivinen.iki.fi> <4c5c7a6d0811200937s5e548215ueb64202219abb46f@mail.gmail.com> <18725.46458.16633.231340@fireball.kivinen.iki.fi> <4c5c7a6d0811201143v154035a8ldab2a1311fd6b6e0@mail.gmail.com> <18725.53158.748678.843699@fireball.kivinen.iki.fi> <4c5c7a6d0811201437y21b830e9r81a6b2c9776c1f6@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 2 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Comment on draft-ietf-ipsecme-ikev2-resumption-00 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 Peny Yang writes: > > Attacker might have seen it when the client tried to do resumption but > > could not because the network was still down, > [Peny] Excuse me, what's the meaning of "network was done"? Do you > mean the server was still down? Either one. If the attacker can fool the client to think the server is down by breaking the network link between them, that is enough to trigger the client to do resumption. > > or attacker can take the > > ticket from the client's valid resumption message, change the SPIi and > > send it to server before client's message gets there, and that will > > cause the ticket to be invalid when client's message comes there. > > Which actually says that the SPIi of the resumption message needs to > > be authenticated, thus the SK_d is required to cover the whole IKE > > message. Also attacker can see the ticket if server decides to use > > cookie requests. > [Peny] Please let me clarify it firstly. In all of the cases above, > when attackers can see the ticket, it can get other things (new SPIi > in the HDR and SK{}), as well. So, in this sense, how could the server > authenticate the SPIi with ticket and SK { IDi } (minimum version as > you said)? Because only client who knows the SK_d can calculate SK {} which has MAC of the full packet. So attacker cannot modify anything in the packet without server detecting it, if the ticket is still valid. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 20 15:03:52 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 01F8328C0FF; Thu, 20 Nov 2008 15:03:52 -0800 (PST) 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 4B90428C0FF for ; Thu, 20 Nov 2008 15:03:51 -0800 (PST) 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 htMCXr2iqVuM for ; Thu, 20 Nov 2008 15:03:50 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 7EF2828C0FA for ; Thu, 20 Nov 2008 15:03:50 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so316103yxg.49 for ; Thu, 20 Nov 2008 15:03:48 -0800 (PST) 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=JVCj9OYxwHuteQHSenb9aJjybautqGIXQy7v88pTR2c=; b=idLT3PwqoqQbRMO4T6s718ww9XNZMx8YOiHWIDTeJ5oTmVfzYre9b5DypW+f3DWjym wFCOdJMKJvzdvK7qg0wba5mMrL6+ti8qxUcIsIFtomSW7Z+9kgbUq1gek5Lnauv5GEVL h9PXGc4sNsrxZOOqrXT3iwem+VUo6fqnjlX+0= 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=TmhgdGaBLwSY0xHviqOdje+VWthJ8C4iQQty/p6hSMpfpLM+JdKcTlrr8Q+07uJrY2 r0fTWVF/6I/+hwF0wII/tXEns1wp45BiX3f09iVqbHISFOLQDE+Pm0j5odf87alj6j8c vXdlm29xigyzQhWZ0RzlLQC+yt2fH0NsQXFk8= Received: by 10.142.51.4 with SMTP id y4mr1392499wfy.116.1227222227512; Thu, 20 Nov 2008 15:03:47 -0800 (PST) Received: by 10.142.211.4 with HTTP; Thu, 20 Nov 2008 15:03:47 -0800 (PST) Message-ID: <4c5c7a6d0811201503w4b8cf58dp8f33c0371026fc43@mail.gmail.com> Date: Fri, 21 Nov 2008 07:03:47 +0800 From: "Peny Yang" To: "Tero Kivinen" In-Reply-To: <18725.59492.262348.580607@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline References: <4c5c7a6d0811172219j96ce787qd265ded48f4c60b6@mail.gmail.com> <18724.14284.263786.286763@fireball.kivinen.iki.fi> <4c5c7a6d0811200736k4b60968dwdc66d93a8f89532b@mail.gmail.com> <18725.38465.514910.498528@fireball.kivinen.iki.fi> <4c5c7a6d0811200937s5e548215ueb64202219abb46f@mail.gmail.com> <18725.46458.16633.231340@fireball.kivinen.iki.fi> <4c5c7a6d0811201143v154035a8ldab2a1311fd6b6e0@mail.gmail.com> <18725.53158.748678.843699@fireball.kivinen.iki.fi> <4c5c7a6d0811201437y21b830e9r81a6b2c9776c1f6@mail.gmail.com> <18725.59492.262348.580607@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org Subject: Re: [IPsec] Comment on draft-ietf-ipsecme-ikev2-resumption-00 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 > Because only client who knows the SK_d can calculate SK {} which has > MAC of the full packet. So attacker cannot modify anything in the > packet without server detecting it, if the ticket is still valid. [Peny] OK, Agree. Well, what if the IKE_SA_INIT message is extended by adding SK{} only for session resumption ? Peny _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Nov 20 15:59:22 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 8E9233A68F1; Thu, 20 Nov 2008 15:59:22 -0800 (PST) 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 142F33A6935 for ; Thu, 20 Nov 2008 15:59:21 -0800 (PST) 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 T8MNSa+vd4-1 for ; Thu, 20 Nov 2008 15:59:14 -0800 (PST) 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 B99A73A68F1 for ; Thu, 20 Nov 2008 15:59:13 -0800 (PST) Received: from [130.129.94.237] ([130.129.47.239]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAKNx9ew038874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Nov 2008 16:59:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 20 Nov 2008 17:59:06 -0600 To: IPsecme WG From: Paul Hoffman Subject: [IPsec] Fwd: [Errata Verified] RFC4308 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 >Date: Thu, 20 Nov 2008 14:09:57 -0800 (PST) >To: paul.hoffman@vpnc.org, paul.hoffman@vpnc.org >Subject: [Errata Verified] RFC4308 >From: RFC Errata System >Cc: tim.polk@nist.gov, iesg@iesg.org, rfc-editor@rfc-editor.org >X-ISI-4-43-8-MailScanner: Found to be clean >X-MailScanner-From: web-usrn@boreas.isi.edu > > >The following errata report has been verified for RFC4308, >"Cryptographic Suites for IPsec". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=4308&eid=1090 > >-------------------------------------- >Status: Verified >Type: Technical > >Reported by: Paul Hoffman >Date Reported: 2007-12-08 >Verified by: Tim Polk (IESG) > >Section: 2 > >Original Text >------------- > > >Corrected Text >-------------- >2.4 Hash Algorithm for IKEv1 > >This document does not specify a hash algorithm to negotiate for IKEv1. Any hash algorithm can be used; SHA-1 is a common choice. No hash algorithm is needed for IKEv2. > >Notes >----- >This was accidentally omitted during the discussion of this document. > >-------------------------------------- >RFC4308 (draft-ietf-ipsec-ui-suites-06) >-------------------------------------- >Title : Cryptographic Suites for IPsec >Publication Date : December 2005 >Author(s) : P. Hoffman >Category : PROPOSED STANDARD >Source : IP Security Protocol >Area : Security >Stream : IETF >Verifying Party : IESG _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 21 02:05: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 1BCE23A691C; Fri, 21 Nov 2008 02:05:46 -0800 (PST) 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 9C2553A691C for ; Fri, 21 Nov 2008 02:05:44 -0800 (PST) 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 C45vNFuKTsy6 for ; Fri, 21 Nov 2008 02:05:43 -0800 (PST) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id BD9223A683E for ; Fri, 21 Nov 2008 02:05:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="scan'208,217";a="34216511" Received: from ind-dkim-2.cisco.com ([64.104.140.59]) by ind-iport-1.cisco.com with ESMTP; 21 Nov 2008 10:05:32 +0000 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mALA5Uos018835; Fri, 21 Nov 2008 15:35:30 +0530 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by india-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mALA5Q2c016106; Fri, 21 Nov 2008 10:05:30 GMT Received: from XMB-BLR-419.apac.cisco.com ([64.104.140.154]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 15:35:25 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 15:35:24 +0530 Message-ID: In-Reply-To: <18724.29181.897230.111045@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Question on CP payload Thread-Index: AclKgocj0FC6j20TRCi47oBLRJhzfQBOI0tw References: <18724.29181.897230.111045@fireball.kivinen.iki.fi> From: "Raghunandan P (raghup)" To: "Tero Kivinen" X-OriginalArrivalTime: 21 Nov 2008 10:05:25.0778 (UTC) FILETIME=[AC915720:01C94BC0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12609; t=1227261930; x=1228125930; c=relaxed/simple; s=inddkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=raghup@cisco.com; z=From:=20=22Raghunandan=20P=20(raghup)=22=20 |Subject:=20RE=3A=20[IPsec]=20=20Question=20on=20CP=20paylo ad |Sender:=20; bh=DpM92AFT60DufPiKLtgKTBW8IOt8PraljGlaGL8Df0o=; b=67nlpkvN9wYyuXwHleUhL0FrDGfz7q3DfrCah5BnriUnUiZRkBkhiU2siY 2sxf8zIoL0fx/Hgv6rSQc5e4D4WJqpUCa6oaAou5YB68fQmKvVoJfB8f6yZo ILheddYcIG; Authentication-Results: ind-dkim-2; header.From=raghup@cisco.com; dkim=pass ( sig from cisco.com/inddkim2002 verified; ); Cc: ipsec@ietf.org Subject: Re: [IPsec] Question on CP payload 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="===============1533393044==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1533393044== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C94BC0.AC45D75A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C94BC0.AC45D75A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tero, Thanks for the information. Please see my response/clarifications below. Regards Raghu -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen Sent: Thursday, November 20, 2008 1:37 AM To: Raghunandan P (raghup) Cc: ipsec@ietf.org Subject: [IPsec] Question on CP payload Raghunandan P (raghup) writes: > 1. The CP payload can be exchanged as part of the AUTH_EXCHANGE and > can also be sent separately as part of informational message. Is that > correct? Can we have a scenario where CP payload is sent as part of > the AUTH_EXCHANGE and also separately as an informational message (in > both the exchanges)? Yes, Configuration payloads can be sent as separate INFORMATIONAL exchange after the IKE_AUTH. Some reason to do it after IKE_AUTH as INFORMATIONAL exchange is if the client wants to get another address, for example it originally only requirested IPv4 address, and now wants to get IPv6 address too. >>>Start=20 A) Thanks for the info. In case the client gets an IPv6 address in the informational exchange response, will a new IPSec IPv6 SA be established with this IPv6 pushed address that would be used for IPv6 traffic? I assume that the ipsec ipv4 SA would still be there for the previously obtained IPv4 pushed address. Correct? B) Would there be a possibility of the client getting a new IPv4 address in the informational exchange response different from the IPv4 address obtained in the AUTH_EXCHANGE. If yes, under what scenarios is this possible? Since the INTERNAL_ADDRESS_EXPIRY is no longer supported as an attribute type in the CP payload (as per the draft), the case of client requesting for an address due to a lifetime expiry is ruled out. If the above is true, how should we handle the new IPv4 address obtained? Would we delete the older IPsec SA that was constructed with the previously obtained pushed address and create a new IPSec SA for the new address? Or Have both the IPSec SAs? (I dont think this is possible as client would not know which IPSec SA to use). If we are deleting the older SA, which one of the below methods is used? b1) First create the new ipsec SA and then delete the older ipsec SA under the same IKE SA. OR b2) Delete the IPSec SA which will also delete the IKE SA since that was the last IPSec SA. Now construct a new IKE SA and a new IPSec SA using the newly pushed address. =20 >>>End > 2. Suppose there is a scanario where CP payload has been exchanged as > part of XAUTH exchange and suppose the config mode reply has pushed an ^^^^^ XAUTH? I assume you mean IKE_AUTH? >>>Yes, I meant IKE AUTH_EXCHANGE. > IP address of 3.3.3.3. Now, suppose Tsi agrred upon is 1.1.1.1 and Tsr > agrred upon is 2.2.2.2 which means that any traffic from 1.1.1.1 to > 2.2.2.2 needs to be NATed to 3.3.3.3 and protected by the child SA. > Hence, a child SA will be setup with 3.3.3.3 to 2.2.2.2. Is that > correct? I am not sure what you are asking here. There isn't any NATs there in general case. Normally the client proposes the TSi of any to the responder and responder will then assign the address (3.3.3.3 in this case), and it will then narrow down the proposal initiator make to that. >>> Yes, NAT is purely implementation dependent. Its not applicable in this case. > Assuming above is true, both IKE SA and child SA have been set up. > Now, suppose a CP payload is exchanged as part of informational > exchange and a new IP address is pushed to the client as part of this > message. Is this possible? Yes. > If yes, what would happen to the existing IPsec SA. Will it be deleted > and new child SA set up? OR will a new child SA be set up? > OR existing child SA modified? Nothing will happen to the existing IPsec SAs. The original addresses assigned to the client are still valid, so there is no point of doing anything to them. Existing SAs are not deleted and they are not modified. > 3. Suppose we have the normal SA_INIT and AUTH_EXCHANGE which create > an IKE SA and a child SA without any configuration messages exchanged > during these exchanges. After this is done, now suppose the CP > payloads are exchanged as part of the informational exchange and the > peer pushes a new IP address to the client. What would happen to the > existing child SA? Nothing will happen to them. They stay there and can be used as before. > Will it be modified to take into account the new pushed address or > will the existing child SA be deleted and a new one set up? They are not modified, and are not automatically deleted. If the client wants to use the new IP-address it has been pushed to it most likely needs to create new IPsec SA that allows that traffic also, as the SAs created before most likely do not allow that traffic. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 ------_=_NextPart_001_01C94BC0.AC45D75A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tero,
Thanks for the information. Please see my=20 response/clarifications = below.

Regards
Raghu

-----Original=20 Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]= On=20 Behalf Of Tero Kivinen
Sent: Thursday, November 20, 2008 1:37 = AM
To:=20 Raghunandan P (raghup)
Cc: ipsec@ietf.org
Subject: [IPsec] = Question on CP=20 payload

Raghunandan P (raghup) writes:
> 1. The CP payload = can be=20 exchanged as part of the AUTH_EXCHANGE and
> can also be sent = separately=20 as part of informational message. Is that
> correct? Can we have a = scenario where CP payload is sent as part of
> the AUTH_EXCHANGE = and also=20 separately as an informational message (in
> both the=20 exchanges)?

Yes, Configuration payloads can be sent as separate=20 INFORMATIONAL exchange after the IKE_AUTH. Some reason to do it after = IKE_AUTH=20 as INFORMATIONAL exchange is if the client wants to get another address, = for=20 example it originally only requirested IPv4 address, and now wants to = get IPv6=20 address too.

>>>Start
A) Thanks for the info. In case the = client gets=20 an IPv6 address in the informational exchange response, will a new IPSec = IPv6 SA=20 be established with this IPv6 pushed address that would be used for IPv6 = traffic? I assume that the ipsec ipv4 SA would still be there for the = previously=20 obtained IPv4 pushed address. Correct?

B) Would there be a = possibility of=20 the client getting a new IPv4 address in the informational exchange = response=20 different from the IPv4 address obtained in the AUTH_EXCHANGE. = If yes,=20 under what scenarios is this possible? Since the = INTERNAL_ADDRESS_EXPIRY is=20 no longer supported as an attribute type in the CP payload (as per the = draft),=20  the case of client requesting for an address due to a lifetime = expiry is=20 ruled out.

If the above is true, how should we handle the = new IPv4=20 address obtained? Would we delete the older IPsec SA that was = constructed with=20 the previously obtained pushed address and create a new IPSec SA for the = new=20 address? Or Have both the IPSec SAs? (I dont think this is possible=20 as client would not know which IPSec SA to use).  If = we are=20 deleting the older SA, which one of the below methods is=20 used?

    b1) First create the new = ipsec SA and=20 then delete the older ipsec SA under the same IKE=20 SA.  OR

    b2) Delete the IPSec SA which = will also=20 delete the IKE SA since that was the last IPSec SA. Now construct a new = IKE SA=20 and a new IPSec SA using the newly pushed address.

 

>>>End

> 2. Suppose there is a scanario where CP payload = has been=20 exchanged as
> part of XAUTH exchange and suppose the config mode = reply=20 has pushed an
         =20 ^^^^^
XAUTH? I assume you mean IKE_AUTH?

>>>Yes, I meant IKE=20 AUTH_EXCHANGE.


> IP address of 3.3.3.3. Now, suppose Tsi agrred upon is = 1.1.1.1 and=20 Tsr
> agrred upon is 2.2.2.2 which means that any traffic from = 1.1.1.1=20 to
> 2.2.2.2 needs to be NATed to 3.3.3.3 and protected by the = child=20 SA.
> Hence, a child SA will be setup with 3.3.3.3 to 2.2.2.2. Is=20 that
> correct?

I am not sure what you are asking here. = There isn't=20 any NATs there in general case. Normally the client proposes the TSi of = any to=20 the responder and responder will then assign the address (3.3.3.3 in = this case),=20 and it will then narrow down the proposal initiator make to = that.

>>> Yes, NAT is purely implementation = dependent.=20 Its not applicable in this case.


> Assuming above is true, both IKE SA and child SA have been = set=20 up.
> Now, suppose a CP payload is exchanged as part of=20 informational
> exchange and a new IP address is pushed to the = client as=20 part of this
> message. Is this possible?

Yes.

> = If yes,=20 what would happen to the existing IPsec SA. Will it be deleted
> = and new=20 child SA set up? OR will a new child SA be set up?
> OR existing = child SA=20 modified?

Nothing will happen to the existing IPsec SAs. The = original=20 addresses assigned to the client are still valid, so there is no point = of doing=20 anything to them. Existing SAs are not deleted and they are not=20 modified.

> 3. Suppose we have the normal SA_INIT and = AUTH_EXCHANGE=20 which create
> an IKE SA and a child SA without any configuration = messages=20 exchanged
> during these exchanges. After this is done, now = suppose the=20 CP
> payloads are exchanged as part of the informational exchange = and=20 the
> peer pushes a new IP address to the client. What would = happen to=20 the
> existing child SA?

Nothing will happen to them. They = stay=20 there and can be used as before.

> Will it be modified to take = into=20 account the new pushed address or
> will the existing child SA be = deleted=20 and a new one set up?

They are not modified, and are not = automatically=20 deleted. If the client wants to use the new IP-address it has been = pushed to it=20 most likely needs to create new IPsec SA that allows that traffic also, = as the=20 SAs created before most likely do not allow that=20 traffic.
--
kivinen@iki.fi
_____________________________________= __________
IPsec=20 mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

------_=_NextPart_001_01C94BC0.AC45D75A-- --===============1533393044== 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 --===============1533393044==-- From ipsec-bounces@ietf.org Fri Nov 21 07:30:04 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 E8CA93A67E2; Fri, 21 Nov 2008 07:30:03 -0800 (PST) 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 887553A67E2 for ; Fri, 21 Nov 2008 07:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 8unsKAezJEcm for ; Fri, 21 Nov 2008 07:30:01 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 333C13A6784 for ; Fri, 21 Nov 2008 07:30:00 -0800 (PST) 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 mALFTlvw022412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2008 17:29:47 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mALFTkSX003621; Fri, 21 Nov 2008 17:29:46 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18726.54250.743713.259337@fireball.kivinen.iki.fi> Date: Fri, 21 Nov 2008 17:29:46 +0200 From: Tero Kivinen To: "Raghunandan P (raghup)" In-Reply-To: References: <18724.29181.897230.111045@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 11 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Question on CP payload 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 Raghunandan P (raghup) writes: >> Yes, Configuration payloads can be sent as separate INFORMATIONAL >> exchange after the IKE_AUTH. Some reason to do it after IKE_AUTH as >> INFORMATIONAL exchange is if the client wants to get another address, >> for example it originally only requirested IPv4 address, and now wants >> to get IPv6 address too. > > A) Thanks for the info. In case the client gets an IPv6 address in the > informational exchange response, will a new IPSec IPv6 SA be established > with this IPv6 pushed address that would be used for IPv6 traffic? Client needs to create new IPsec SAs for those IPv6 traffic, i.e. after getting the IPv6 address it can simply do create child sa exchange with traffic selectors matching the IPv6 address and create new IPsec SA for that use. > I assume that the ipsec ipv4 SA would still be there for the > previously obtained IPv4 pushed address. Correct? Yes. > B) Would there be a possibility of the client getting a new IPv4 address > in the informational exchange response different from the IPv4 address > obtained in the AUTH_EXCHANGE. Yes, that would be possible. > If yes, under what scenarios is this possible? I am not sure if there is real scenarios where this can happen, as it does require the client to do start informational exchange to request new IP-address, but perhaps it could be possible in cases where client realizes after the initial IKE_AUTH that he needs multiple IPv4 addresses, and requests more of them. This is something that is not that well defined, i.e. can server return just the same address it did last time, or what? I.e. does the client need to ask for 2 addresses, and prefilling one with the address it already has, so server can give 2 addresses, where one is new and one is the same old one client already had. But as long as we do not have any real scenario where this would be needed, I do not think we need to waste our time to specify exactly how it is supposed to work... > Since the INTERNAL_ADDRESS_EXPIRY is no longer supported as an > attribute type in the CP payload (as per the draft), the case of client > requesting for an address due to a lifetime expiry is ruled out. Yes. > If the above is true, how should we handle the new IPv4 address > obtained? Would we delete the older IPsec SA that was constructed with > the previously obtained pushed address and create a new IPSec SA for the > new address? As the old IPv4 address is still valid until the IKE SA is deleted (ikev2bis text), then there is no need to delete or do anything for the old IPsec SAs. > Or Have both the IPSec SAs? (I dont think this is possible as client > would not know which IPSec SA to use). As it was the client who requested the get the another IP-address, client should have some way to know why it wanted it and it needs to have some kind of method to know which of them is used for which traffic. > If we are deleting the older SA, which one of the below methods is > used? No need to delete it. > b1) First create the new ipsec SA and then delete the older ipsec SA > under the same IKE SA. OR This is one way of doing it. > b2) Delete the IPSec SA which will also delete the IKE SA since that > was the last IPSec SA. Now construct a new IKE SA and a new IPSec SA > using the newly pushed address. Deleting last IPsec SA DOES NOT delete the IKE SA. IKE SA can exists even without any IPsec SAs, so you can delete the IPsec SA, and then recreate the IPsec SA using the same IKE SA, even when the deleted IPsec SA was last in the IKE SA. You can also just delete the IKE SA and start over and create new IKE SA and ask new addresses in the configuration payload of the IKE_AUTH, but in that case it would be no need to do configuration payload in the INFORMATIONAL exchange before deleting IKE SA, if you are going to delete IKE SA anyways. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Nov 24 11:11: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 EB2E53A699E; Mon, 24 Nov 2008 11:11:14 -0800 (PST) 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 9846D3A6826 for ; Mon, 24 Nov 2008 11:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 d3SKqfNoepHl for ; Mon, 24 Nov 2008 11:11:11 -0800 (PST) Received: from g5t0009.atlanta.hp.com (g5t0009.atlanta.hp.com [15.192.0.46]) by core3.amsl.com (Postfix) with ESMTP id 4E6393A679C for ; Mon, 24 Nov 2008 11:11:10 -0800 (PST) Received: from G6W0641.americas.hpqcorp.net (g6w0641.atlanta.hp.com [16.230.34.77]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0009.atlanta.hp.com (Postfix) with ESMTPS id 128FE30181 for ; Mon, 24 Nov 2008 19:11:06 +0000 (UTC) Received: from G5W0323.americas.hpqcorp.net (16.228.8.68) by G6W0641.americas.hpqcorp.net (16.230.34.77) with Microsoft SMTP Server (TLS) id 8.1.263.0; Mon, 24 Nov 2008 19:10:25 +0000 Received: from GVW0538EXC.americas.hpqcorp.net ([16.228.8.54]) by G5W0323.americas.hpqcorp.net ([16.228.8.68]) with mapi; Mon, 24 Nov 2008 19:10:25 +0000 From: "He, Wenxiao" To: "ipsec@ietf.org" Date: Mon, 24 Nov 2008 19:10:24 +0000 Thread-Topic: [Ipsec] RFC 4301 and ICMP processing Thread-Index: AclKX85vysvDk/5XQn6cRulbzoddVwAQXMVwAPG57SA= Message-ID: <769907F0D19EFA45BD6F04FC6E896D6D1EC07E8312@GVW0538EXC.americas.hpqcorp.net> References: <4c5c7a6d0811172219j96ce787qd265ded48f4c60b6@mail.gmail.com> <18723.8781.499111.51370@fireball.kivinen.iki.fi> <4c5c7a6d0811181416h4ec9f7bew9579dbcf56f424bf@mail.gmail.com> <18724.14284.263786.286763@fireball.kivinen.iki.fi> <769907F0D19EFA45BD6F04FC6E896D6D1EBF8468A7@GVW0538EXC.americas.hpqcorp.net> In-Reply-To: <769907F0D19EFA45BD6F04FC6E896D6D1EBF8468A7@GVW0538EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [IPsec] [Ipsec] RFC 4301 and ICMP processing 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, Anyone has an opinion on processing ICMP error message as an IPsec end host? Thanks, Wenxiao > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of He, Wenxiao > Sent: Wednesday, November 19, 2008 4:35 PM > To: ipsec@ietf.org > Subject: Re: [IPsec] [Ipsec] RFC 4301 and ICMP processing > > > Hello, > > I am trying to figure out the requirements of processing ICMP > error message as an IPsec end host. > > Just googled and noticed that there was a discussion (took > place on Tue, 31 Jul 2007) on ICMP topic but focusing on > gateway. The original discussion is copied at the end of this message. > > Now, consider a simple end-to-end case between host A and > host B. The SPD between A and B only specifies a SA for UDP, > and there is no SPD to cover ICMP traffic. When host A sends > a UDP message to host B, a SA pair is negotiated. And the > A->B UDP message triggers host B to send back an ICMP error message. > > A) If I apply section 6.2 "Processing Protected, Transit ICMP > Error Messages" to the B->A ICMP error message, the icmp > error message will be carried by the extant SA pair generated > by UDP message. > > B) If I donot apply the process specified in section 6.2, > then the ICMP ERROR message will be discarded because no SPD is found. > > Which of the above two approaches is the expected behavior > for an IPsec end host? Does section 6 apply to IPsec end host? > > Thanks, > Wenxiao He > > ========================================== > > [Date Prev][Date Next][Thread Prev][Thread Next][Date > Index][Thread Index] > Re: [Ipsec] RFC 4301 and ICMP processing > > * To: Stephen Kent > * Subject: Re: [Ipsec] RFC 4301 and ICMP processing > * From: Scott C Moonen > * Date: Tue, 31 Jul 2007 16:08:18 -0400 > * Cc: ipsec at ietf.org > * In-reply-to: > * List-help: > * List-id: IP Security > * List-post: > * List-subscribe: > , > > * List-unsubscribe: > , > > > > Thanks for the very quick response, Stephen! > > Scott Moonen (smoonen at us.ibm.com) > http://scott.andstuff.org/ > > > Stephen Kent > > 07/31/2007 03:44 PM > > To > Scott C Moonen/Raleigh/IBM at IBMUS cc > ipsec at ietf.org > Subject > Re: [Ipsec] RFC 4301 and ICMP processing > > > > > > > At 11:52 AM -0600 7/31/07, Scott C Moonen wrote: > Content-Type: multipart/signed; > protocol="application/x-pkcs7-signature"; > micalg=sha1; boundary=-------z66_boundary_sign > > In section 6.2, RFC 4301 requires the use of additional > checks to verify whether an ICMP packet is consistent with an > SA's selectors. When sending or receiving an ICMP packet, if > there is no existing SA or SPD entry to match the ICMP error, > then the ICMP packet is allowed to traverse the same SA that > its embedded packet would have traversed. > > It is reasonably clear what is to be done for an end-to-end > SA, but the RFC's language is unclear as to whether this is > required for a gateway SA. Consider the following setup: > > H1 ----- GW1 ===== GW2 ----- RTR1 ----- H2 Host H1 > sends a UDP packet to H2 that is encapsulated in an IPsec > tunnel between gateways GW1 and GW2. My question is this: If > RTR1 originates an ICMP error for this packet that traverses > the same path in reverse, should GW2 encapsulate the ICMP > packet in the original UDP SA (in the absence of other rules > for carrying the ICMP packet), and should GW1 allow the > encapsulated ICMP packet to arrive over that UDP SA? > > 4301 allows GW1 and GW2 to handle this situation in either of > two ways. An SPD can say that the SA for the H1/H2 traffic > ALSO can carry ICMP messages, or the SPD can call for > creating a separate SA between the two GWs to carry only ICMP > messages. So, the answer to your question depends on the > contents of the SPDs at GW1 and GW2. > > In the case of GW1 allowing the ICMP packet to exit the > tunnel and be forwarded, the RFC hints strongly that this > should be the case. The last sentence of section 6.2 speaks > of cases where the ICMP must not be forwarded, > > The intent of the last sentence in 6.2 is to emphasize that > if an ICMP packet is received on an inbound SA and cannot be > verified via the procedure outlined in 6.2, then it MUST be > discarded, not forwarded. Section 6.2 does not express a > strong preference for either of the approaches to carriage of > ICMP traffic defined in this section. Compliant > implementations MUST support both approaches, e.g., the text > says "To accommodate both policies, ..." . > > strongly implying that GW1 is normally expected to forward > in this case. But it is less clear that GW2 should > encapsulate ICMP errors in non-ICMP SAs for errors that it > has not originated. Section 6.2 speaks only of performing > this encapsulation for "outbound" ICMP errors, and of ICMP > errors "sent and received via SAs." What if GW2 is doing > forwarding but not sending? > > The ICMP errors are outbound whether they are generated by > the security gateway or by a host or router behind the SG. So > whether the GW is generating the ICMP error message itself, > or forwarding it, the treatment is the same at this stage of > processing. > > I'm inclined to think that GW2 should encapsulate any ICMP > error according to these rules, even routed ICMP errors which > it did not itself originate. > > That's controlled by the SPD. > > This is parallel with the fact that GW1 seems to be expected > to behave in the reverse manner, and also aligns with the use > of "outbound" at other points in the RFC to be inclusive of > forwarded traffic. The one concern I can see is that ICMP > errors that GW2 did not originate are considered less > trustworthy and we may not wish to apply this processing to > them. However, it is possible to prevent this by creating > additional SPD entries at GW2 to prevent untrustworthy ICMP > errors from entering the gateway in the first place. > > yes, the GW could elect to not forward ICMP traffic from > routers behind it, for security reasons. > > Am I correct in assuming that section 6.2 of RFC 4301 is > intended to address both local and forwarded ICMP traffic? > Or is the treatment of forwarded traffic left to the > discretion of each implementation? > > As I noted above, the intent of 6.2 is to accommodate both > locally generated and forwarded ICMP traffic. > > Steve > > _______________________________________________ > Ipsec mailing list > Ipsec at ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > > * References: > o Re: [Ipsec] RFC 4301 and ICMP processing > + From: Stephen Kent > > * Prev by Date: Re: [Ipsec] RFC 4301 and ICMP processing > * Next by Date: Re: Re: [Ipsec] RFC 4301 and ICMP processing > * Previous by thread: Re: [Ipsec] RFC 4301 and ICMP processing > * Next by thread: Re: Re: [Ipsec] RFC 4301 and ICMP processing > * Index(es): > o Date > o Thread > > Note: Messages sent to this list are the opinions of the > senders and do not imply endorsement by the IETF. > _______________________________________________ > 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 Nov 24 11:44:02 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 01A893A67DA; Mon, 24 Nov 2008 11:44:02 -0800 (PST) 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 126853A67DA for ; Mon, 24 Nov 2008 11:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 N0Pfp8Y70yD6 for ; Mon, 24 Nov 2008 11:44:00 -0800 (PST) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 6115F3A6452 for ; Mon, 24 Nov 2008 11:44:00 -0800 (PST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAOJhwv0011164 for ; Mon, 24 Nov 2008 19:43:58 GMT Received: from kebe.East.Sun.COM (kebe.East.Sun.COM [129.148.174.48]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id mAOJhvGR061711 for ; Mon, 24 Nov 2008 14:43:57 -0500 (EST) Received: from kebe.East.Sun.COM (localhost [127.0.0.1]) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mAOJSbWR002546; Mon, 24 Nov 2008 14:28:37 -0500 (EST) Received: (from danmcd@localhost) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mAOJSbmd002545; Mon, 24 Nov 2008 14:28:37 -0500 (EST) X-Authentication-Warning: kebe.East.Sun.COM: danmcd set sender to danmcd@sun.com using -f Date: Mon, 24 Nov 2008 14:28:37 -0500 From: Dan McDonald To: "He, Wenxiao" Message-ID: <20081124192837.GH2019@kebe.East.Sun.COM> References: <4c5c7a6d0811172219j96ce787qd265ded48f4c60b6@mail.gmail.com> <18723.8781.499111.51370@fireball.kivinen.iki.fi> <4c5c7a6d0811181416h4ec9f7bew9579dbcf56f424bf@mail.gmail.com> <18724.14284.263786.286763@fireball.kivinen.iki.fi> <769907F0D19EFA45BD6F04FC6E896D6D1EBF8468A7@GVW0538EXC.americas.hpqcorp.net> <769907F0D19EFA45BD6F04FC6E896D6D1EC07E8312@GVW0538EXC.americas.hpqcorp.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <769907F0D19EFA45BD6F04FC6E896D6D1EC07E8312@GVW0538EXC.americas.hpqcorp.net> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Cc: "ipsec@ietf.org" Subject: Re: [IPsec] [Ipsec] RFC 4301 and ICMP processing 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 Mon, Nov 24, 2008 at 07:10:24PM +0000, He, Wenxiao wrote: > > Now, consider a simple end-to-end case between host A and > > host B. The SPD between A and B only specifies a SA for UDP, > > and there is no SPD to cover ICMP traffic. When host A sends > > a UDP message to host B, a SA pair is negotiated. And the > > A->B UDP message triggers host B to send back an ICMP error message. So far, so good. > > A) If I apply section 6.2 "Processing Protected, Transit ICMP > > Error Messages" to the B->A ICMP error message, the icmp > > error message will be carried by the extant SA pair generated > > by UDP message. > > > > B) If I donot apply the process specified in section 6.2, > > then the ICMP ERROR message will be discarded because no SPD is found. > > > Which of the above two approaches is the expected behavior > > for an IPsec end host? Does section 6 apply to IPsec end host? I can't say what everyone else does, but in {,Open}Solaris we've always had ICMP errors reflect back with the same policy (and SA) used by the traffic. It makes sense from a not-leaking-information point-of-view. In fact, you've helped me find a bug with inbound ICMP processing -- if an SA is tied to a protocol or port, ICMP SPD checking needs to apply the *inner* packet selectors. Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Nov 25 21:53: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 CE1BC3A6B29; Tue, 25 Nov 2008 21:53:51 -0800 (PST) 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 4B1C43A6918 for ; Tue, 25 Nov 2008 21:53:50 -0800 (PST) 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=[AWL=0.001, 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 IBVMD6u1lxxt for ; Tue, 25 Nov 2008 21:53:49 -0800 (PST) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id 751AE3A6B29 for ; Tue, 25 Nov 2008 21:53:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,666,1220227200"; d="scan'208";a="34581518" Received: from ind-dkim-2.cisco.com ([64.104.140.59]) by ind-iport-1.cisco.com with ESMTP; 26 Nov 2008 05:53:43 +0000 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAQ5rhDs024382 for ; Wed, 26 Nov 2008 11:23:43 +0530 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAQ5rds6012510 for ; Wed, 26 Nov 2008 05:53:41 GMT Received: from XMB-BLR-419.apac.cisco.com ([64.104.140.154]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 11:23:31 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Nov 2008 11:23:30 +0530 Message-ID: In-Reply-To: <18726.54250.743713.259337@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Meaning of INTERNAL_IP4_SUBNET Thread-Index: AclL7hSwmHHMJdnURPG2mSCQBXCJWQDmyo1g References: <18724.29181.897230.111045@fireball.kivinen.iki.fi> <18726.54250.743713.259337@fireball.kivinen.iki.fi> From: "Raghunandan P (raghup)" To: X-OriginalArrivalTime: 26 Nov 2008 05:53:31.0485 (UTC) FILETIME=[4FD000D0:01C94F8B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=922; t=1227678823; x=1228542823; c=relaxed/simple; s=inddkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=raghup@cisco.com; z=From:=20=22Raghunandan=20P=20(raghup)=22=20 |Subject:=20Meaning=20of=20INTERNAL_IP4_SUBNET |Sender:=20; bh=paQXT0bv3P4O8+Kyn/mntWMWPdqtBz57jPBuTz8ZGsw=; b=GFRhQuCv63gs4vh66KpWNtqU9eVOkatBb4XKtDAHyxzDAvSEaeUCSURdx9 NL6zT6GVl2eS4snISohDteY0w40OrwsvbJeyJiueCYc3ktwf+zCKX+Wb9Mkf g5havG/+6m; Authentication-Results: ind-dkim-2; header.From=raghup@cisco.com; dkim=pass ( sig from cisco.com/inddkim2002 verified; ); Subject: [IPsec] Meaning of INTERNAL_IP4_SUBNET 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 was going through the IKEv2 draft and needed a clarification on the following: The section 3.15.2 clearly explains the use of INTERNAL_IP4_SUBNET in the CFG_REPLY and how the peer can convey the subnet behind it which would be carried in both the CFG_REPLY payload and Tsr payload. However, I wanted more clarification on the below line: Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET is in CFG_REQUESTs is unclear, they cannot be used reliably in CFG_REQUESTs. If the client itself wants to announce subnets behind it as part of CFG_REQUEST, cant this be taken care by the peer so that it can send the Tsi back to the client accordingly having the information contained in the CFG_REQUEST payload? (just like the peer sends same information in TSr and CFG_REPLY payloads). Any plan to add more clarity on this and how this scenario needs to be handled? Thanks Raghu _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Nov 26 02:21: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 787ED3A684E; Wed, 26 Nov 2008 02:21:05 -0800 (PST) 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 5BA2D3A68D1 for ; Wed, 26 Nov 2008 02:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.312 X-Spam-Level: X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[AWL=0.288, 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 KENqHqnVlR8k for ; Wed, 26 Nov 2008 02:21:03 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 4B1E33A684E for ; Wed, 26 Nov 2008 02:21:02 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mAQAKhvF015909; Wed, 26 Nov 2008 12:20:55 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Nov 2008 12:20:43 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Nov 2008 12:20:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Nov 2008 12:20:42 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB720261AF33@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Meaning of INTERNAL_IP4_SUBNET Thread-Index: AclL7hSwmHHMJdnURPG2mSCQBXCJWQDmyo1gAAmskaA= References: <18724.29181.897230.111045@fireball.kivinen.iki.fi><18726.54250.743713.259337@fireball.kivinen.iki.fi> From: To: , X-OriginalArrivalTime: 26 Nov 2008 10:20:43.0250 (UTC) FILETIME=[A37D3520:01C94FB0] X-Nokia-AV: Clean Subject: Re: [IPsec] Meaning of INTERNAL_IP4_SUBNET 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 Raghu, INTERNAL_IP4/6_SUBNET, like the other configuration payloads currently defined, is meant for client-to-VPN-gateway use (e.g. remote access from laptop to corporate intranet), not gateway-to-gateway use. (If the client itself has subnets behind it, it would be a gateway.) Best regards, Pasi > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of ext Raghunandan P (raghup) > Sent: 26 November, 2008 07:54 > To: ipsec@ietf.org > Subject: [IPsec] Meaning of INTERNAL_IP4_SUBNET > > Hi, > I was going through the IKEv2 draft and needed a clarification on the > following: > > The section 3.15.2 clearly explains the use of INTERNAL_IP4_SUBNET in > the CFG_REPLY and how the peer can convey the subnet behind it which > would be carried in both the CFG_REPLY payload and Tsr > payload. However, > I wanted more clarification on the below line: > > Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET is in > CFG_REQUESTs is unclear, they cannot be used reliably in > CFG_REQUESTs. > > If the client itself wants to announce subnets behind it as part of > CFG_REQUEST, cant this be taken care by the peer so that it > can send the > Tsi back to the client accordingly having the information > contained in > the CFG_REQUEST payload? (just like the peer sends same information in > TSr and CFG_REPLY payloads). Any plan to add more clarity on this and > how this scenario needs to be handled? > > Thanks > Raghu > _______________________________________________ > 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 kdavis2@aamu.edu Wed Nov 26 14:34:14 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 2185828C260 for ; Wed, 26 Nov 2008 14:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -33.639 X-Spam-Level: X-Spam-Status: No, score=-33.639 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_DSL=1.129, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, 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 o9I2YKaSzB6a for ; Wed, 26 Nov 2008 14:34:12 -0800 (PST) Received: from athedsl-18833.home.otenet.gr (athedsl-220796.home.otenet.gr [85.74.182.26]) by core3.amsl.com (Postfix) with SMTP id 5C2D63A6813 for ; Wed, 26 Nov 2008 14:34:10 -0800 (PST) To: Subject: U.S. city crime rate From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081126223411.5C2D63A6813@core3.amsl.com> Date: Wed, 26 Nov 2008 14:34:10 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From ipsec-bounces@ietf.org Wed Nov 26 23:19: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 D783B28C151; Wed, 26 Nov 2008 23:19:48 -0800 (PST) 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 5F4013A6CC3 for ; Wed, 26 Nov 2008 23:18:29 -0800 (PST) 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_21=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 Zn5rWZ+8q4dL for ; Wed, 26 Nov 2008 23:18:28 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id B79E93A6B77 for ; Wed, 26 Nov 2008 23:18:27 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so553074fga.41 for ; Wed, 26 Nov 2008 23:18:23 -0800 (PST) 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=CURC6haRprQ7+y+h9+HbBOWN1HwDltkwCcbxOx2Vb4U=; b=KKUcqdIInncf41av69jlNv4n/EZjimAFAtOE5kuEhw8BC7AyH0PFmkyYo/Ulq3bAqt CkhtqY5FKuB0x+kSJTOuJTmedac1wXg9IL3DyEuRsEOFga4eOXU8v41g6BJpB34VxAQA BDy2x3SH7ezIt8y/PQktYSKMrN4bdC8Wp777o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=n8hENi67364HTaEbly606Qg3Cq7lMid7Nj/6GpmGWyhkVAcRvMrvogMVrTl9bDN2cP /BLXMrygUxyhHqvbb/Zzrwa3YhpdNv6zgaH5VmZoM9rxSLWNeFzvmyq4B39k2SWJTwvy RpWe5BP2f11BB4rSkAyMmmlG1ZxtSBlOnniHM= Received: by 10.86.91.12 with SMTP id o12mr4350415fgb.52.1227770303730; Wed, 26 Nov 2008 23:18:23 -0800 (PST) Received: by 10.86.57.20 with HTTP; Wed, 26 Nov 2008 23:18:23 -0800 (PST) Message-ID: <99043b4a0811262318x3a3a3564q98d12c3a2c1eb11d@mail.gmail.com> Date: Thu, 27 Nov 2008 08:18:23 +0100 From: "Matthew Cini Sarreo" To: ipsec@ietf.org MIME-Version: 1.0 Subject: [IPsec] IKEv2: Authentication Data 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="===============0723863191==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0723863191== Content-Type: multipart/alternative; boundary="----=_Part_18445_17242342.1227770303705" ------=_Part_18445_17242342.1227770303705 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, First of all, excuse my inexperience, IKEv2 is my first project of this kind. RFC 4306, section 2.15 describes how the Authentication Data field in the Authentication Payload is constructed (or, in other words, how the data in the Authentication Data field is created). There are two scenarios in the section: " When not using extensible authentication (see section 2.16), the peers are authenticated by having each sign (or MAC using a shared secret as the key) a block of data". The first scenario is using prf(SK_p(i or r), ID(i or r)') and the second one being AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), ). Does this mean that when using certificate based authentication, the first scenario is carried out, but when not (i.e just using a pre-shared key, which, maybe is entered by a user in some configuration data or is communicated by other means) the second scenario is used? Also, in this second scenario, it is not clear to me what is. Is it the concatenation of data as described at the beginning of section 2.15? Thanks & Regards, Matt ------=_Part_18445_17242342.1227770303705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

First of all, excuse my inexperience, IKEv2 is my first project of this kind.

RFC 4306, section 2.15 describes how the Authentication Data field in the Authentication Payload is constructed (or, in other words, how the data in the Authentication Data field is created).

There are two scenarios in the section: " When not using extensible authentication (see section 2.16), the peers are authenticated by having each sign (or MAC using a shared secret as the key) a block of data". The first scenario is using prf(SK_p(i or r), ID(i or r)') and the second one being AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg octets>). Does this mean that when using certificate based authentication, the first scenario is carried out, but when not (i.e just using a pre-shared key, which, maybe is entered by a user in some configuration data or is communicated by other means) the second scenario is used? Also, in this second scenario, it is not clear to me what <msg octets> is. Is it the concatenation of data as described at the beginning of section 2.15?

Thanks & Regards,
Matt
------=_Part_18445_17242342.1227770303705-- --===============0723863191== 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 --===============0723863191==-- From ipsec-bounces@ietf.org Thu Nov 27 00:48: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 D3EB03A6A04; Thu, 27 Nov 2008 00:48:27 -0800 (PST) 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 75EAD3A6A04 for ; Thu, 27 Nov 2008 00:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, J_CHICKENPOX_21=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 tov+7OatuO8y for ; Thu, 27 Nov 2008 00:48:25 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 46F093A6405 for ; Thu, 27 Nov 2008 00:48:25 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9B88029C004; Thu, 27 Nov 2008 10:48:21 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id E87F529C003; Thu, 27 Nov 2008 10:48:19 +0200 (IST) X-CheckPoint: {492E5E4D-10000-88241DC2-7B6} Received: from [91.90.139.118] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mAR8mJfE000837; Thu, 27 Nov 2008 10:48:19 +0200 (IST) Message-Id: <6AC34A81-77C6-4FB5-AFA2-0390E11D851F@checkpoint.com> From: Yoav Nir To: Matthew Cini Sarreo In-Reply-To: <99043b4a0811262318x3a3a3564q98d12c3a2c1eb11d@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 27 Nov 2008 10:48:19 +0200 References: <99043b4a0811262318x3a3a3564q98d12c3a2c1eb11d@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org Subject: Re: [IPsec] IKEv2: Authentication Data 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: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Matthew. You may want to read the revised document we are writing ( http://tools.iet= f.org/html/draft-ietf-ipsecme-ikev2bis = ). Section 2.15 there has a some clarifications on these issues. We = would appreciate your input about how this can be made even better, = because this is a work-in-progress. Regardless, here are some answers to your questions. The message octets are the same regardless of signing method. They are = described in the first paragraph of 2.15 ("For the responder...") That = part is definitely better in the new document. As for the signing method, there are really three cases: =95 Using shared keys: then it's AUTH =3D prf(prf(Shared Secret,"Key Pad = for IKEv2"), ) =95 Using certificates: then it's a regular public key signature. =95 Using extensible authentication (EAP): then in message #4, the = gateway signs with the private key, and in the last pair of messages, = both parties sign using the EAP MSK value similar to the way shared = keys are used (this is specified in 2.16) Hope this helps Yoav On Nov 27, 2008, at 9:18 AM, Matthew Cini Sarreo wrote: > Hi, > > First of all, excuse my inexperience, IKEv2 is my first project of = > this kind. > > RFC 4306, section 2.15 describes how the Authentication Data field = > in the Authentication Payload is constructed (or, in other words, = > how the data in the Authentication Data field is created). > > There are two scenarios in the section: " When not using extensible = > authentication (see section 2.16), the peers are authenticated by = > having each sign (or MAC using a shared secret as the key) a block = > of data". The first scenario is using prf(SK_p(i or r), ID(i or r)') = > and the second one being AUTH =3D prf(prf(Shared Secret,"Key Pad for = > IKEv2"), ). Does this mean that when using certificate = > based authentication, the first scenario is carried out, but when = > not (i.e just using a pre-shared key, which, maybe is entered by a = > user in some configuration data or is communicated by other means) = > the second scenario is used? Also, in this second scenario, it is = > not clear to me what is. Is it the concatenation of = > data as described at the beginning of section 2.15? > > Thanks & Regards, > Matt > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 28 02:27: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 89E5F3A6AA5; Fri, 28 Nov 2008 02:27:14 -0800 (PST) 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 E2B4C3A6AA5 for ; Fri, 28 Nov 2008 02:27:12 -0800 (PST) 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 jfa3+BtetgWP for ; Fri, 28 Nov 2008 02:27:12 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id E3CC83A6A9C for ; Fri, 28 Nov 2008 02:27:11 -0800 (PST) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id mASAR7Qh018965 for ; Fri, 28 Nov 2008 04:27:07 -0600 (CST) Received: from inexp01.in.lucent.com ([135.254.223.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Nov 2008 04:27:07 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.25]) by inexp01.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Nov 2008 15:57:02 +0530 MIME-Version: 1.0 Date: Fri, 28 Nov 2008 15:56:48 +0530 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <6D26D1FE43A66F439F8109CDD424196502356B45@INEXC1U01.in.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Deep Inspecting ESP-NULL Packets Thread-Index: AclRQ9IySiJTCFf7TT6Hi0CVzwKouA== From: "Bhatia, Manav \(Manav\)" To: X-OriginalArrivalTime: 28 Nov 2008 10:27:02.0754 (UTC) FILETIME=[DA846C20:01C95143] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: [IPsec] Deep Inspecting ESP-NULL Packets 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 was working on prioritizing some control traffic that's protected using ESP and it was in this context that I was pointed towards the WG doc - "Wrapped ESP for Traffic Visibility". The problem that I am trying to solve is the same as being addressed in this draft - providing explicit means to signal that ESP-NULL is being used to protect the packet. Besides firewalls, this also becomes very important on routers since a lot of applications and protocols use ESP-NULL for data integrity protection and source authentication purposes. I wouldn't expend cycles extolling the virtues of being able to disambiguate ESP encrypted and ESP-NULL packets as everyone in this WG is very well aware of this. I went through the WG document and I think its good and it solves the problem. However, I am a tad uncomfortable with introducing a new ESP protocol type. This imo is a major change and would require all the intermediary boxes to upgrade so that they can support this. There are currently firewalls configured that drop all traffic that they don't recognize. Wouldn't such firewalls drop all traffic using W-ESP? I was thinking of an alternative solution which uses one of the reserved values of SPI to indicate that it's a ESP-NULL packet. IANA could, for instance, allocate a value of 1 to indicate this. Now, we continue using the existing protocol type (i.e. 50 for ESP) and add 4 octets of RSPI before the original ESP packet. Existing implementations only need to add the RSPI of 1 before the ESP payload, without needing to change the body of the packet. Since we're using the existing ESP protocol number, the intermediary devices can still forward the packet and there is little change required. Implementation of this extension is *extremely* *extremely* easy as one only needs to add a RSPI of 1 (or whatever is assigned by IANA) for all ESP-NULL packets. An extended ESP packet using NULL encryption would thus look like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved Security Parameters Index (RSPI) = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Data* (variable) | ~ ~ | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding (0-255 bytes) | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Pad Length | Next Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Data (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Intermediaries (routers, firewalls, IDS, etc) interested in inspecting the packets en route can look at the SPI value at the start of the ESP header. If its 1 and if they are aware of this extension, then they understand that what follows is a normal ESP-NULL packet, which can be inspected. Intermediaries that don't understand this extension of ESP would treat this like a normal ESP packet This extension aware end nodes (routers) can similarly inspect the packet. If the SPI value is 1, they can deep inspect the packet and assign it to the right CPU queue/remark/apply ACLs/filters, based on the kind of payload the packet carries. Would like to hear from the folks on what they think about this proposal? Cheers, Manav -- Manav Bhatia, IP Division, Alcatel-Lucent, Bangalore - India _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 28 06:49: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 E74E13A6BB9; Fri, 28 Nov 2008 06:49:22 -0800 (PST) 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 E6C063A6BB9 for ; Fri, 28 Nov 2008 06:49:21 -0800 (PST) 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 u0cPqMLfTsyd for ; Fri, 28 Nov 2008 06:49:20 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by core3.amsl.com (Postfix) with ESMTP id 605E73A6B74 for ; Fri, 28 Nov 2008 06:49:20 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id 18so1391297fkq.5 for ; Fri, 28 Nov 2008 06:49:16 -0800 (PST) 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:content-transfer-encoding :content-disposition; bh=YKZFHZbM7gfM1u4LZQEC86A5xeHZ3fP775Ki0ANDVyQ=; b=rEimNLURI4T5iVpfEH3mO5QRV7zJs+XcD1QLLDwkz2eDiC+pb4f99c69GMXIFfzwxo i+PvTs8ht/YUI5Bh26DCMTiLHX4+XOXFI33VaD/b8e5F2Jd05ap5cYyyvZ1rZm2K0R3f TtdbC+ZlUW/EE7Vh7QBfdRxghLdZIEg0HDKpc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=DRYAG9jyxDHWdPLQUEf7GHzdSmOyqXAl7meVmTbuO/OJLgSPpKvXqZ+Ut6dLTBiNY+ 6glhOB+0y5Xr1sDxrKgN8QFpRQv5hBt0NIPLG2a0Ixp4/XAsPSG7JQpbXfWk2iSwz2uz wwRQsbyfmnxeK1WTZyoAgVtvP/bz4yApwlNR8= Received: by 10.187.240.1 with SMTP id s1mr1879191far.40.1227883755877; Fri, 28 Nov 2008 06:49:15 -0800 (PST) Received: by 10.187.241.19 with HTTP; Fri, 28 Nov 2008 06:49:15 -0800 (PST) Message-ID: Date: Fri, 28 Nov 2008 20:19:15 +0530 From: "Jack Kohn" To: manav@alcatel-lucent.com, ipsec@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets 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 I love the idea however i see one teeny weeny problem. If you want your ASICs to do your processing then you would do good if you have the next-header field in a fixed position. In your way of things, this is not possible, which is btw doable in the current proposal (WESP) on the table. However, like you and many others here, i detest the idea of introducing a new ESP protocol number. You could do a couple of things - (a) add another octet after the RSPI that gives the next-header or (2) work on some common ground and see if the two ideas can be merged. Jack > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Bhatia, Manav (Manav) > Sent: Friday, November 28, 2008 3.57 PM > To: ipsec@ietf.org > Subject: [IPsec] Deep Inspecting ESP-NULL Packets > > > Hi, > > I was working on prioritizing some control traffic that's protected > using ESP and it was in this context that I was pointed towards the WG > doc - "Wrapped ESP for Traffic Visibility". The problem that > I am trying > to solve is the same as being addressed in this draft - providing > explicit means to signal that ESP-NULL is being used to protect the > packet. Besides firewalls, this also becomes very important on routers > since a lot of applications and protocols use ESP-NULL for data > integrity protection and source authentication purposes. > > I wouldn't expend cycles extolling the virtues of being able to > disambiguate ESP encrypted and ESP-NULL packets as everyone in this WG > is very well aware of this. > > I went through the WG document and I think its good and it solves the > problem. However, I am a tad uncomfortable with introducing a new ESP > protocol type. This imo is a major change and would require all the > intermediary boxes to upgrade so that they can support this. There are > currently firewalls configured that drop all traffic that they don't > recognize. Wouldn't such firewalls drop all traffic using W-ESP? > > I was thinking of an alternative solution which uses one of > the reserved > values of SPI to indicate that it's a ESP-NULL packet. IANA could, for > instance, allocate a value of 1 to indicate this. Now, we > continue using > the existing protocol type (i.e. 50 for ESP) and add 4 octets of RSPI > before the original ESP packet. Existing implementations only need to > add the RSPI of 1 before the ESP payload, without needing to > change the > body of the packet. > > Since we're using the existing ESP protocol number, the intermediary > devices can still forward the packet and there is little change > required. Implementation of this extension is *extremely* *extremely* > easy as one only needs to add a RSPI of 1 (or whatever is assigned by > IANA) for all ESP-NULL packets. > > An extended ESP packet using NULL encryption would thus look > like this: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved Security Parameters Index (RSPI) = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Original Security Parameters Index (SPI) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload Data* (variable) | > ~ ~ > | | > + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | Padding (0-255 bytes) | > +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | Pad Length | Next Header | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Authentication Data (variable) | > ~ ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Intermediaries (routers, firewalls, IDS, etc) interested in inspecting > the packets en route can look at the SPI value at the start of the ESP > header. If its 1 and if they are aware of this extension, then they > understand that what follows is a normal ESP-NULL packet, which can be > inspected. Intermediaries that don't understand this extension of ESP > would treat this like a normal ESP packet > > This extension aware end nodes (routers) can similarly inspect the > packet. If the SPI value is 1, they can deep inspect the packet and > assign it to the right CPU queue/remark/apply ACLs/filters, > based on the > kind of payload the packet carries. > > Would like to hear from the folks on what they think about this > proposal? > > Cheers, Manav > > -- > Manav Bhatia, > IP Division, Alcatel-Lucent, > Bangalore - India > > > _______________________________________________ > 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 Fri Nov 28 08:06: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 B5D2C3A6961; Fri, 28 Nov 2008 08:06:53 -0800 (PST) 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 EBA443A68ED for ; Fri, 28 Nov 2008 08:06:52 -0800 (PST) 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 UtcR47RXTF85 for ; Fri, 28 Nov 2008 08:06:51 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C6D1E3A6856 for ; Fri, 28 Nov 2008 08:06:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,683,1220227200"; d="scan'208";a="203244851" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 28 Nov 2008 16:06:49 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id mASG6n67013345; Fri, 28 Nov 2008 08:06:49 -0800 Received: from sfluhrerwxp (stealth-10-32-244-84.cisco.com [10.32.244.84]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mASG6muC014715; Fri, 28 Nov 2008 16:06:48 GMT From: "Scott Fluhrer" To: "'Bhatia, Manav \(Manav\)'" , References: <6D26D1FE43A66F439F8109CDD424196502356B45@INEXC1U01.in.lucent.com> Date: Fri, 28 Nov 2008 11:06:47 -0500 Message-ID: <01f901c95173$5199e9a0$54f4200a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <6D26D1FE43A66F439F8109CDD424196502356B45@INEXC1U01.in.lucent.com> Thread-Index: AclRQ9IySiJTCFf7TT6Hi0CVzwKouAAJjyYg DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5473; t=1227888409; x=1228752409; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sfluhrer@cisco.com; z=From:=20=22Scott=20Fluhrer=22=20 |Subject:=20RE=3A=20[IPsec]=20Deep=20Inspecting=20ESP-NULL= 20Packets |Sender:=20; bh=cUpC/UuR4Ci23v+q4a//HpZzAVzmxL9wAZUo9iucN8w=; b=vHY3IZtcazHiLcHw85Ik6DMEyN9yV5sQMXM9F3QIoa4Uapr7oVkKzdOB+k nREcCM+2LdNoWkNJN+5Vd15y15EH+wC2ufLa8qXuZ8iDGHqzBYiXGcncG1cw vI5RYNPzS6; Authentication-Results: sj-dkim-3; header.From=sfluhrer@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets 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 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Bhatia, Manav (Manav) > Sent: Friday, November 28, 2008 5:27 AM > To: ipsec@ietf.org > Subject: [IPsec] Deep Inspecting ESP-NULL Packets > > > Hi, > > I was working on prioritizing some control traffic that's > protected using ESP and it was in this context that I was > pointed towards the WG doc - "Wrapped ESP for Traffic > Visibility". The problem that I am trying to solve is the > same as being addressed in this draft - providing explicit > means to signal that ESP-NULL is being used to protect the > packet. Besides firewalls, this also becomes very important > on routers since a lot of applications and protocols use > ESP-NULL for data integrity protection and source > authentication purposes. > > I wouldn't expend cycles extolling the virtues of being able > to disambiguate ESP encrypted and ESP-NULL packets as > everyone in this WG is very well aware of this. > > I went through the WG document and I think its good and it > solves the problem. However, I am a tad uncomfortable with > introducing a new ESP protocol type. This imo is a major > change and would require all the intermediary boxes to > upgrade so that they can support this. There are currently > firewalls configured that drop all traffic that they don't > recognize. Wouldn't such firewalls drop all traffic using W-ESP? > > I was thinking of an alternative solution which uses one of > the reserved values of SPI to indicate that it's a ESP-NULL > packet. IANA could, for instance, allocate a value of 1 to > indicate this. Now, we continue using the existing protocol > type (i.e. 50 for ESP) and add 4 octets of RSPI before the > original ESP packet. Existing implementations only need to > add the RSPI of 1 before the ESP payload, without needing to > change the body of the packet. Obvious problems with the packet format you have suggested: - How does an intermediate device know how long the authentication data is (and thus find the 'next header' field)? - To an intermediate device that isn't aware of this extension, it would look like an ESP packet except that the ESP sequence number doesn't increment; instead, it stays at one particular fixed value (until a rekey, when it abruptly switches to another fixed value). One possible concern is that firewalls that try to filter what they can for ESP traffic flows will reject this. Neither is that difficult to fix... > > Since we're using the existing ESP protocol number, the > intermediary devices can still forward the packet and there > is little change required. Implementation of this extension > is *extremely* *extremely* easy as one only needs to add a > RSPI of 1 (or whatever is assigned by > IANA) for all ESP-NULL packets. > > An extended ESP packet using NULL encryption would thus look > like this: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved Security Parameters Index (RSPI) = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Original Security Parameters Index (SPI) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload Data* (variable) | > ~ ~ > | | > + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | Padding (0-255 bytes) | > +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | Pad Length | Next Header | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Authentication Data (variable) | > ~ ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Intermediaries (routers, firewalls, IDS, etc) interested in > inspecting the packets en route can look at the SPI value at > the start of the ESP header. If its 1 and if they are aware > of this extension, then they understand that what follows is > a normal ESP-NULL packet, which can be inspected. > Intermediaries that don't understand this extension of ESP > would treat this like a normal ESP packet > > This extension aware end nodes (routers) can similarly > inspect the packet. If the SPI value is 1, they can deep > inspect the packet and assign it to the right CPU > queue/remark/apply ACLs/filters, based on the kind of payload > the packet carries. > > Would like to hear from the folks on what they think about > this proposal? > > Cheers, Manav > > -- > Manav Bhatia, > IP Division, Alcatel-Lucent, > Bangalore - India > > > _______________________________________________ > 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 Fri Nov 28 08:41: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 CDD8B28C0E5; Fri, 28 Nov 2008 08:41:31 -0800 (PST) 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 2C2AB28C10B for ; Fri, 28 Nov 2008 08:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 rqK1EPq5ovyo for ; Fri, 28 Nov 2008 08:41:29 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id EFE0928C0E5 for ; Fri, 28 Nov 2008 08:41:28 -0800 (PST) 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 mASGfESA007891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Nov 2008 18:41:14 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mASGfDqc023100; Fri, 28 Nov 2008 18:41:13 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18736.7977.492687.346315@fireball.kivinen.iki.fi> Date: Fri, 28 Nov 2008 18:41:13 +0200 From: Tero Kivinen To: "Jack Kohn" In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 1 min Cc: ipsec@ietf.org, manav@alcatel-lucent.com Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets 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 Jack Kohn writes: > I love the idea however i see one teeny weeny problem. > > If you want your ASICs to do your processing then you would do good if > you have the next-header field in a fixed position. In your way of > things, this is not possible, which is btw doable in the current > proposal (WESP) on the table. However, like you and many others here, > i detest the idea of introducing a new ESP protocol number. You could > do a couple of things - (a) add another octet after the RSPI that > gives the next-header or (2) work on some common ground and see if the > two ideas can be merged. If you are doing deep inspection anyways then finding the next header by using heuristics isn't really a problem. On the other hand if you are doing heuristics (which do not require any changes to sending, or receiving ends, or any middle boxes who do not do deep inspection) then you do not even need the reserved SPI... -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 28 09:14: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 AD76C3A69EE; Fri, 28 Nov 2008 09:14:17 -0800 (PST) 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 9835E3A6998 for ; Fri, 28 Nov 2008 09:14:16 -0800 (PST) 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 1UxOvHOwBHBt for ; Fri, 28 Nov 2008 09:14:15 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id A32593A683D for ; Fri, 28 Nov 2008 09:14:15 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so612833yxg.49 for ; Fri, 28 Nov 2008 09:14:12 -0800 (PST) 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=wcQbvwkHKvgdPTbHi0x1pZlrvNkw/AS6qXiQZn/i+sk=; b=prkp1uvBAMF6NTrdxhjmSv/4Admcw6GHkHbkA2fHgYOmjsmqAj4K2iehA5tsogr2p1 e5+slctE9QmSxO3pLfMX7oB9vZL2F7drzRU70oqq2HR++X+/8GPnewUQxWMHB/YC7g8o sX0CjjGpfLLWk3u2B+JMb/0hUs7MYT/E+cJbQ= 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=E8yycqLHc53I/3hcEsSAoOwfuKVugjcv/i5en8ThIzO9YiJTgMnTQaaCJH/BAJVeJw U4pSl/uEV82MapTJJ0U5OYAYl/xICGRUSc3XlTpaAxC9V9KjaYkKo9i+xv4WD97TC7T+ hw9UNgchWAtEOox0hBO/nP/F97xkdZLh3OzjQ= Received: by 10.142.162.9 with SMTP id k9mr3406221wfe.282.1227892451602; Fri, 28 Nov 2008 09:14:11 -0800 (PST) Received: by 10.142.156.16 with HTTP; Fri, 28 Nov 2008 09:14:11 -0800 (PST) Message-ID: Date: Fri, 28 Nov 2008 22:44:11 +0530 From: "Jack Kohn" To: "Tero Kivinen" In-Reply-To: <18736.7977.492687.346315@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline References: <18736.7977.492687.346315@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org, manav@alcatel-lucent.com Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets 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 Tero, Heuristics is probability and is at best just an educated guess. I think the stakes are high as you would be dropping/forwarding packets based on the probability that your model returns you. Also, do you propose to do this in HW or SW? Is there a model that you have in mind? Do you have a study that you can share with us that gives some numbers on how well this model works? Jack. On Fri, Nov 28, 2008 at 10:11 PM, Tero Kivinen wrote: > Jack Kohn writes: >> I love the idea however i see one teeny weeny problem. >> >> If you want your ASICs to do your processing then you would do good if >> you have the next-header field in a fixed position. In your way of >> things, this is not possible, which is btw doable in the current >> proposal (WESP) on the table. However, like you and many others here, >> i detest the idea of introducing a new ESP protocol number. You could >> do a couple of things - (a) add another octet after the RSPI that >> gives the next-header or (2) work on some common ground and see if the >> two ideas can be merged. > > If you are doing deep inspection anyways then finding the next header > by using heuristics isn't really a problem. On the other hand if you > are doing heuristics (which do not require any changes to sending, or > receiving ends, or any middle boxes who do not do deep inspection) > then you do not even need the reserved SPI... > -- > kivinen@iki.fi > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 28 09:45:04 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 824463A682E; Fri, 28 Nov 2008 09:45:04 -0800 (PST) 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 8A9AD3A682E for ; Fri, 28 Nov 2008 09:45:03 -0800 (PST) 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 0KBgnZxFi9GF for ; Fri, 28 Nov 2008 09:45:02 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id 685D13A676A for ; Fri, 28 Nov 2008 09:45:02 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so617574ywj.49 for ; Fri, 28 Nov 2008 09:44:59 -0800 (PST) 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=cW+Wxjv8W53Wn63qXHR4TPqyP7GEYJ6/KxMQth8NNR4=; b=Tkp03BVFLhbktpW/1mgRPPpQsgpQsRI71hjH9TS+8/g5oP7+Ii3gC4gzspgnX4I6Wp S4n9YnVDoeiyFrNcxw4dPK1IBWZ7J3CU1RulcE70MqaA+VEMCcNkP+MU6vOI1Pro06ys XpHuiPYUC04nlmR4Ps6jjvClfi0sQYtDbDA2w= 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=GeQQsrFfHHYJW2p3k5Jg80sDxN4Fw1y4qB/OiumrdEyHgyye3LfgnnXdct4mEl98CV pU+WK4UZ2OxzdDpzVfGndNi0CT/i5Rpz7J4pU9TEzpZfHjFywDzZyxqhDNmRON0NYCe2 lB3PmQfcKf4+PrBajcfF7J/3BGMU8sLClHXkc= Received: by 10.142.217.17 with SMTP id p17mr3435195wfg.23.1227894298694; Fri, 28 Nov 2008 09:44:58 -0800 (PST) Received: by 10.142.156.16 with HTTP; Fri, 28 Nov 2008 09:44:58 -0800 (PST) Message-ID: Date: Fri, 28 Nov 2008 23:14:58 +0530 From: "Jack Kohn" To: "Scott Fluhrer" In-Reply-To: <01f901c95173$5199e9a0$54f4200a@amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD424196502356B45@INEXC1U01.in.lucent.com> <01f901c95173$5199e9a0$54f4200a@amer.cisco.com> Cc: ipsec@ietf.org, "Bhatia, Manav \(Manav\)" Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets 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 > Obvious problems with the packet format you have suggested: > > - How does an intermediate device know how long the authentication data is > (and thus find the 'next header' field)? Yes, i mentioned this to Manav and its trivial to fix this. > > - To an intermediate device that isn't aware of this extension, it would > look like an ESP packet except that the ESP sequence number doesn't > increment; instead, it stays at one particular fixed value (until a rekey, > when it abruptly switches to another fixed value). One possible concern is > that firewalls that try to filter what they can for ESP traffic flows will > reject this. Wow. You're saying that firewalls maintain state for each IPSec flow and actually care about the sequence numbers? They'll have to maintain state per . Why would you do that? Are there firewalls that actually do that? > > Neither is that difficult to fix... Absolutely. I think whats important at this point is whether we want a new protocol or some method that extends ESP for our needs. I would rather that we go with the latter. Jack > >> >> Since we're using the existing ESP protocol number, the >> intermediary devices can still forward the packet and there >> is little change required. Implementation of this extension >> is *extremely* *extremely* easy as one only needs to add a >> RSPI of 1 (or whatever is assigned by >> IANA) for all ESP-NULL packets. >> >> An extended ESP packet using NULL encryption would thus look >> like this: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Reserved Security Parameters Index (RSPI) = 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Original Security Parameters Index (SPI) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sequence Number | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Payload Data* (variable) | >> ~ ~ >> | | >> + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | Padding (0-255 bytes) | >> +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | Pad Length | Next Header | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Authentication Data (variable) | >> ~ ~ >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Intermediaries (routers, firewalls, IDS, etc) interested in >> inspecting the packets en route can look at the SPI value at >> the start of the ESP header. If its 1 and if they are aware >> of this extension, then they understand that what follows is >> a normal ESP-NULL packet, which can be inspected. >> Intermediaries that don't understand this extension of ESP >> would treat this like a normal ESP packet >> >> This extension aware end nodes (routers) can similarly >> inspect the packet. If the SPI value is 1, they can deep >> inspect the packet and assign it to the right CPU >> queue/remark/apply ACLs/filters, based on the kind of payload >> the packet carries. >> >> Would like to hear from the folks on what they think about >> this proposal? >> >> Cheers, Manav >> >> -- >> Manav Bhatia, >> IP Division, Alcatel-Lucent, >> Bangalore - India >> >> >> _______________________________________________ >> 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 > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Nov 28 16:24:47 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 9C6183A687F; Fri, 28 Nov 2008 16:24:47 -0800 (PST) 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 517013A687F for ; Fri, 28 Nov 2008 16:24:46 -0800 (PST) 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 NVWlM8WTSFdF for ; Fri, 28 Nov 2008 16:24:45 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 3B9323A635F for ; Fri, 28 Nov 2008 16:24:44 -0800 (PST) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id mAT0Od93025743; Fri, 28 Nov 2008 18:24:39 -0600 (CST) Received: from inexp01.in.lucent.com ([135.254.223.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Nov 2008 18:24:39 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.25]) by inexp01.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Nov 2008 05:54:35 +0530 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 29 Nov 2008 05:54:34 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD424196502356BC4@INEXC1U01.in.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Deep Inspecting ESP-NULL Packets Thread-Index: AclRaJc2mqydNnIGShCJMKWtTkYZQAAT/3fw References: From: "Bhatia, Manav \(Manav\)" To: "Jack Kohn" X-OriginalArrivalTime: 29 Nov 2008 00:24:35.0663 (UTC) FILETIME=[DB95CDF0:01C951B8] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: ipsec@ietf.org Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets 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 Jack, Thanks for your comments. > I love the idea however i see one teeny weeny problem. Not a problem :-) > > If you want your ASICs to do your processing then you would do good if > you have the next-header field in a fixed position. In your way of > things, this is not possible, which is btw doable in the current > proposal (WESP) on the table. However, like you and many others here, > i detest the idea of introducing a new ESP protocol number. You could > do a couple of things - (a) add another octet after the RSPI that Yup, this can be done. Cheers, Manav > gives the next-header or (2) work on some common ground and see if the > two ideas can be merged. > > Jack > > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > > On Behalf Of Bhatia, Manav (Manav) > > Sent: Friday, November 28, 2008 3.57 PM > > To: ipsec@ietf.org > > Subject: [IPsec] Deep Inspecting ESP-NULL Packets > > > > > > Hi, > > > > I was working on prioritizing some control traffic that's protected > > using ESP and it was in this context that I was pointed > towards the WG > > doc - "Wrapped ESP for Traffic Visibility". The problem that > > I am trying > > to solve is the same as being addressed in this draft - providing > > explicit means to signal that ESP-NULL is being used to protect the > > packet. Besides firewalls, this also becomes very important > on routers > > since a lot of applications and protocols use ESP-NULL for data > > integrity protection and source authentication purposes. > > > > I wouldn't expend cycles extolling the virtues of being able to > > disambiguate ESP encrypted and ESP-NULL packets as everyone > in this WG > > is very well aware of this. > > > > I went through the WG document and I think its good and it > solves the > > problem. However, I am a tad uncomfortable with introducing > a new ESP > > protocol type. This imo is a major change and would require all the > > intermediary boxes to upgrade so that they can support > this. There are > > currently firewalls configured that drop all traffic that they don't > > recognize. Wouldn't such firewalls drop all traffic using W-ESP? > > > > I was thinking of an alternative solution which uses one of > > the reserved > > values of SPI to indicate that it's a ESP-NULL packet. IANA > could, for > > instance, allocate a value of 1 to indicate this. Now, we > > continue using > > the existing protocol type (i.e. 50 for ESP) and add 4 > octets of RSPI > > before the original ESP packet. Existing implementations > only need to > > add the RSPI of 1 before the ESP payload, without needing to > > change the > > body of the packet. > > > > Since we're using the existing ESP protocol number, the intermediary > > devices can still forward the packet and there is little change > > required. Implementation of this extension is *extremely* > *extremely* > > easy as one only needs to add a RSPI of 1 (or whatever is > assigned by > > IANA) for all ESP-NULL packets. > > > > An extended ESP packet using NULL encryption would thus look > > like this: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Reserved Security Parameters Index (RSPI) = 1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Original Security Parameters Index (SPI) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Sequence Number | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Payload Data* (variable) | > > ~ ~ > > | | > > + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | Padding (0-255 bytes) | > > +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | Pad Length | Next Header | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Authentication Data (variable) | > > ~ ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Intermediaries (routers, firewalls, IDS, etc) interested in > inspecting > > the packets en route can look at the SPI value at the start > of the ESP > > header. If its 1 and if they are aware of this extension, then they > > understand that what follows is a normal ESP-NULL packet, > which can be > > inspected. Intermediaries that don't understand this > extension of ESP > > would treat this like a normal ESP packet > > > > This extension aware end nodes (routers) can similarly inspect the > > packet. If the SPI value is 1, they can deep inspect the packet and > > assign it to the right CPU queue/remark/apply ACLs/filters, > > based on the > > kind of payload the packet carries. > > > > Would like to hear from the folks on what they think about this > > proposal? > > > > Cheers, Manav > > > > -- > > Manav Bhatia, > > IP Division, Alcatel-Lucent, > > Bangalore - India > > > > > > _______________________________________________ > > 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 Fri Nov 28 16:38: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 A04103A6A0F; Fri, 28 Nov 2008 16:38:31 -0800 (PST) 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 D5A073A6A0F for ; Fri, 28 Nov 2008 16:38:30 -0800 (PST) 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 cNM1eP2z7LFW for ; Fri, 28 Nov 2008 16:38:30 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id EF5203A63EB for ; Fri, 28 Nov 2008 16:38:29 -0800 (PST) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id mAT0cOWe028228; Fri, 28 Nov 2008 18:38:24 -0600 (CST) Received: from inexp01.in.lucent.com ([135.254.223.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Nov 2008 18:38:23 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.25]) by inexp01.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Nov 2008 06:08:19 +0530 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 29 Nov 2008 06:08:18 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD424196502356BC5@INEXC1U01.in.lucent.com> In-Reply-To: <01f901c95173$5199e9a0$54f4200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Deep Inspecting ESP-NULL Packets Thread-Index: AclRQ9IySiJTCFf7TT6Hi0CVzwKouAAJjyYgABOzbjA= References: <6D26D1FE43A66F439F8109CDD424196502356B45@INEXC1U01.in.lucent.com> <01f901c95173$5199e9a0$54f4200a@amer.cisco.com> From: "Bhatia, Manav \(Manav\)" To: "Scott Fluhrer" , X-OriginalArrivalTime: 29 Nov 2008 00:38:19.0251 (UTC) FILETIME=[C67B5C30:01C951BA] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets 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 Scott, > - To an intermediate device that isn't aware of this > extension, it would > look like an ESP packet except that the ESP sequence number doesn't > increment; instead, it stays at one particular fixed value > (until a rekey, > when it abruptly switches to another fixed value). One > possible concern is > that firewalls that try to filter what they can for ESP > traffic flows will > reject this. I am not sure how big a problem this is. However, if it needs to be fixed then this can be easily done. You could send the original SPI and the next-header as part of the payload, so the original ESP packet has the sequence number in the right place. The receiver upon seeing the RSPI value of 1 would understand that the first 4 octets give the actual SPI, while the intermediaries could look at the 5th octet to know what the next-header is. If you want the firewalls to be able to parse the L4 info then you could include the ESP header length too. This could be the 6th octet. Using this the intermediaries can determine the exact location from where the payload starts. An extended ESP packet using NULL encryption would thus look like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved Security Parameters Index (RSPI) = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | next-header | eESP HDRLen | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Payload Data* (variable) | ~ ~ | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding (0-255 bytes) | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Pad Length | Next Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Data (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Neither is that difficult to fix... Yes. Cheers, Manav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From jgeering@adam.com.au Sat Nov 29 08:49:36 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 D6C6F3A679F for ; Sat, 29 Nov 2008 08:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -27.744 X-Spam-Level: X-Spam-Status: No, score=-27.744 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, 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 PCrCu5+G-tEU for ; Sat, 29 Nov 2008 08:49:36 -0800 (PST) Received: from ab1cs.com (unknown [92.45.235.100]) by core3.amsl.com (Postfix) with SMTP id 0DFC63A6884 for ; Sat, 29 Nov 2008 08:49:30 -0800 (PST) To: Subject: RE: Message 20842 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081129164934.0DFC63A6884@core3.amsl.com> Date: Sat, 29 Nov 2008 08:49:30 -0800 (PST) Click here to view as a webpage.


Windows Live Customer Support | Hotmail Support FAQs | Newsletter feedback

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052 As a Windows Live member you have received this e-mail to inform you of updates, changes to the service, or special news and information vital to the service. Our policy is to send e-mail messages only to announce such information, and we'll continue to honor this policy. These communications are required as a part of this service. If you do not wish to receive these letters you may discontinue your participation in the service and close your account.

Microsoft respects your privacy. To learn more, please read our online Privacy Statement

Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
From ipsec-bounces@ietf.org Sat Nov 29 15:45:02 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 329403A699D; Sat, 29 Nov 2008 15:45:02 -0800 (PST) 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 DB2963A699D for ; Sat, 29 Nov 2008 15:45:00 -0800 (PST) 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 GeQevmAkbjzp for ; Sat, 29 Nov 2008 15:45:00 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 349D03A68C2 for ; Sat, 29 Nov 2008 15:45:00 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2058004wfd.31 for ; Sat, 29 Nov 2008 15:44:57 -0800 (PST) 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=8sSsQhwsVJDjeMCC61MjGgHolz/6z7pFS9Cdvlfx8VU=; b=M2onBJCLSfet8Nfn+0OunOdMQWHIF7Iop7gp6I5J9SfWLJXKtjtNhcwqVgHPigVMgY v00W1hUnbZMW0CeEpQyr044X0r12bdMRgH75hcCI42BFfO2+VaNnzssZc8byG3VnUk8/ wSNId78x0U073PbRIPO4yqYs4vq0gkAow4xRY= 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=xlgB6i6ZWiCXIIdW+d30Q1ImMdHgbNDxrhzdkIFccFdLo0aCuD9V8pE3x901yzO6uX KL7ANoXuhxJbCqnAY33FUYMWn5ojih5p9mefzvn6MRsmPW9CtwqFEKTHJGcCBjdw7H7w zkw5o7dJawVKstjPAv4KNPeB09Spd23yMDM2M= Received: by 10.142.165.14 with SMTP id n14mr3897946wfe.24.1228002296977; Sat, 29 Nov 2008 15:44:56 -0800 (PST) Received: by 10.142.171.20 with HTTP; Sat, 29 Nov 2008 15:44:56 -0800 (PST) Message-ID: Date: Sun, 30 Nov 2008 05:14:56 +0530 From: "Jack Kohn" To: "Bhatia, Manav (Manav)" In-Reply-To: <6D26D1FE43A66F439F8109CDD424196502356BC5@INEXC1U01.in.lucent.com> MIME-Version: 1.0 Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD424196502356B45@INEXC1U01.in.lucent.com> <01f901c95173$5199e9a0$54f4200a@amer.cisco.com> <6D26D1FE43A66F439F8109CDD424196502356BC5@INEXC1U01.in.lucent.com> Cc: ipsec@ietf.org, Scott Fluhrer Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets 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 > You could send the original SPI and the next-header as part of the > payload, so the original ESP packet has the sequence number in the right > place. The receiver upon seeing the RSPI value of 1 would understand > that the first 4 octets give the actual SPI, while the intermediaries Sounds Good. > could look at the 5th octet to know what the next-header is. If you want > the firewalls to be able to parse the L4 info then you could include the > ESP header length too. This could be the 6th octet. Using this the I am assuming that you're mentioning ESP header length explicitly to account for the IV (if required, by the authentication algorithm), as otherwise its a fixed value and can always be inferred, right? > intermediaries can determine the exact location from where the payload > starts. Jack _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Nov 30 07:57:40 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 D08C63A6B64; Sun, 30 Nov 2008 07:57:40 -0800 (PST) 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 B820E3A6B64 for ; Sun, 30 Nov 2008 07:57:39 -0800 (PST) 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 dAQHl0CIeANI for ; Sun, 30 Nov 2008 07:57:38 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id C08DE3A6971 for ; Sun, 30 Nov 2008 07:57:38 -0800 (PST) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id mAUFvU41026864; Sun, 30 Nov 2008 09:57:30 -0600 (CST) Received: from inexp01.in.lucent.com ([135.254.223.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Nov 2008 09:57:30 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.25]) by inexp01.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Nov 2008 21:27:27 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 30 Nov 2008 21:27:26 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD424196502356C2B@INEXC1U01.in.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Deep Inspecting ESP-NULL Packets Thread-Index: AclSfH8DZI6W+idaQPCpS9r2HxLIeQAh5+Pw References: <6D26D1FE43A66F439F8109CDD424196502356B45@INEXC1U01.in.lucent.com> <01f901c95173$5199e9a0$54f4200a@amer.cisco.com> <6D26D1FE43A66F439F8109CDD424196502356BC5@INEXC1U01.in.lucent.com> From: "Bhatia, Manav \(Manav\)" To: "Jack Kohn" X-OriginalArrivalTime: 30 Nov 2008 15:57:27.0029 (UTC) FILETIME=[57883A50:01C95304] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: ipsec@ietf.org, Scott Fluhrer Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets 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 Jack, > > could look at the 5th octet to know what the next-header > is. If you want > > the firewalls to be able to parse the L4 info then you > could include the > > ESP header length too. This could be the 6th octet. Using this the > > I am assuming that you're mentioning ESP header length explicitly to > account for the IV (if required, by the authentication algorithm), as > otherwise its a fixed value and can always be inferred, right? Yes, that's correct. Cheers, Manav > > > intermediaries can determine the exact location from where > the payload > > starts. > > Jack > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Nov 30 10:39: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 ACEAE3A69E4; Sun, 30 Nov 2008 10:39:49 -0800 (PST) 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 193D23A69E4 for ; Sun, 30 Nov 2008 10:39:48 -0800 (PST) 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 e9da908JSvUb for ; Sun, 30 Nov 2008 10:39:47 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by core3.amsl.com (Postfix) with ESMTP id D64D73A69A6 for ; Sun, 30 Nov 2008 10:39:46 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id 18so2157907fkq.5 for ; Sun, 30 Nov 2008 10:39:41 -0800 (PST) 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=+6z5npI5x/TUIUs2KkuvMZxUPrtwXEISsgXFO6FeC/o=; b=cKKZfBu+/6+2ILE7UpCOF8XLnAvE8lLg44ubZDsEHB37x/0b6VjplbutJjlFNTkdpI JPDaMbFSlZclyPeYhkIuavoWNN2t0a3+8/HSnKQrzHMil39FMHXj9sp7VV0qH6WLC+6w Y5v9pHgN3fC47ZJ2OiyCr1t8JThYw9xOeCIRM= 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=oBelj2UZ4nRkcd9tcZ6gyypoEXchQgmOuUIKOisKdZPAU4af+8KDRMqgAvD+QMcXpI UweaCIii+UY7+2qAGwkDJ8szqfEqVMR17Ms8iFUG7oJPdyTKRrRA9nLTLIX3/tYkqnxn FgtLR3xyZSUIHfEIcP3chumff5xwuuTVrI9DA= Received: by 10.181.20.13 with SMTP id x13mr743442bki.164.1228070381785; Sun, 30 Nov 2008 10:39:41 -0800 (PST) Received: by 10.180.205.7 with HTTP; Sun, 30 Nov 2008 10:39:41 -0800 (PST) Message-ID: <77ead0ec0811301039k1e279415tb4d5037b0c9e3a74@mail.gmail.com> Date: Sun, 30 Nov 2008 10:39:41 -0800 From: "Vishwas Manral" To: "Bhatia, Manav (Manav)" In-Reply-To: <6D26D1FE43A66F439F8109CDD424196502356C2B@INEXC1U01.in.lucent.com> MIME-Version: 1.0 Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD424196502356B45@INEXC1U01.in.lucent.com> <01f901c95173$5199e9a0$54f4200a@amer.cisco.com> <6D26D1FE43A66F439F8109CDD424196502356BC5@INEXC1U01.in.lucent.com> <6D26D1FE43A66F439F8109CDD424196502356C2B@INEXC1U01.in.lucent.com> Cc: ipsec@ietf.org, Scott Fluhrer , Jack Kohn Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets 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 Manav, Thanks for your effort i the draft. I noticed that the RFC4303 does not state how reserved values need to be handled. Am I missing something? The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. The SPI value of zero (0) is reserved for local, implementation-specific use and MUST NOT be sent on the wire. (For example, a key management implementation might use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established.) What would an IPsec router do in case it gets one of the reserved SPI values in the packet? Thanks again, Vishwas On Sun, Nov 30, 2008 at 7:57 AM, Bhatia, Manav (Manav) wrote: > Hi Jack, > >> > could look at the 5th octet to know what the next-header >> is. If you want >> > the firewalls to be able to parse the L4 info then you >> could include the >> > ESP header length too. This could be the 6th octet. Using this the >> >> I am assuming that you're mentioning ESP header length explicitly to >> account for the IV (if required, by the authentication algorithm), as >> otherwise its a fixed value and can always be inferred, right? > > Yes, that's correct. > > Cheers, Manav > >> >> > intermediaries can determine the exact location from where >> the payload >> > starts. >> >> Jack >> _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Nov 30 15:52:52 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 AB2953A6A48; Sun, 30 Nov 2008 15:52:52 -0800 (PST) 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 97DFB3A6A1A for ; Sun, 30 Nov 2008 15:52:50 -0800 (PST) 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 HLicEBgHlkus for ; Sun, 30 Nov 2008 15:52:50 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id DB4C53A68CE for ; Sun, 30 Nov 2008 15:52:49 -0800 (PST) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id mAUNqgiV013083; Sun, 30 Nov 2008 17:52:42 -0600 (CST) Received: from inexp02.in.lucent.com ([135.254.223.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Nov 2008 17:52:42 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.25]) by inexp02.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 05:22:38 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Dec 2008 05:22:36 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD424196502356C2F@INEXC1U01.in.lucent.com> In-Reply-To: <77ead0ec0811301039k1e279415tb4d5037b0c9e3a74@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Deep Inspecting ESP-NULL Packets Thread-Index: AclTGwzNM8vLAbbkTp+K68M5jZPoKAAKmKqQ References: <6D26D1FE43A66F439F8109CDD424196502356B45@INEXC1U01.in.lucent.com> <01f901c95173$5199e9a0$54f4200a@amer.cisco.com> <6D26D1FE43A66F439F8109CDD424196502356BC5@INEXC1U01.in.lucent.com> <6D26D1FE43A66F439F8109CDD424196502356C2B@INEXC1U01.in.lucent.com> <77ead0ec0811301039k1e279415tb4d5037b0c9e3a74@mail.gmail.com> From: "Bhatia, Manav \(Manav\)" To: "Vishwas Manral" X-OriginalArrivalTime: 30 Nov 2008 23:52:38.0422 (UTC) FILETIME=[B9A58B60:01C95346] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: ipsec@ietf.org Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets 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 Vishwas, [ .. ] > What would an IPsec router do in case it gets one of the reserved SPI > values in the packet? The transit routers would not care about this while the end routers should ignore such packets. In this case, the latter behavior is acceptable as end routers unaware of this extension would anyways be unable able to parse this packet. Cheers, Manav > > Thanks again, > Vishwas > > On Sun, Nov 30, 2008 at 7:57 AM, Bhatia, Manav (Manav) > wrote: > > Hi Jack, > > > >> > could look at the 5th octet to know what the next-header > >> is. If you want > >> > the firewalls to be able to parse the L4 info then you > >> could include the > >> > ESP header length too. This could be the 6th octet. > Using this the > >> > >> I am assuming that you're mentioning ESP header length > explicitly to > >> account for the IV (if required, by the authentication > algorithm), as > >> otherwise its a fixed value and can always be inferred, right? > > > > Yes, that's correct. > > > > Cheers, Manav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Nov 30 17:05: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 DB3BD3A6AAC; Sun, 30 Nov 2008 17:05:27 -0800 (PST) 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 31ACF28C0D8 for ; Sun, 30 Nov 2008 17:05:27 -0800 (PST) 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 05VBeRPf99jc for ; Sun, 30 Nov 2008 17:05:25 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 784263A6A7D for ; Sun, 30 Nov 2008 17:05:24 -0800 (PST) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id mB115KBl002349 for ; Sun, 30 Nov 2008 19:05:20 -0600 (CST) Received: from inexp02.in.lucent.com ([135.254.223.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Nov 2008 19:05:19 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.25]) by inexp02.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 06:35:16 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C95350.DEDBB16E" Date: Mon, 1 Dec 2008 06:35:14 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD424196502356C33@INEXC1U01.in.lucent.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: draft-bhatia-ipsecme-esp-null-00.txt Thread-Index: AclTUN4AhGExzZB0Q2KvPONyKHzphA== From: "Bhatia, Manav \(Manav\)" To: X-OriginalArrivalTime: 01 Dec 2008 01:05:16.0044 (UTC) FILETIME=[DEFDE4C0:01C95350] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [IPsec] draft-bhatia-ipsecme-esp-null-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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C95350.DEDBB16E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have written a small draft describing my proposal. It incorporates the feedback that I received from the mailing list and offline. I think the main difference between this draft and the WG draft is that while the latter requires a new IP protocol number, mine uses one of the reserved SPI values (keeping the protocol number intact) to disambiguate ESP-NULL from the encrypted ESP packets. In my proposal nothing happens to the ESP packets on the noncompliant intermediaries, while in case of the latter, they would probably get dropped (as those packets would not be recognized). I have submitted a copy to internet-drafts and it should be available online in a few days. The WG could meanwhile, review the attached draft. Would appreciate comments and feedback! Thanks, Manav -- Manav Bhatia, IP Division, Alcatel-Lucent, Bangalore - India =20 ------_=_NextPart_001_01C95350.DEDBB16E Content-Type: text/plain; name="draft-bhatia-ipsecme-esp-null-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-bhatia-ipsecme-esp-null-00.txt Content-Disposition: attachment; filename="draft-bhatia-ipsecme-esp-null-00.txt" SW50ZXJuZXQgRHJhZnQgICAgICAgICBJZGVudGlmeWluZyBFU1AtTlVMTCBQYWNrZXRzICAgICAg IERlY2VtYmVyIDIwMDggDQogDQogDQogICBOZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIE1hbmF2IEJoYXRpYSANCiAgIEludGVybmV0IERyYWZ0 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFsY2F0ZWwtTHVjZW50IA0K ICAgSW50ZW5kZWQgU3RhdHVzOiBQcm9wb3NlZCBTdGFuZGFyZCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQogICBFeHBpcmVzOiBNYXkgMjAwOSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICANCiAgICAgICAgICAgICAgICAg ICAgICAgSWRlbnRpZnlpbmcgRVNQLU5VTEwgUGFja2V0cyANCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgZHJhZnQtYmhhdGlhLWlwc2Vj bWUtZXNwLW51bGwtMDAudHh0IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCiAgICANCiAgIFN0YXR1cyBvZiB0aGlzIE1lbW8gDQogICAgDQogICBCeSBzdWJtaXR0aW5n IHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCBhbnkgDQog ICBhcHBsaWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNo ZSBpcyBhd2FyZSANCiAgIGhhdmUgYmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBv ZiB3aGljaCBoZSBvciBzaGUgYmVjb21lcyANCiAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBp biBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4gDQogICAgDQogICBJbnRlcm5l dC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmlu ZyANCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91 cHMuICBOb3RlIHRoYXQgDQogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3Jr aW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0gDQogICBEcmFmdHMuIA0KICAgIA0KICAgSW50ZXJu ZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXgg bW9udGhzIA0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5 IG90aGVyIGRvY3VtZW50cyBhdCBhbnkgDQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0 byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZSANCiAgIG1hdGVyaWFsIG9yIHRvIGNp dGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIgDQogICAgDQogICBUaGUg bGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQgDQogICBo dHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuIA0KICAgIA0KICAgVGhl IGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3Nl ZCBhdCANCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuIA0KICAgIA0KICAgVGhp cyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBNYXkgMjAwOS4gDQogICAgDQpBYnN0cmFj dCANCiAgICANCiAgIEVuY2Fwc3VsYXRpbmcgU2VjdXJpdHkgUGF5bG9hZCAoRVNQKSBbUkZDNDMw M10gcHJvdmlkZXMgZGF0YSANCiAgIGludGVncml0eSBwcm90ZWN0aW9uLCBjb25maWRlbnRpYWxp dHkgYW5kIGRhdGEgb3JpZ2luIGF1dGhlbnRpY2F0aW9uIA0KICAgZm9yIGRhdGEgdHJhbnNwb3J0 ZWQgaW4gYW4gSW50ZXJuZXQgUHJvdG9jb2wgKElQKSBbUkZDNzkxXSBbUkZDMjQ2MF0gDQogICBw YWNrZXQuICANCiAgICANCiAgIFRoZXJlIGFyZSB2YXJpb3VzIGFwcGxpY2F0aW9ucyBhbmQgcHJv dG9jb2xzIHRoYXQgZG8gbm90IHJlcXVpcmUgDQogICBjb25maWRlbnRpYWxpdHkgYnV0IG9ubHkg bmVlZCBkYXRhIGludGVncml0eSBhc3N1cmFuY2Ugb3IgZGF0YSBvcmlnaW4gDQogICBhdXRoZW50 aWNhdGlvbi4gU2luY2UgRVNQIHN1cHBvcnQgaXMgbWFuZGF0b3J5IGZvciBJUFNlYywgc3VjaCAN CiAgIGFwcGxpY2F0aW9ucyBlbmQgdXAgdXNpbmcgRVNQIHdpdGggTlVMTCBlbmNyeXB0aW9uLiAN CiAgICANCiAgIEhvd2V2ZXIsIGJlY2F1c2Ugb2YgdGhlIHdheSBFU1AgaXMgZGVmaW5lZCwgaXQg aXMgaW1wb3NzaWJsZSBmb3IgDQogICBmaXJld2FsbHMgYW5kIGludGVybWVkaWF0ZSByb3V0ZXJz IHRvIGRpZmZlcmVudGlhdGUgYmV0d2VlbiBlbmNyeXB0ZWQgDQogIA0KIA0KQmhhdGlhICAgICAg ICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAyMDA5ICAgICAgICAgICAgICAgICAgW1BhZ2Ug MV0gDQoMSW50ZXJuZXQgRHJhZnQgICAgICAgICBJZGVudGlmeWluZyBFU1AtTlVMTCBQYWNrZXRz ICAgICAgIERlY2VtYmVyIDIwMDggDQogDQogDQogICBFU1AgYW5kIEVTUCBOVUxMIHBhY2tldHMg Ynkgc2ltcGx5IGV4YW1pbmluZyB0aGVtLiBUaGlzIHBvc2VzIA0KICAgcHJvYmxlbXMgZm9yIHRo ZSBmaXJld2FsbHMgc2luY2Ugc3VjaCBwYWNrZXRzIGNhbm5vdCBiZSBmaWx0ZXJlZCBhbmQgDQog ICBpZGVudGlmaWVkLiBJdCBwb3NlcyBhIGRpZmZlcmVudCBzZXQgb2YgcHJvYmxlbXMgZm9yIHJv dXRlcnMgc2luY2UgDQogICBzdWNoIHBhY2tldHMgY2Fubm90IGJlIHByb3Blcmx5IGZpbHRlcmVk LCBjbGFzc2lmaWVkIGFuZCBwcmlvcml0aXplZC4gDQogICAgDQogICBUaGlzIGRvY3VtZW50IHBy b3Bvc2VzIGFuIGV4dGVuc2lvbiB0byBFU1Agc28gdGhhdCBmaXJld2FsbHMgYW5kIA0KICAgcm91 dGVycyBjYW4gZGlzYW1iaWd1YXRlIGJldHdlZW4gRVNQIGVuY3J5cHRlZCBhbmQgRVNQIE5VTEwg ZW5jcnlwdGVkIA0KICAgcGFja2V0cy4gIA0KICAgIA0KQ29udmVudGlvbnMgdXNlZCBpbiB0aGlz IGRvY3VtZW50IA0KICAgIA0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJS RVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLCANCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5P VCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzICANCiAgIGRv Y3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLiAN CiAgICANCjEuIEludHJvZHVjdGlvbiANCiAgICANCiAgIEVTUC1OVUxMIGlzIHVzZWQgd2hlbiBj b25maWRlbnRpYWxpdHkgaXMgbm90IHJlcXVpcmVkIGFuZCBvbmx5IHNvdXJjZSANCiAgIGF1dGhl bnRpY2F0aW9uIGFuZCBkYXRhIGludGVncml0eSBhc3N1cmFuY2UgaXMgZGVzaXJlZC4gIA0KICAg IA0KICAgSVBTZWMgbWFuZGF0ZXMgdGhlIHVzZSBvZiBFU1Agd2hpbGUga2VlcHMgc3VwcG9ydCBm b3IgQXV0aGVudGljYXRpb24gDQogICBIZWFkZXIgKEFIKSBbUkZDNDMwMl0gYXMgb3B0aW9uYWwu IFRodXMsIG5ldyBwcm90b2NvbHMgdXNpbmcgSVBTZWMgDQogICBmb3IgZGF0YSBpbnRlZ3JpdHkg YWxzbyBtYW5kYXRlIHRoZSB1c2Ugb2YgRVNQLU5VTEwuIEl0IGlzIGFsc28gDQogICBtYW5kYXRv cnkgW1JGQzQ4MzVdIGZvciBhbGwgRVNQIGltcGxlbWVudGF0aW9ucyB0byBwcm92aWRlIHN1cHBv cnQgDQogICBmb3IgRVNQIE5VTEwgZW5jcnlwdGlvbi4gQmVjYXVzZSBvZiB0aGVzZSBmYWN0b3Jz IGEgbG90IG9mIHZlbmRvcnMgZG8gDQogICBub3QgaW1wbGVtZW50IEFIIGFuZCBvbmx5IHN1cHBv cnQgRVNQLU5VTEwgZm9yIGRhdGEgaW50ZWdyaXR5IGFuZCANCiAgIHNvdXJjZSBhdXRoZW50aWNh dGlvbi4gVGhlIHRyYWZmaWMgdXNpbmcgRVNQLU5VTEwgaXMgdGh1cyBvbmx5IGdvaW5nIA0KICAg dG8gaW5jcmVhc2Ugd2l0aCB0aW1lLiANCiAgICANCiAgIEZpcmV3YWxscyBhbmQgaW50ZXJtZWRp YXRlIHJvdXRlcnMgaW4gdGhlIG5ldHdvcmsgZmluZCBpdCBpbXBvc3NpYmxlIA0KICAgdG8gcGFy c2UgRVNQIHBhY2tldHMgc2luY2UgdGhleSBoYXZlIG5vIGlkZWEgd2hldGhlciB0aGUgcGFja2V0 IGlzIA0KICAgZW5jcnlwdGVkIG9yIG5vdC4gVGhleSBjYW5ub3QgZm9yIHRoaXMgcmVhc29uIGlt cGxlbWVudCBmaWx0ZXJzIGFuZCANCiAgIGFjY2VzcyBjb250cm9sIGxpc3RzIChBQ0xzKS4gIA0K ICAgIA0KICAgQUNMcyBhcmUgaGlnaGx5IGRlc2lyYWJsZSBhbmQgdXNlZCBleHRlbnNpdmVseSBi eSBzZXJ2aWNlIHByb3ZpZGVycyANCiAgIHRvIGJsb2NrIHVuZGVzaXJlZCB0cmFmZmljIGNvbWlu ZyBmcm9tIG90aGVyIGRvbWFpbnMuIA0KICAgIA0KICAgVGhpcyBkcmFmdCB0aGVyZWZvcmUgcHJv cG9zZXMgYW4gZXh0ZW5zaW9uIHRvIEVTUCB3aXRoIHdoaWNoIA0KICAgaWRlbnRpZnlpbmcgYW4g RVNQLU5VTEwgcGFja2V0IGZyb20gYW4gRVNQIGVuY3J5cHRlZCBwYWNrZXQgYmVjb21lcyANCiAg IHRyaXZpYWwuIEl0IGlzIGJhY2t3YXJkIGNvbXBhdGlibGU7IHRoZXJlZm9yZSBpbnRlcm1lZGlh dGUgZGV2aWNlcyANCiAgIHRoYXQgZG8gbm90IHVuZGVyc3RhbmQgdGhpcyBleHRlbnNpb24gd291 bGQgdHJlYXQgcGFja2V0cyB1c2luZyB0aGlzIA0KICAgZXh0ZW5zaW9uIGFzIG5vcm1hbCBFU1Ag cGFja2V0cy4gIA0KICAgIA0KICAgVGhlIGV4dGVuc2lvbiBkZXNjcmliZWQgaW4gdGhpcyBkcmFm dCBpcyBhcHBsaWNhYmxlIGZvciBib3RoIHR1bm5lbCANCiAgIGFuZCB0cmFuc3BvcnQgbW9kZXMg b2YgRVNQLiANCiAgICANCg0KDQoNCiAgDQogDQpCaGF0aWEgICAgICAgICAgICAgICAgICAgICBF eHBpcmVzIEFwcmlsIDIwMDkgICAgICAgICAgICAgICAgICBbUGFnZSAyXSANCgxJbnRlcm5ldCBE cmFmdCAgICAgICAgIElkZW50aWZ5aW5nIEVTUC1OVUxMIFBhY2tldHMgICAgICAgRGVjZW1iZXIg MjAwOCANCiANCiANCjIuIEV4cGxpY2l0bHkgTWFya2luZyBFU1AgTlVMTCBQYWNrZXRzIA0KIA0K ICAgRVNQLU5VTEwgcGFja2V0cywgZm9yIGJvdGggaW1wbGVtZW50YXRpb25zIGJhc2VkIG9uIFtS RkMyNDEwXSBhbmQgDQogICBbUkZDNDU0M10gTVVTVCBiZSBzZW50IHdpdGggYSB3ZWxsIGtub3du LCByZXNlcnZlZCBTUEkgb2YgMS4gVGhlIA0KICAgb3JpZ2luYWwgU1BJIHNob3VsZCBiZSBpbmNs dWRlZCBhcyBwYXJ0IG9mIHRoZSBwYXlsb2FkLiBUaGlzIGlzIA0KICAgZW5jb2RlZCBpbiB0aGUg Zmlyc3QgNCBvY3RldHMgb2YgdGhlIHBheWxvYWQgc2VjdGlvbiBvZiB0aGUgRVNQIA0KICAgaGVh ZGVyLiBBbiBpbXBsZW1lbnRhdGlvbiB0aGVuIE1VU1QgcHV0IHRoZSBuZXh0LWhlYWRlciBmb2xs b3dlZCBieSANCiAgIHRoZSBFU1AgaGVhZGVyIGxlbmd0aCBhcyB0aGUgZmlmdGggYW5kIHRoZSBz aXh0aCBvY3RldHMgb2YgdGhlIA0KICAgcGF5bG9hZC4gDQogICAgDQogICBTaW5jZSB0aGUgcGFj a2V0IGlzIG5vdCBlbmNyeXB0ZWQgdGhlc2UgZmllbGRzIHdvdWxkIGJlIHNlbnQgaW4gY2xlYXIg DQogICB0ZXh0IGFuZCB3b3VsZCBiZSB2aXNpYmxlIHRvIGFsbC4gDQogICAgDQogICBBbiBleHRl bmRlZCBFU1AgcGFja2V0IHVzaW5nIE5VTEwgZW5jcnlwdGlvbiB3b3VsZCB0aHVzIGxvb2sgbGlr ZSANCiAgIHRoaXM6IA0KICAgIA0KICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAg ICAgICAgIDIgICAgICAgICAgICAgICAgICAgMyANCiAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSANCiAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICAN CiAgIHwgICAgICAgIFJlc2VydmVkIFNlY3VyaXR5IFBhcmFtZXRlcnMgSW5kZXggKFJTUEkpID0g MSAgICAgICAgICB8ICANCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICANCiAgIHwgICAgICAgICAgICAgICAgICAgICAg U2VxdWVuY2UgTnVtYmVyICAgICAgICAgICAgICAgICAgICAgICAgICB8ICANCiAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r ICANCiAgIHwgICAgICAgICAgT3JpZ2luYWwgU2VjdXJpdHkgUGFyYW1ldGVycyBJbmRleCAoU1BJ KSAgICAgICAgICAgICB8ICANCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICANCiAgIHwgIG5leHQtaGVhZGVyICB8ICBl RVNQIEhEUkxlbiAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICsgDQogICB8ICAgICAgICAgICAgICAgICAgICBQYXlsb2FkIERhdGEqICh2YXJpYWJsZSkgICAg ICAgICAgICAgICAgICAgfCAgDQogICB+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfiAgDQogICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgDQogICArICAg ICAgICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKyAgDQogICB8ICAgICAgICAgICAgICAgfCAgICAgUGFkZGluZyAoMC0yNTUgYnl0ZXMpICAg ICAgICAgICAgICAgICAgICAgfCAgDQogICArLSstKy0rLSstKy0rLSstKyAgICAgICAgICAgICAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgDQogICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgIFBhZCBMZW5ndGggICB8IE5leHQgSGVhZGVyICAgfCAgDQogICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKyAgDQogICB8ICAgICAgICAgICAgICAgICAgQXV0aGVudGljYXRpb24gRGF0YSAgKHZh cmlhYmxlKSAgICAgICAgICAgICAgfCANCiAgIH4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB+IA0KICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKyANCiAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMSAN CiAgICANCiAgIFJlc2VydmVkIFNlY3VyaXR5IFBhcmFtZXRlcnMgSW5kZXggKFJTUEkpOiBXZWxs IGtub3duIHZhbHVlIHRoYXQgDQogICBzaG91bGQgYmUgZ2l2ZW4gYnkgSUFOQSB3aGljaCB3b3Vs ZCBpbmRpY2F0ZSB0aGF0IGl0IGlzIGFuIEVTUC1OVUxMIA0KICAgcGFja2V0LiAgDQogICAgDQog ICBuZXh0LWhlYWRlcjogVGhpcyBpcyBhIG9uZSBvY3RldCBmaWVsZCB0aGF0IGluZGljYXRlcyB0 aGUgbmV4dCANCiAgIHByb3RvY29sIGhlYWRlci4gRXhwbGljaXRseSBtZW50aW9uaW5nIHRoaXMg cHJvdmlkZXMgYW4gZWFzeSBhY2Nlc3MgDQogICB0byBhIEhXIHBhcnNlciB0byBleHRyYWN0IHRo ZSB1cHBlciBsYXllciBwcm90b2NvbC4gDQogIA0KIA0KQmhhdGlhICAgICAgICAgICAgICAgICAg ICAgRXhwaXJlcyBBcHJpbCAyMDA5ICAgICAgICAgICAgICAgICAgW1BhZ2UgM10gDQoMSW50ZXJu ZXQgRHJhZnQgICAgICAgICBJZGVudGlmeWluZyBFU1AtTlVMTCBQYWNrZXRzICAgICAgIERlY2Vt YmVyIDIwMDggDQogDQogDQogICAgDQogICBlRVNQIEhEUkxlbjogVGhpcyBpcyBhIG9uZSBvY3Rl dCBmaWVsZCB0aGF0IGdpdmVzIHRoZSBsZW5ndGggb2YgdGhlIA0KICAgZXh0ZW5kZWQgRVNQIGhl YWRlciArIElWIChpZiBtYW5kYXRlZCBieSB0aGUgYXV0aGVudGljYXRpb24gDQogICBhbGdvcml0 aG0pLiBJdCBpcyBhbiBvZmZzZXQgdG8gdGhlIGJlZ2lubmluZyBvZiB0aGUgcGF5bG9hZCBkYXRh LiANCiAgICANCiAgIEludGVybWVkaWF0ZSBub2RlcyAocm91dGVycywgZmlyZXdhbGxzLCBldGMp IGludGVyZXN0ZWQgaW4gaW5zcGVjdGluZyANCiAgIHRoZSBwYWNrZXRzIGVuIHJvdXRlIGNhbiBs b29rIGF0IHRoZSBTUEkgdmFsdWUgYXQgdGhlIHN0YXJ0IG9mIHRoZSANCiAgIEVTUCBoZWFkZXIu IElmIHRoZXkgYXJlIHVuYXdhcmUgb2YgdGhpcyBleHRlbnNpb24gdGhlbiB0aGlzIHBhY2tldCAN CiAgIHdvdWxkIGFwcGVhciBsaWtlIGEgbm9ybWFsIEVTUCBwYWNrZXQuIEhvd2V2ZXIsIGNvbXBs aWFudCANCiAgIGltcGxlbWVudGF0aW9ucyB3aWxsIHVuZGVyc3RhbmQgdGhhdCB0aGlzIGlzIGFu IGV4dGVuZGVkIEVTUCBwYWNrZXQgDQogICBhbmQgd291bGQgaGF2ZSBlbm91Z2ggaW5mb3JtYXRp b24gdG8gYmUgYWJsZSB0byBkZWVwIGluc3BlY3QgdGhlIEVTUC0NCiAgIE5VTEwgcGFja2V0LiAN CiAgICANCiAgIFRoZSBjb21wbGlhbnQgZW5kIG5vZGVzIChyb3V0ZXJzKSBjYW4gc2ltaWxhcmx5 IGVhc2lseSBwYXJzZSB0aGUgDQogICBwYWNrZXQuIElmIHRoZSBTUEkgdmFsdWUgaXMgMSwgdGhl biBpdCBjYW4gZXh0cmFjdCB0aGUgb3JpZ2luYWwgU1BJIA0KICAgZnJvbSB0aGUgcGF5bG9hZCBh bmQgcHJvY2VzcyB0aGUgcGFja2V0IGFjY29yZGluZ2x5LiANCiAgICANCjMuIEF1dGhlbnRpY2F0 aW5nIHRoZSBQYWNrZXRzIA0KICAgIA0KICAgQWxsIGZpZWxkcyBvZiB0aGUgZXh0ZW5kZWQgRVNQ IGhlYWRlciBzdGFydGluZyB3aXRoIHRoZSBSU1BJIGFuZCANCiAgIGVuZGluZyB3aXRoIHRoZSBO ZXh0IEhlYWRlciBpbiB0aGUgRVNQIHRyYWlsZXIgYXJlIGluY2x1ZGVkIGluIHRoZSANCiAgIEVT UCBkYXRhIGludGVncml0eSBjaGVjay4gDQogICAgDQogICBUaGUgYXV0aGVudGljYXRpb24gZGF0 YSBmaWVsZCBpcyB1c2VkIHRvIGhvbGQgdGhlIHJlc3VsdCBvZiB0aGUgZGF0YSANCiAgIGludGVn cml0eSBjaGVjayBkb25lIG9uIHRoZSBFU1AgcGFja2V0LiBUaGUgbGVuZ3RoIG9mIHRoaXMgZmll bGQgDQogICBkZXBlbmRzIG9uIHRoZSBhdXRoZW50aWNhdGlvbiBhbGdvcml0aG0gZW1wbG95ZWQg YnkgdGhlIFNlY3VyaXR5IA0KICAgQXNzb2NpYXRpb24gKFNBKSB1c2VkIHRvIHByb2Nlc3MgdGhp cyBwYWNrZXQuICANCiAgICANCjQuIEFja25vd2xlZGdlbWVudHMgIA0KICAgICANCiAgIFRoZSBh dXRob3Igd291bGQgbGlrZSB0byB0aGFuayBKYWNrIEtvaG4gZm9yIGhpcyB1c2VmdWwgY29tbWVu dHMuIA0KICAgIA0KNS4gSUFOQSBDb25zaWRlcmF0aW9ucyAgDQogDQogICBJQU5BIG11c3QgYXNz aWduIGEgdmFsdWUgdGhhdCBmb3IgUmVzZXJ2ZWQgU1BJIHdoaWNoIHdpbGwgYmUgdXNlZCBhcyAN CiAgIGRlc2NyaWJlZCBhYm92ZS4gVGhlIGRyYWZ0IHVzZXMgYSB2YWx1ZSAxIHRvIGZvc3RlciBw cmUtc3RhbmRhcmQgDQogICBpbXBsZW1lbnRhdGlvbnMuIA0KICAgIA0KNi4gU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMgDQogICAgDQogICBUaGlzIHByb3Bvc2FsIG5laXRoZXIgaW5jcmVhc2VzIG5v ciBkZWNyZWFzZXMgdGhlIHNlY3VyaXR5IGZvciBFU1AuIA0KICAgQWxsIGNvbnNpZGVyYXRpb25z IHZhbGlkIGZvciBFU1AgYWxzbyBhcHBseSBoZXJlLiAgDQogICAgDQo3LiBSZWZlcmVuY2VzIA0K IA0KNy4xIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIA0KICAgIA0KICAgIA0KICAgW1JGQzQzMDNdIEtl bnQsIFMuLCAiSVAgRW5jYXBzdWxhdGluZyBTZWN1cml0eSBQYXlsb2FkIChFU1ApIiwgICAgICAg ICAgICAgICANCiAgDQoMIA0KQmhhdGlhICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJp bCAyMDA5ICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0gDQoMSW50ZXJuZXQgRHJhZnQgICAgICAg ICBJZGVudGlmeWluZyBFU1AtTlVMTCBQYWNrZXRzICAgICAgIERlY2VtYmVyIDIwMDggDQogDQog DQogICAgICAgICAgICAgUkZDIDQzMDMsIERlY2VtYmVyIDIwMDUuICAgDQogICAgDQogICBbUkZD MjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0 ZSAgIA0KICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBSRkMgMjExOSwgQkNQIDE0 LCBGZWJydWFyeSAyMDAxLiANCiAgICANCiAgIFtSRkMyNDEwXSBHbGVubiwgUi4sIGFuZCBLZW50 LCBTLiwgIlRoZSBOVUxMIEVuY3J5cHRpb24gQWxnb3JpdGhtIGFuZCAgDQogICAgICAgICAgICAg aXRzIFVzZSBXaXRoIElQc2VjIiwgUkZDIDI0MTAsIE5vdmVtYmVyIDE5OTguIA0KICAgIA0KICAg W1JGQzQ1NDNdIE1jR3JldywgRC4gYW5kIFZpZWdhLCBKLiwgIlRoZSBVc2Ugb2YgR2Fsb2lzIE1l c3NhZ2UgIA0KICAgICAgICAgICAgIEF1dGhlbnRpY2F0aW9uIENvZGUgKEdNQUMpIGluIElQc2Vj IEVTUCBhbmQgQUgiLCBSRkMgNDU0MywgIA0KICAgICAgICAgICAgIE1heSAyMDA2LiANCiAgICAN CjcuMiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIA0KICAgIA0KICAgW1JGQzc5MV0gIElTSSwgIklu dGVybmV0IFByb3RvY29sIiwgUkZDIDc5MSwgU2VwdGVtYmVyIDE5ODEgDQogICAgDQogICBbUkZD MjQ2MF0gRGVlcmluZywgUy4gYW5kIEhpbmRlbiwgUi4sICJJbnRlcm5ldCBQcm90b2NvbCwgVmVy c2lvbiA2ICANCiAgICAgICAgICAgICAoSVB2NikgU3BlY2lmaWNhdGlvbiIsIERlY2VtYmVyIDE5 OTggDQogICAgDQogICBbUkZDNDMwMl0gS2VudCwgUy4sICJJUCBBdXRoZW50aWNhdGlvbiBIZWFk ZXIiLCBSRkMgNDMwMiwgIA0KICAgICAgICAgICAgIERlY2VtYmVyIDIwMDUuICANCiAgICANCiAg IFtSRkM0ODM1XSBNYW5yYWwsIFYuLCAiQ3J5cHRvZ3JhcGhpYyBBbGdvcml0aG0gSW1wbGVtZW50 YXRpb24gIA0KICAgICAgICAgICAgIFJlcXVpcmVtZW50cyBmb3IgRW5jYXBzdWxhdGluZyBTZWN1 cml0eSBQYXlsb2FkIChFU1ApIGFuZCAgICAgDQogICAgICAgICAgICAgQXV0aGVudGljYXRpb24g SGVhZGVyIChBSCkiLCBSRkMgNDgzNSwgQVBSSUwgMjAwNy4gDQogICAgDQo4LiBBdXRob3IncyBB ZGRyZXNzZXMgDQogICAgDQogICBNYW5hdiBCaGF0aWEgDQogICBBbGNhdGVsLUx1Y2VudCwgDQog ICBCYW5nYWxvcmUsIEluZGlhIA0KICAgRW1haWw6IG1hbmF2QGFsY2F0ZWwtbHVjZW50LmNvbSAg ICAgDQogICAgDQpGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQgDQogICAgDQogICBDb3B5cmlnaHQg KEMpIFRoZSBJRVRGIFRydXN0ICgyMDA4KS4gDQogICAgDQogICBUaGlzIGRvY3VtZW50IGlzIHN1 YmplY3QgdG8gdGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucyANCiAgIGNvbnRh aW5lZCBpbiBCQ1AgNzgsIGFuZCBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRo b3JzIA0KICAgcmV0YWluIGFsbCB0aGVpciByaWdodHMuIA0KICAgIA0KICAgVGhpcyBkb2N1bWVu dCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFu IA0KICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9O IEhFL1NIRSBSRVBSRVNFTlRTIA0KICAgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUg SU5URVJORVQgU09DSUVUWSwgVEhFIElFVEYgVFJVU1QgQU5EIA0KICAgVEhFIElOVEVSTkVUIEVO R0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgDQog ICBPUiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBU SEFUIFRIRSBVU0UgT0YgDQogICBUSEUgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJ TkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQgDQogICBXQVJSQU5USUVTIE9GIE1FUkNIQU5U QUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gDQogICAgDQogIA0K IA0KQmhhdGlhICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAyMDA5ICAgICAgICAg ICAgICAgICAgW1BhZ2UgNV0gDQoMSW50ZXJuZXQgRHJhZnQgICAgICAgICBJZGVudGlmeWluZyBF U1AtTlVMTCBQYWNrZXRzICAgICAgIERlY2VtYmVyIDIwMDggDQogDQogDQpJbnRlbGxlY3R1YWwg UHJvcGVydHkgDQogICAgDQogICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcg dGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueSANCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBS aWdodHMgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCANCiAgIHRvIHBlcnRh aW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmli ZWQgDQogICBpbiB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vu c2UgdW5kZXIgc3VjaCByaWdodHMgDQogICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxl OyBub3IgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMgDQogICBtYWRlIGFueSBpbmRlcGVu ZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24gDQog ICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVu dHMgY2FuIGJlIA0KICAgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuIA0KICAgIA0KICAgQ29w aWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBh bnkgICANCiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9y IHRoZSByZXN1bHQgb2YgYW4gICANCiAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFs IGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSAgIA0KICAgb2Ygc3VjaCBwcm9wcmll dGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMgICANCiAgIHNwZWNp ZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3Np dG9yeSAgIA0KICAgYXQgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuIA0KICAgIA0KICAgVGhlIElF VEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9u IGFueSANCiAgIGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Ig b3RoZXIgcHJvcHJpZXRhcnkgDQogICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0 aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQgDQogICB0aGlzIHN0YW5kYXJkLiAgUGxl YXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0IGlldGYtDQogICBpcHJA aWV0Zi5vcmcuIA0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQogIA0KIA0KQmhhdGlhICAgICAgICAgICAgICAgICAgICAg RXhwaXJlcyBBcHJpbCAyMDA5ICAgICAgICAgICAgICAgICAgW1BhZ2UgNl0gDQoM ------_=_NextPart_001_01C95350.DEDBB16E 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 ------_=_NextPart_001_01C95350.DEDBB16E-- From ipsec-bounces@ietf.org Sun Nov 30 19:55: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 189253A68F3; Sun, 30 Nov 2008 19:55:07 -0800 (PST) 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 CE76C3A67EE for ; Sun, 30 Nov 2008 19:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 dNeBJWlsNTJy for ; Sun, 30 Nov 2008 19:55:05 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by core3.amsl.com (Postfix) with ESMTP id CDD313A68F3 for ; Sun, 30 Nov 2008 19:55:04 -0800 (PST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id mB13sxB9014041 for ; Mon, 1 Dec 2008 12:54:59 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id mB13sxQh029639 for ipsec@ietf.org; Mon, 1 Dec 2008 12:54:59 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id NAA29638; Mon, 1 Dec 2008 12:54:59 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id mB13swj4013521 for ; Mon, 1 Dec 2008 12:54:58 +0900 (JST) Received: by toshiba.co.jp id mB13swc7019862; Mon, 1 Dec 2008 12:54:58 +0900 (JST) To: ipsec@ietf.org In-Reply-To: Message from "Vishwas Manral" of "Sun, 30 Nov 2008 10:39:41 PST." <77ead0ec0811301039k1e279415tb4d5037b0c9e3a74@mail.gmail.com> Date: Mon, 01 Dec 2008 12:54:58 +0900 Message-Id: <200812010354.mB13swc7019862@toshiba.co.jp> From: atsushi.fukumoto@toshiba.co.jp Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org A few comments: SPI value 1 is already assigned. You should let IANA assign a value, and until that it should be To Be Assigned. If I understand correctly, efforts has been paid to make protocol headers align at 4-octet word boundary. If the policy hasn't changed, the next protocol header should align at the word boundary inside ESP header as well. FUKUMOTO Atsushi atsushi.fukumoto@toshiba.co.jp _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Nov 30 21:25: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 7E35B3A68DD; Sun, 30 Nov 2008 21:25:57 -0800 (PST) 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 31EF63A68DD for ; Sun, 30 Nov 2008 21:25:56 -0800 (PST) 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 yOi-Gy+pUdYD for ; Sun, 30 Nov 2008 21:25:55 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 253553A67EE for ; Sun, 30 Nov 2008 21:25:53 -0800 (PST) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id mB15PmW1003847; Sun, 30 Nov 2008 23:25:48 -0600 (CST) Received: from inexp02.in.lucent.com ([135.254.223.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Nov 2008 23:25:48 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.25]) by inexp02.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 10:55:44 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Dec 2008 10:55:42 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD424196502356C66@INEXC1U01.in.lucent.com> In-Reply-To: <200812010354.mB13swc7019862@toshiba.co.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Deep Inspecting ESP-NULL Packets Thread-Index: AclTaJ6kdhVDaYXoQ3+qBfhWhokw3gAB/T7Q References: Message from "Vishwas Manral" of "Sun, 30 Nov 2008 10:39:41 PST."<77ead0ec0811301039k1e279415tb4d5037b0c9e3a74@mail.gmail.com> <200812010354.mB13swc7019862@toshiba.co.jp> From: "Bhatia, Manav \(Manav\)" To: , X-OriginalArrivalTime: 01 Dec 2008 05:25:44.0076 (UTC) FILETIME=[420654C0:01C95375] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets 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 Atsushi, > SPI value 1 is already assigned. I didn't realize that SPI of 1 was already taken. I tried searching for it on the IANA website but couldn't find it. Can you point me to the RFC that defines this? > You should let IANA assign a value, > and until that it should be To Be Assigned. Yup, will do that. > If I understand correctly, efforts has been paid to make protocol > headers align at 4-octet word boundary. If the policy hasn't changed, > the next protocol header should align at the word boundary inside ESP > header as well. Its easy to align it on a word boundary - just add two reserved bytes after the header length; these would be set to zero when transmitting and ignored on receipt. This also leaves room for further extensions. Cheers, Manav > > > FUKUMOTO Atsushi > atsushi.fukumoto@toshiba.co.jp > _______________________________________________ > 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 lthxp@advantagepayroll.com Sun Nov 30 23:22:37 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 9E7403A6896 for ; Sun, 30 Nov 2008 23:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -33.574 X-Spam-Level: X-Spam-Status: No, score=-33.574 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, 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 Ka0gBBt2kE-2 for ; Sun, 30 Nov 2008 23:22:36 -0800 (PST) Received: from ppp91-76-43-19.pppoe.mtu-net.ru (ppp91-76-43-19.pppoe.mtu-net.ru [91.76.43.19]) by core3.amsl.com (Postfix) with SMTP id 885FA3A69DA for ; Sun, 30 Nov 2008 23:22:32 -0800 (PST) To: Subject: Heavy mortars in Africa From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081201072235.885FA3A69DA@core3.amsl.com> Date: Sun, 30 Nov 2008 23:22:32 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From ipsec-bounces@ietf.org Sun Nov 30 23:27: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 817EF3A69FD; Sun, 30 Nov 2008 23:27:46 -0800 (PST) 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 8B9C43A69EB for ; Sun, 30 Nov 2008 23:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 uKjFNFWqzmcq for ; Sun, 30 Nov 2008 23:27:44 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by core3.amsl.com (Postfix) with ESMTP id 731BD3A6947 for ; Sun, 30 Nov 2008 23:27:39 -0800 (PST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id mB17RYbC012823 for ; Mon, 1 Dec 2008 16:27:34 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id mB17RYP8016638 for ipsec@ietf.org; Mon, 1 Dec 2008 16:27:34 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id SAA16635; Mon, 1 Dec 2008 16:27:34 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id mB17RYKe016334 for ; Mon, 1 Dec 2008 16:27:34 +0900 (JST) Received: by toshiba.co.jp id mB17RYZe013174; Mon, 1 Dec 2008 16:27:34 +0900 (JST) To: "Bhatia, Manav \(Manav\)" In-Reply-To: Message from "Bhatia, Manav \(Manav\)" of "Mon, 01 Dec 2008 10:55:42 +0530." <6D26D1FE43A66F439F8109CDD424196502356C66@INEXC1U01.in.lucent.com> Date: Mon, 01 Dec 2008 16:27:33 +0900 Message-Id: <200812010727.mB17RYZe013174@toshiba.co.jp> From: atsushi.fukumoto@toshiba.co.jp Cc: ipsec@ietf.org Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Bhatia, Manav \(Manav\) wrote: > > SPI value 1 is already assigned. > > I didn't realize that SPI of 1 was already taken. I tried searching for > it on the IANA website but couldn't find it. Can you point me to the RFC > that defines this? > Refer to http://www.iana.org/assignments/spi-numbers . SKIP stands for Simple Key-Management for Internet Protocol. > > If I understand correctly, efforts has been paid to make protocol > > headers align at 4-octet word boundary. If the policy hasn't changed, > > the next protocol header should align at the word boundary inside ESP > > header as well. > > Its easy to align it on a word boundary - just add two reserved bytes > after the header length; these would be set to zero when transmitting > and ignored on receipt. This also leaves room for further extensions. > I was wrong, it should be 8-octets boundary. (RFC2460, section 4) I guess there's no difference for your case, though. FUKUMOTO Atsushi atsushi.fukumoto@toshiba.co.jp _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec